[Cloud Native] Introduction and Basic Concepts of Kubernetes

1. Introduction to Kubernetes

1.1 Definition and background of Kubernetes

Kubernetes is a portable, extensible, open source platform. Used to manage containerized workloads and services, facilitating declarative configuration and automation. It is an open source version of Borg, a secret weapon that Google has kept secret for more than ten years. Google has been managing a large number of application clusters through the Borg system. Since Kubernetes is a distributed architecture solution based on container technology, it is not limited to any programming language.

Kubernetes is a pluggable open platform, and those default solutions are optional. Kubernetes provides the foundation for building a developer platform, but retains user choice in important places and has higher flexibility.

1.2. Functions of Kubernetes

1. For service discovery and load balancing , Kubernetes can expose containers using DNS names or their own IP addresses. If there is a lot of traffic coming into the container, Kubernetes can load balance and distribute the network traffic, making the deployment stable.
2. For deployment and rollback , the desired state of the container can be described through a configuration file, and the actual state of the container can be changed to the desired state at a controlled rate. Support rollback by deployment, and support rollback to a specified deployment version.
3. Elastic scaling , automatic scaling policies can be configured according to indicators to deal with burst traffic.
4. Container quota management , allowing to specify the required CPU and memory for each container.
5. Fault detection and self-healing , Kubernetes will automatically find containers that do not meet health checks, and try to restart and replace these containers. Clients are not notified until the service is ready.
6. Key and configuration management , Kubernetes provides secret and configMap, two resources to manage key information and configuration information respectively.
7. Supports multiple data volume types , such as: local storage, public cloud providers, distributed storage systems, etc.

1.3 What Kubernetes can't do

1. Restricting application types is not supported. Kubernetes is designed to support a wide variety of workloads, and if an application can run in a container, it will run well on Kubernetes.
2. The source code is not deployed, and the application is not built. Kubernetes is a platform based on container technology, so all deployments are images.
3. Application-level services are not provided as built-in services. For example: message middleware, mysql database, etc. But these components can run on Kubernetes.

2. Kubernetes components

2.1. Control plane (master) components

The master node makes global decisions for the cluster, such as resource scheduling, and detects and responds to cluster events, such as starting or deleting pods.
The master node usually does not run any workloads.

1. kube-apiserver , apiserver is a component of the Kubernetes master node. This component is responsible for exposing the Kubernetes API and handling the work of accepting requests. kube-apiserver supports high availability deployment.
2. etcd, a key-value database that takes into account consistency and high availability, is used to store Kubernetes cluster data.
3. kube-scheduler, the master node component, is responsible for monitoring newly created pods that do not specify a running node, and selects a node to run the pod.
4. kube-controller-manager is the master node component responsible for running the controller process.

Controllers include:

• Node Controller: Responsible for notifying and responding when a node fails.
• Task controller: Monitor job objects for tasks and create Pods to execute these tasks.
• Endpoint controller: fill in the endpoint object, that is, add service and pod.
• Replication controller: used to ensure that the actual number of pods is consistent with the expected number.
• Service Account and Token Controller: Create default accounts and API access credentials for new namespaces.

2.2, Node node components

1. The kubelet runs on each node in the cluster. It ensures that all containers are running in Pods. Cooperate with the master node to manage node nodes, and report node node information to the master node, such as: operating system, Docker version, CPU and memory of the machine, and which Pods are currently running. Report the node status to the master through regular heartbeats. If the node status fails to be reported within the timeout, the master node will judge that the node is "disconnected" and schedule pods to run on other nodes.
2. kube-proxy is a network proxy running on each node in the cluster, which implements part of the Kubernetes service (service) concept. kube-proxy maintains some network rules on the nodes that allow network communication with pods from network sessions inside or outside the cluster.
3. Container runtime, eg: docker engine + cri-dockerd.

3. Basic concepts and terminology of Kubernetes

3.1、Resource

