前言
上一节说到间接创立的 Pod 没有自愈性能。
应用控制器创立的 Pod 能力故障自愈,那么什么是控制器呢。
能够这么了解,容器是赤裸裸的箱子,Pod 把箱子进行了包装以不便 K8S 挂载。
那么 K8S 一次挂载几个 Pod,如何挂载,这些信息都由控制器来指定和治理。
控制器蕴含很多种,本节实际 Deployment 控制器。
更新历史
- 20200601 - 初稿 - 左程立
- 原文地址 - https://blog.zuolinux.com/2020/06/01/about-controller-deployment.html
Deployment 控制器
咱们通过 Deployment 控制器来公布 Pod
# cat nginx.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deploymentspec: selector: matchLabels: app: nginx replicas: 2 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
该例中:
- 创立名为 nginx-deployment 的控制器,metadata.name 指定
- 创立 2 个复制的 Pod,spec.replicas 指定
- spec.selector 指定 Deployment 如何抉择治理的 Pod
- spec.template.metadata.lables 指定了 Pod 的标签
- spec.template.spec.containers 指定了容器的相干信息
公布 Deployment
[root@master01 ~]# kubectl apply -f nginx.yaml
查看 Deployment
[root@master01 ~]# kubectl get deploymentNAME READY UP-TO-DATE AVAILABLE AGEnginx-deployment 2/2 2 2 36m
查看正本状况
[root@master01 ~]# kubectl get rsNAME DESIRED CURRENT READY AGEnginx-deployment-5bf87f5f59 2 2 2 39m
DESIRED 冀望状态
CURRENT 理论状态
查看 Pod 信息
[root@master01 ~]# kubectl get pods --show-labelsNAME READY STATUS RESTARTS AGE LABELSnginx-deployment-5bf87f5f59-4phlc 1/1 Running 0 40m app=nginx,pod-template-hash=5bf87f5f59nginx-deployment-5bf87f5f59-jrzxj 1/1 Running 0 40m app=nginx,pod-template-hash=5bf87f5f59
参数 pod-template-hash=5bf87f5f59 的意义:
通过对 ReplicaSet 的 PodTemplate 进行哈希解决,确保 Deployment 的子 ReplicaSets 不重叠抵触。
控制器工作原理
控制器始终处于有限循环中,获取所治理对象的冀望状态和理论状态。
在下面的 nginx.yaml 例子中:
- replicas: 2 是 Pod 的冀望状态
- Deployment 控制器一直的从 ETCD 中获取目前 Pod 的理论状态
- 如果理论状态小于2,那么创立新的 Pod,如果理论状态大于2,那么删除多余的 Pod
在 github 的 kubernetes/kubernetes/tree/master/pkg/controller 目录下,蕴含了 K8S 的各种控制器,Deployment 是其中的一种。
更新
更改 nginx.yaml 的 spec.template 中内容即可
如更新 image: nginx:1.7.9 为 image: nginx:1.9.1
而后 kubectl apply -f nginx.yaml
回滚
查看历史版本
[root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deploymentdeployment.apps/nginx-deployment REVISION CHANGE-CAUSE1 <none>2 <none>3 <none>
查看具体批改记录
[root@master01 ~]# kubectl rollout history deployment.v1.apps/nginx-deployment --revision=1deployment.apps/nginx-deployment with revision #1Pod 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=2deployment.apps/nginx-deployment with revision #2Pod 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=3deployment.apps/nginx-deployment with revision #3Pod 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>
回滚到指定版本 --to-revision=xxx
[root@master01 ~]# kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=1
回滚到上次批改
kubectl rollout undo deployment.v1.apps/nginx-deployment
将每次执行的命令记录到history中
[root@master01 ~]# kubectl apply -f nginx.yaml --record
结束语
Deployment 控制器能够治理 Pod,它通过操作叫做 ReplicaSet 的控制器来间接的治理 Pod。
Deployment 控制器有个毛病,它只能治理 Nginx 这样的无状态的 Pod,无奈治理如 Mysql 这样有状态的利用,有状态利用须要应用 StatefulSet 控制器来治理。
分割我
微信公众号:zuolinux_com