k8s study notes (5): Detailed explanation of k8s controller

1. How to create a pod

In kubernetes, Pods can be divided into two categories according to how they are created:

• Autonomous: A Pod created directly by kubernetes. This Pod will disappear after being deleted and will not be rebuilt.
• Controller-created pod: A Pod created through a Pod controller. This Pod will be automatically rebuilt after being deleted.

The Pod controller is the middle layer that manages Pods. After using the Pod controller, we only need to tell the Pod controller how many and what kind of Pods we want, and it will create Pods that meet the conditions and ensure that each The Pod is in the state expected by the user. If the Pod fails during operation, the controller will restart or recreate the Pod based on the specified policy.

2. Workload resources

Workloads are applications running on Kubernetes

In Kubernetes, whether your workload consists of a single component or multiple components working together, you can run it in a set of Pods. In Kubernetes, Pod represents a collection of running containers on the cluster .

Load resources to manage a group of Pods for users. These load resources configure the controller to ensure that the correct number of Pods of the correct type and running state is consistent with the state specified by the user.

3. Type of controller

• ReplicaSet 's main function is to ensure that a certain number of Pods can run normally. It will continue to monitor the running status of these Pods. Once a Pod fails, it will be restarted or rebuilt. At the same time, it also supports the expansion and contraction of the number of Pods and the upgrade of version images.
• Deployment does not directly manage Pods, but indirectly manages Pods by managing ReplicaSet, that is: Deployment manages ReplicaSet, and ReplicaSet manages Pods. Therefore, the function of Deployment is more powerful than ReplicaSet, including all functions of ReplicaSet, including stop and continue of release, rolling version update and version rollback.
• DaemonSet can ensure that a copy is running on each (or designated) node in the cluster. It is generally suitable for scenarios such as log collection and node monitoring . In other words, if the functions provided by a Pod are node-level (each node requires and only needs one), then this type of Pod is suitable to be created using a DaemonSet type controller.
• Job , which can ensure that a specified number of pods complete one-time tasks in batches and batch scheduling
• CronJob uses the Job controller as its control object and uses it to manage Pod resource objects. The job tasks defined by the Job controller will be executed immediately after the controller resource is created, but CronJob can be used as a periodic task similar to the Linux operating system. The method of job planning controls the running time point and the way of repeated operation. In other words, CronJob can repeatedly execute the Job task at a specific point in time.
• Horizontal Pod Autoscaler can automatically adjust the number of Pods according to the cluster load to achieve peak shaving and valley filling.
• StatefulSet , manages stateful applications.

ReplicaSet

Its main function is to ensure that a certain number of Pods can run normally. It will continue to monitor the running status of these Pods . Once a Pod fails, it will be restarted or rebuilt. At the same time, it also supports the expansion and contraction of the number of Pods and the upgrade of version images.

Deployment

In order to better solve the problem of service orchestration, kubernetes introduced the Deployment controller starting from version v1.2 . It is worth mentioning that the Deployment controller does not directly manage Pods, but indirectly manages Pods by managing ReplicaSet , that is: Deployment manages ReplicaSet, and ReplicaSet manages Pods. Therefore, the function of Deployment is more powerful than ReplicaSet.

The main functions are as follows:

• Supports all functions of ReplicaSet.
• Supports stop and continue publishing.
• Supports version rolling update and version rollback.

Horizontal Pod Autoscaler

We can already kubectl scaleachieve Pod expansion and contraction by manually executing commands, but this obviously does not meet the positioning goal of kubernetes - automation and intelligence. Kubernetes hopes to automatically adjust the number of Pods by monitoring the usage of Pods , so a controller like HPA was created.

HPA can obtain the utilization of each Pod, then compare it with the indicators defined in HPA, calculate the specific value that needs to be scaled, and finally adjust the number of Pods. In fact, HPA, like the previous Deployment, is also a Kubernetes resource object. It tracks and analyzes the load changes of the target Pod to determine whether it is necessary to adjust the number of copies of the target Pod in a targeted manner.

DaemonSet

The DaemonSet type controller can ensure that a copy is running on each (or designated) node in the cluster , and is generally suitable for scenarios such as log collection and node monitoring . In other words, if the functions provided by a Pod are node-level (each node requires and only needs one), then this type of Pod is suitable to be created using a DaemonSet type controller.

Features of DaemonSet controller:

• Each time a node is added to the cluster, the specified Pod replica will also be added to the node.
• Pods are also garbage collected when nodes are removed from the cluster.
  

Cronjob

The CronJob controller uses the Job controller as its control object and uses it to manage Pod resource objects . The job tasks defined by the Job controller will be executed immediately after the controller resource is created, but CronJob can be executed in a periodic manner similar to the Linux operating system. The method of task job planning controls the running time point and the way of repeated operation. In other words, CronJob can repeatedly execute the Job task at a specific point in time.

StatefulSet

• Stateless application
  • Think pods are all the same
  • Scale and expand at will
  • No need to consider which node to run on
  • No order required
• Stateful application
  • There are order requirements
  • Pods are independent and different, ensuring the pod startup sequence and uniqueness
  • You need to consider which pod to run on
  • Requires installation sequence for scaling and expansion
• StatefulSet is a load management controller provided by Kubernetes to manage stateful applications.
• StatefulSet deployment requires HeadLinessService (headless service)

Use HeadLinessService (headless service)

• When using Deployment, each Pod name is not in order and is composed of random strings. Therefore, the pods at this time are in no order. However, in StatefulSet, pods are required to be in order. Each pod cannot be Replace it at will. The pod name remains unchanged after the pod is rebuilt.
• The P of the Pod changes, so it is identified by the pod name. The pod name is the unique identification code of the pod. The headless service can give each pod a unique name.