Most concepts in Kubernetes, such as Node, Pod, Replication Controller, Service, etc., can be regarded as a resource object. Almost all resource objects can be added, deleted, and modified through the kubectl tool (or API programming call) provided by Kubernetes. , query and other operations and save them in etcd for persistent storage.

Kubernetes is actually a highly automated resource control system. It realizes advanced functions of automatic control and automatic error correction by tracking and comparing the difference between the "resource expected state" stored in the etcd library and the "actual resource state" of the current environment.

3.2、Kubernetes API version

Check out the available apiversion commands:

kubectl api-versions

K8s officially divides apiversion into three major types, alpha, beta, and stable.

• Alpha: Not fully tested, there may be bugs, and functions may be adjusted or removed at any time.
• Beta: Fully tested, feature details may be modified in the future.
• Stable: Stable version, which will receive continuous support.

3.3, Pod (core concept)

Pod is the most important basic concept of Kubernetes and the smallest scheduling unit of Kubernetes. Each Pod has a special Pause container called the "root container". In addition to the Pause and root containers, each Pod also contains one or more closely related user business containers.
Why is Kubernetes designed this way?

1. In reality, there are multiple closely related business containers that need to be deployed as a group of containers, so the pod supports deploying multiple containers in one pod, and multiple business containers in the pod share the IP and Volume of the pause, which solves the problem of closely related Communication issues between containers, data sharing issues.
2. A pod contains multiple business containers. In this case, Kubernetes cannot make a correct judgment on the overall status of the pod. Therefore, the Pause root container is introduced, and the state of the pod is represented by the state of the pause root container. For example: the question of whether the pod is dead.

Kubernetes assigns a unique IP address to each Pod, called Pod IP. Multiple containers in a Pod share the Pod IP address.
Kubernetes requires the underlying network to support TCP/IP direct communication between any two Pods in the cluster. For example: flannel, Open vSwitch, etc. Therefore, we need to remember that containers in a pod can communicate directly with pod containers on other hosts.

Pods are of two types:

1. Ordinary pod: After the pod is created, it will be stored in etcd, and then scheduled to run on a specific node node. By default, when a container in the pod stops running, Kubernetes will automatically detect the problem and restart the pod. If the node machine where the pod is located is down, the pod on the node will be rescheduled to on other nodes.
2. Static pod: A static pod is stored in a specific file on a specific Nod, and only starts and runs on that node, and cannot be scheduled to other nodes. For example: the master node components all run as static pods, and the file storage directory is: /etc/kubernetes/manifests/

In addition, for most containers, the resource quota of a CPU is quite large, so in Kubernetes, one thousandth of the CPU quota is usually used as the smallest unit, expressed in m. Usually, the CPU allocation of a container is defined as 100 ~ 300m, that is, it occupies 0.1 ~ 0.3 CPU.

spec:
  containers:
  - name: db
    image: mysql
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Usually, Requests is set to a small value, indicating the resource requirements of the container under normal workload conditions, and limits are set to the maximum resource usage under peak load conditions.

3.4, Label (core concept)

Label (label) is another core concept in the Kubernetes system. A Label is a key=value pair, where the key and value are specified by the user. Label can be attached to various resource objects, such as Node, Pod, Service, RC, etc.

A resource object can define any number of Labels, and the same Label can also be added to any number of resource objects. By binding a Label to a specified resource object, group management of resource objects is realized, which is convenient for Kubernetes to perform resource allocation, scheduling, and deployment.

By binding one or more different Labels to the specified resource object, the multi-dimensional resource group management function can be realized, so that resource allocation, scheduling, deployment and other management work can be performed flexibly and conveniently. For example:
Version tags: release:stable, release:beta.
Environment tags: environment:dev, environment:qa, environment:production.

Use the Label to affix the corresponding label to the resource object, and then use the Label Selector (label selector) to query and filter the resource objects with certain Labels. There are currently two Label Selector expressions:

1. Based on the equation: name=myweb,env!=production
2. Set-based: name in (myweb,myweb1),name not in (myweb,myweb1)

