标签：

Pod控制器-Deployment

本章节开始，将对控制器逐个进行讲解和分析，我们先讲解最根本且最常用的控制器：Deployment！

控制器东西的分类

What is Deployment?

Deployment的更新机制

ReplicaSet

命令增补

Deployment-demo

备注

1.控制器东西的分类 1.守护进程型

1.无状态应用:非系统级应用（Nginx等）

保举使用：Deployment，ReplicaSet

2.无状态应用:系统级应用

应用场景：日志和监控收集客户端：场景就是每个node节点需要且只需要运行1个pod

保举使用：DaemonSet

3.有状态应用

应用场景：mysql、redis集群等

保举使用：statefulSet

2.非守护进程型

Job：一次性任务

Cronjob：按时任务

2. What is Deployment?

Deploymen是一个供给申明Pod更新和Reolica Sets状态的控制器。换句话说：

你在deployment东西中描述了一个期望状态，接着deployment控制器会让当前状态和用户期望状态连结一致。好比我期望运行2个nginx Pod，当一个Pod因为不成抗因素下线的时候deployment控制器就会按照用户期望的状态再启动一个nginx pod。

第二章节的kubernetes集群架构里，我说过tomcat和redis是通过相关service进行"连接"的，这其实只是为了大家能更简单的理解。其实serice会去找到对应的deployment，然后deployment按照申明的Replica Sets的配置，控制对应Pod容器的数量和状态。

3.Deployment的更新机制

你可以发明Deployment的更新机制是基于滚动更新的，具体挨次如下：

首先，创建一个新的RS控制器，版本为v2；

接着将旧控制器的pod陆续下线，同时新的RS控制器同步上线对应Pod；

Pod更新完成后，弃用旧的RS控制器，滚动颁布就此完成。

你可以使用kubectl get pod -o wide -w不雅察看pod滚动更新情况，可以使用kubectl get rs -o wide不雅察看RS控制器的名字、状态等信息。

你也可以使用pause命令实现基于deployment的金丝雀颁布计谋。

这里我增补了一个RS控制器状态，你可以不雅察看发明，各控制器的定名、期望状态、当前状态和就绪状态。

#使用命令检察rs控制器的历史版本 [[email protected] mainfasts]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR myapp-67f698f887 0 0 0 53m myapp nginx:1.16 app=myapp,pod-template-hash=67f698f887,rel=stable myapp-7c488c6f44 5 5 5 48m myapp nginx:1.17 app=myapp,pod-template-hash=7c488c6f44,rel=stable myapp-98f644994 0 0 0 46m myapp nginx:1.15 app=myapp,pod-template-hash=98f644994,rel=stable ngx-new-cb79d555 2 2 2 2d22h nginx nginx app=ngx-new,pod-template-hash=cb79d555 1.滚动颁布和回滚实战

1) 我们首先编纂deployment-nginx.yaml，并apply -f，颁布nginx1.10版本。
此中我们给定了滚动计谋：最多新增1个(maxSurge)最少下线1个(maxUnavailable)

第一次颁布的时候是新增1个，下线2个

apiVersion: apps/v1 kind: Deployment metadata: name: deploy-nginx spec: replicas: 3 minReadySeconds: 10 strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 1 type: RollingUpdate selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.10-alpine ports: - containerPort: 80 name: http readinessProbe: periodSeconds: 1 httpGet: path: / port: http

2) 接着，我们通过改削deployment-nginx.yaml的image: nginx:1.10-alpine版本为1.13，颁布并不雅察看。可以发明deployment对应的rs控制器逐步应用至deploy-nginx-567c45c74（nginx:1.13-alpine）

[[email protected] chapter5]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR deploy-nginx-567c45c748 2 2 0 51s nginx nginx:1.13-alpine app=nginx,pod-template-hash=567c45c748 deploy-nginx-5745bb45d7 2 2 2 7m2s nginx nginx:1.10-alpine app=nginx,pod-template-hash=5745bb45d7 deploy-nginx-67f876bcb6 0 0 0 5m51s nginx nginx:1.11-alpine app=nginx,pod-template-hash=67f876bcb6 [[email protected] chapter5]# kubectl get rs -o wide NAME DESIRED CURRENT READY AGE CONTAINERS IMAGES SELECTOR deploy-nginx-567c45c748 3 3 2 2m40s nginx nginx:1.13-alpine app=nginx,pod-template-hash=567c45c748 deploy-nginx-5745bb45d7 0 0 0 8m51s nginx nginx:1.10-alpine app=nginx,pod-template-hash=5745bb45d7 deploy-nginx-67f876bcb6 0 0 0 7m40s nginx nginx:1.11-alpine app=nginx,pod-template-hash=67f876bcb6

3) 同时，我们可以检察历史版本，，第4条是我们最新的版本。由于前几次颁布没有新增--record=true字段，所以显示为none

[[email protected] chapter5]# kubectl rollout history deployment/deploy-nginx deployment.apps/deploy-nginx REVISION CHANGE-CAUSE 2 <none> 3 <none> 4 kubectl apply --filename=deploy-nginx.yaml --record=true