Deployment controller

We publish the Pod through the Deployment controller

# cat nginx.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
Copy the code

In this case:

  • Create a controller named nginx-deployment, specified by metadata.name

  • Create 2 replicas of pods, spec.replicas specified

  • How does spec. Selector specify Deployment select managed pods

  • The spec. The template. The metadata. The lables tag specifies the Pod

  • Spec. The template. The spec. Containers specifies the relevant information of the vessel

Release Deployment

[root@master01 ~]# kubectl apply -f nginx.yaml 
Copy the code

Check the Deployment

[root@master01 ~]# kubectl get deployment
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
nginx-deployment   2/2     2            2           36m
Copy the code

Viewing copies

[root@master01 ~]# kubectl get rs
NAME                          DESIRED   CURRENT   READY   AGE
nginx-deployment-5bf87f5f59   2         2         2       39m
Copy the code

DESIRED CURRENT Indicates the actual status

Viewing Pod Information

[root@master01 ~]# kubectl get pods --show-labels
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
nginx-deployment-5bf87f5f59-4phlc   1/1     Running   0          40m   app=nginx,pod-template-hash=5bf87f5f59
nginx-deployment-5bf87f5f59-jrzxj   1/1     Running   0          40m   app=nginx,pod-template-hash=5bf87f5f59
Copy the code

The pod-template-hash= 5BF87f5f59 parameter ensures that the child ReplicaSets of Deployment do not overlap by hashing the ReplicaSet PodTemplate.

Working principle of controller

The controller is always in an infinite loop, getting the expected and actual state of the managed objects.

In the nginx.yaml example above:

  • Replicas: 2 is the expected state of the Pod

  • The Deployment controller continuously gets the actual status of the current Pod from the ETCD

  • If the actual state is less than 2, create a new Pod, and if the actual state is greater than 2, delete the extra pods

In making kubernetes/kubernetes/tree/master/PKG/controller directory, contains all kinds of controller, K8S Deployment is one of them.

update

Kubectl apply -f nginx.yaml; kubectl apply -f nginx.yaml

The rollback

Viewing historical Versions

[root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deployment deployment.apps/nginx-deployment REVISION  CHANGE-CAUSE 1 <none> 2 <none> 3 <none>Copy the code

View detailed modification records

[root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deployment --revision=1 deployment.apps/nginx-deployment with revision #1 Pod Template: Labels: App =nginx pod-template-hash=5b6f47948 Containers: nginx: Image: nginx:1.7.8 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> [root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2 deployment.apps/nginx-deployment with revision #2 Pod Template: Labels: App =nginx pod-template-hash= 678645BF77 Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> [root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deployment --revision=3 deployment.apps/nginx-deployment with revision #3 Pod Template: Labels: App =nginx pod-template-hash=64d99cdfb6 Containers: nginx: Image: nginx:1.9.8 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none>Copy the code

Rollback to the specified version — to-revision= XXX

[root@master01 ~]# kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=1
Copy the code

Rollback to last modification

kubectl rollout undo deployment.v1.apps/nginx-deployment
Copy the code

Record the command executed each time in history

[root@master01 ~]# kubectl apply -f nginx.yaml --record
Copy the code

conclusion

The Deployment controller manages pods, which it indirectly manages by operating on a controller called ReplicaSet.

One disadvantage of the Deployment controller is that it can only manage stateless pods such as Nginx, not stateful applications such as Mysql, which need to be managed using the StatefulSet controller.