Complicated condition selection can be realized through the combination of multiple Label Selector expressions. Multiple expressions are separated by "," and the conditions are "AND" relations, that is, multiple conditions are met at the same time.

# 该片段表示：选择标签 key值为 app，value值为 myweb的资源
selector:
  app: myweb

# 该片段表示：选择标签 key值为 app且value值为 myweb
# 且 key 值为tier 且 value值 in （frontend，backend）
selector：
matchLabels:
  app: myweb
matchExpressions:
  - {
    
    key: tier, operator: In, values: [frontend,backend]}
  # 或使用以下写法
  - key: tier
    operator: In # In, NotIn, Exists and DoesNotExist
	values: ["frontend","backend"]

3.5, Replication Controller (not recommended)

Replication Controller (RC for short), RC is one of the core concepts of Kubernetes. Simply put, RC defines an expected scenario, that is, it declares that the number of replicas of a certain Pod conforms to an expected value at any time. So the definition of RC includes:

1. The number of replicas the Pod expects
2. Label Selector for filtering target Pods
3. The template used to create a Pod when the number of Pod replicas is less than expected.
4. The RC definition looks like this:

apiVersion: v1
kind: ReplicationController # 副本控制器 RC
metadata:
  name: myhello-rc # RC名称，全局唯一
  labels:
	name: myhello-rc
spec:
  replicas: 5 # Pod副本期待数量
  selector:
	name: myhello-pod
  template:
	metadata:
	  labels:
		name: myhello-pod
	spec:
	  containers: # Pod 内容的定义部分
	  - name: myhello #容器的名称
		image: long-xu/hello:1.0.0 #容器对应的 Docker Image
		imagePullPolicy: IfNotPresent
		ports:
		- containerPort: 80
		env: # 注入到容器的环境变量
		- name: env1
		  value: "k8s-env1"
		- name: env2
		  value: "k8s-env2"

After we define an RC, the controller manager component of Kubernetes will regularly inspect whether the number of copies of the target pod is consistent with the expected number. When the actual number of copies is greater than the expected number, some target pods are shut down. When the actual number of copies is less than the expected number, some new target pods are created through the pod definition template in RC.

3.6、Replica Set

Replica Set is a new concept introduced in Kubernetes version 1.2, and Replica Set is an upgraded version of RC. The difference between the two is: RC's Label Selector only supports equation-based expressions, while RS's Label Selector supports set-based expressions; after editing RS online, RS will automatically update Pod, while RC's modification will not automatically update Existing Pods.
RC (Replica Set) function:

1. Automatically create pods and automatically control the number of pod replicas by defining RC/RS
2. Filter the target pod through the Label Selector mechanism
3. By changing the number of copies defined by RC/RS, the scaling of the service corresponding to the Pod is realized.
4. Pods can be upgraded by changing the image in the RC/RS template. RS

3.7, Deployment (important concept)

Deployment is a concept introduced by Kubernetes in version 1.2, which is used to better solve pod deployment, upgrade, rollback and other issues.
RS is automatically created inside Deployment for Pod replica control. Deployment has the following advantages over RC/RS:

1. The Deployment resource object will automatically create an RS resource object to complete the deployment, modify the Deployment and release a new RS resource object to serve the new release version.
2. Deployment supports viewing the deployment progress to determine whether the deployment operation is complete.
3. Updating the Deployment will trigger the deployment to update the pod, but the update of the RC will not automatically trigger the update of the pod. RS can trigger pod updates.
4. The Deployment supports the Pause operation, and the modification to the Deployment after the pause will not trigger the release action. After the modification is completed, a new Deployment can be released through the Resume operation.
5. Deployment supports rollback operations, which can be rolled back to the previous version or to the specified release version.
6. Deployments support restart operations, which trigger updates of Pods.
7. Deployment will automatically clean up RS that is no longer needed.

3.8、Horizontal Pod Autoscaler

