Today, I will continue to introduce you to the relevant knowledge of Linux operation and maintenance. The main content of this article is the Deployment controller.
1. Overview of the Deployment Controller
In the previous Kubernetes Detailed Explanation (20) - ReplicaSet Controller and Kubernetes Detailed Explanation (21) - ReplicaSet Controller Practical Application , we introduced Kubernetes' ReplicaSet controller. Today, let's introduce another Kubernetes control Device - Deployment. The Deployment controller is built on top of the ReplicaSet controller (meaning that when the Deployment controller is created, it must first create a ReplicaSet controller) , which can provide declarative updates for Pod and ReplicaSet resources.
The main responsibility of the Deployment controller is to ensure the healthy operation of Pod resources. Most of the functions of the controller are realized by calling the ReplicaSet controller. At the same time, the Deployment controller also adds some features. Most of these features are reflected in the Pod update, making the Our team's Pod update control is more granular. The features added to the Deployment controller are as follows:
1. Event and status viewing.
We can view the status of Pod updates with the help of the Deployment controller.
2. Rollback
After the Pod is upgraded, if you find that there are problems after the update and upgrade, you can roll back the Pod through Deployment control, that is, restore the Pod to the previous version.
3. Version record
Each version of the Pod upgrade can be retained, which can facilitate the rollback operation.
4. Pause and start
During the Pod upgrade process, you can pause and start at any time. In this way, only some Pods can be upgraded to achieve canary release (grayscale release).
5. Various program updates
Deployment supports two update schemes. One is Recreate, which means rebuilding the update mechanism, first completely stops and deletes the original Pod object, and then replaces it with a new version; the other is RollingUpdate, which is a rolling update mechanism, which gradually replaces, Upgrade Pods to ensure uninterrupted services.
2. Creation of Deployment Controller Resource List
Next, we will create the Deployment controller through the resource configuration list and view the effect. Create the Deployment.yaml file and write the following content:
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
namespace: default
spec:
replicas: 1
selector:
matchLabels:
controller: deployment
pod: myapp
template:
metadata:
labels:
controller: deployment
pod: myapp
spec:
containers:
- name: myapp
image: ikubernetes/myapp:v1
ports:
- name: http
containerPort: 80
The resource configuration list after the configuration is completed is as follows:
From the above configuration, it can be seen that the parameters of the Deployment controller and the ReplicaSet controller are basically the same. If you are confused about the above configuration, you can refer to the two articles mentioned in the previous article. But too much to say.
After completing the creation and writing of the resource configuration manifest file, we next execute the resource manifest configuration file to create the Deployment controller.
Excuting an order:
kubectl apply -f Deployment.yaml
Next, we execute the commands one after another:
kubectl get deployment
kubectl get replicaset
kubectl get pods
It is used to view the deployment controller, ReplicaSet controller and Pod respectively. The results are as follows:
As can be seen from the above figure, our Deployment controller was created successfully. And there is the following relationship between the Deployment controller, the ReplicaSet controller and the Pod: After the Deployment controller is created, Kubernetes will automatically create the ReplicaSet controller. The name of the controller is based on the name of the Deployment controller, followed by a random String, and the name of the Pod is based on the name of the Deployment controller, followed by a random string.
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200