Horizontal Pod Autoscaler (HPA for short), its main function is to automatically scale Pod horizontally. Based on tracking and analyzing the load changes of all target Pods controlled by the specified RC/RS, it is determined whether it is necessary to adjust the number of copies of the target Pod in a targeted manner.

3.9、StatefulSet

In the Kubernetes system, Pod management objects RC, Deployment, DaemonSet, and Job are all stateless services. But in reality, many services are stateful, and StatefulSet is used to manage Pods of stateful applications. Similar to Deployment, StatefulSet also manages a group of Pods with the same definition through Label Selector. But unlike Deployment, StatefulSet maintains a unique ID for each of its Pods. Although each pod is created based on the same definition file, they are not interchangeable: each pod has a permanent ID no matter how it is scheduled.
When should StatefulSet be used:

1. Applications that require a stable, unique network identity.
2. Applications that require stable persistent storage.
3. Applications that require orderly deployment, updates, and scaling.

What are the limitations:

1. A Pod's storage must be driven by a PersistentVolume.
2. Deleting or shrinking a StatefulSet does not delete the associated storage volumes.
3. A Headless Service needs to be used to be responsible for the Pod's network identification, so a Headless Service needs to be created.
4. When a StatefulSet is deleted, the Pods it manages are not guaranteed to be deleted. It can be achieved by adjusting the number of copies to 0.

Which common applications are stateful, for example: MySQL cluster, MongoDB cluster, kafka cluster, etc.

3.10、DaemonSet

A DaemonSet ensures that all (or some) nodes run a replica of a Pod. When nodes join the cluster, a Pod will be added for them. These Pods are also recycled when a node is removed from the cluster. Deleting a DaemonSet will delete all Pods it created.

Some typical uses of DaemonSet:

• Run cluster daemons on each node
• Run a log collection daemon on each node
• Run a monitoring daemon on each node

A simple usage is to start a DaemonSet on all nodes for each type of daemon. A slightly more complex usage is to deploy multiple DaemonSets for the same kind of daemon; each with different flags and different memory, CPU requirements for different hardware types.

3.11, Service (important concept)

Service service is also one of the core resource objects in Kubernetes. Its main function is to expose applications running on a set of Pods as network services. This is actually the microservice we often mention. Define the access entry address of a service through the service resource object. By accessing this entry, the front-end application can access a group of cluster instances composed of Pod copies behind it. The target Pods set targeted by the service is usually determined through the Label Selector, as shown in the figure below:

Once the Service is defined, it is assigned an unchangeable Cluster IP, which will not change during the entire life cycle of the Service.

3.12、Job

A job is a work task, and a job will create one or more Pods to perform work tasks. The Job will track and record the number of successfully completed Pods. When the number of successfully completed Pods reaches the specified number of successes, the Job ends. When the Pod fails during execution, the Job will create a new Pod to replace the Pod. Deleting a Job will clear all created Pods. The operation of suspending the Job will delete all active Pods of the Job until the Job is resumed again. Job is usually a single task. If you need to run a scheduled job, you should use CronJob.

3.13、Volume

Volume is an object abstracted by k8s, which is used to solve the problem of container runtime in Pod, file storage and multi-container data sharing. Pods can use any number of Volume types concurrently. The lifecycle of a temporary volume is the same as that of a pod, but the lifecycle of a persistent volume has nothing to do with a pod. Kubernetes destroys ephemeral volumes when the Pod no longer exists; however, Kubernetes does not destroy persistent volumes. For any type of volume in a given Pod, data will not be lost during container restarts, which means that the life cycle of the data volume is independent of the container. The core of Volume is a directory, which may contain data, and the containers in the Pod can access the data in the directory. The specific Volume type used will determine how the directory is formed, what medium is used to store data, and the content stored in the directory.

Volume supports multiple Volume types, such as: cephfs, configMap, csi, downwardAPI, emptyDir, fc(fibre channel), gcePersistentDisk, glusterfs, hostPath, iscsi, local, nfs, persistentVolumeClaim, projected, secret, rbd, etc.

The use of Volume is relatively simple. Usually, we declare a Volume on the Pod, then reference the Volume in the container and mount it to a certain directory of the container, for example:

template：
  metadata：
	labels:
	  app: myapp
  spec:
	volumes:
	  - name: datavol
		emptyDir: {
    
    }
	containers:
	- name: nginx
	  image: nginx
	  volumeMounts:
		- mountPath: /mydata
		  name: datavol

3.14、Persistent Volume

A persistent volume (PersistentVolume, PV) is a piece of storage in the cluster, which can be provisioned in advance by the administrator, or dynamically provisioned using a storage class (Storage Class). Persistent volumes are cluster resources, just like nodes are cluster resources. PV persistent volumes are the same as ordinary volumes, and they are also implemented using volume plug-ins, except that they have independent life cycles.

Pod uses PersistentVolumeClaim (PVC) to claim PV as a storage volume. The cluster will find its bound PV through the PVC, and mount the PV to the Pod.

The following is a YAML definition file for an NFS type PV, declaring a storage space of 8Gi:

apiVersion: v1
kind: PersistentVolume
metadata:
  name:pv0001
spec:
  capacity:
	storage: 8Gi
  accessModes:
	- ReadWriteOnce
  nfs:
	path: /somepath
	server: 192.168.0.106

PV's accessModes property:

1. ReadWriteOnce: Read and write permissions, only allowed to be mounted by a single Node.
2. ReadOnlyMany: Read-only permission, allowing multiple Node mounts.
3. ReadWriteMany: Read and write permissions, allowing multiple Nodes to mount.

If a Pod needs to apply for a certain type of PV, you need to define a PersistentVolumeClaim object first:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
	- ReadWriteOnce
  resources:
	requests:
	  storage: 8Gi

Then, just refer to the PVC in the Pod's Volume definition:

volumes:
  - name: mypd
	persistentVolumeClaim:
	  claimName: myclaim

Finally, let’s talk about the status of PV; the status of PV includes the following:

1. Available: idle state.
2. Bound: Bound to a PVC.
3. Released: The corresponding PVC has been deleted, but the resource has not been recycled by the cluster.
4. Failed: PV automatic recovery failed.

3.15, Namespace (an important concept)

Namespace (namespace) is another very important concept in the Kubernetes system, which mainly provides resource isolation. Resources in the same cluster can be divided into isolated groups through namespaces. Resource names under a unified namespace must be unique, but resource names under different namespaces can be the same. The role of the namespace is only for those resource objects with a namespace, such as:
Deployment, service, pod, rc, etc. Not applicable to cluster objects, such as: Node, namespace, PV, etc.

3.16、Annotation

Annotation (annotation) is similar to Label, and it is also defined in the form of key/value key-value pairs. The difference is that Label defines the metadata of the Kubernetes object and is used for Label Selector. Annotation is additional information arbitrarily defined by the user, so that external tools can find it easily.

3.17、ConfigMap

ConfigMap is used to save the data of non-confidential configuration items required by other resource objects in key-value pairs.
For example: configuration files for applications. In this way, all configuration items used by the cluster can be managed centrally.

3.18、Secret

Secret is similar to ConfigMap, but Secret is specially used to store confidential data.

Summarize

1. Pod is a very important concept of Kubernetes, just like the importance of containers to docker; the difference between Pod and containers: a Pod can contain multiple containers, a Pod must have a root container, and network and data volumes are hung on the root container Down.
2. Label is similar to the label in WeChat friends. It is used for resource management, and it is used for resource management in kubernetes. For example, the Label in the service can be used as a basis for load balancing.
3. RC (replication controller) is no longer recommended. It can be deployed using deployment, which has more advantages than RC.
4. The replica set (referred to as RS) is an upgraded version of RC, but it is usually not used explicitly, and it is automatically used by the kubernetes system.
5. deployment is used to deploy stateless applications; stateful applications are deployed using StatefulSet.