明明ReplicaSet已经能够控制pod的数量了,为何还须要Deployment?nginx
简单的说,Deployment控制ReplicaSet的多个版本,ReplicaSet控制Pod个数
web
Deploymen实际上一个两层控制器,遵循一种滚动更新的方式来实升级现有的容器,这个能力的实现,依赖的就是ReplicaSet这个对象
当咱们修改了Deployment对象后,Deployment控制器会使用修改后的模板,建立一个新的ReplicaSet对象,这时候有两个RelicaSet对象,
Deployment经过控制ReplicaSet对象的pod数量来达到滚动升级的效果
例如A和B,若是最终设置的pod数都是3,经过A-1,B+1这样的方式,直到A的pod数量变为0,最终 达到了滚动升级的目的。
同时,由于存在多个ReplicaSet,让回滚成为了可能api
示例yaml文件app
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
template字段,指定了建立pod的模板
replicas指定了pod的节点数量
还有一个 type: RollingUpdate,指定了滚动升级的策略ide
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment labels: app: nginx spec: ... strategy: type: RollingUpdate rollingUpdate: maxSurge: 1 maxUnavailable: 1
查看deploymentscode
kubectl get deployments demo2 -o wide NAME READY UP-TO-DATE AVAILABLE AGE CONTAINERS IMAGES SELECTOR demo2 2/3 3 2 24d demo2 harbor.eoffcn.com/dev/demo2 workload.user.cattle.io/workloadselector=deployment-web-demo2
UP-TO-DATE:当前处于最新版本的 Pod 的个数,所谓最新版本指的是 Pod 的 Spec 部分与 Deployment 里 Pod 模板里定义的彻底一致
AVAILABLE:当前已经可用的 Pod 的个数,即:既是 Running 状态,又是最新版本,而且已经处于 Ready(健康检查正确)状态的 Pod 的个数
READY:前处于 Running 状态的 Pod 的个数/用户指望的 Pod 副本个数对象
查看历史版本blog
kubectl rollout history deployment ${name} deployment.extensions/demo2 REVISION CHANGE-CAUSE 1 <none> 2 <none> 3 <none> 4 <none>
查看指定版本get
kubectl rollout history deployment ${name} --revision=${version}
回滚到上一版本io
kubectl rollout undo deployment ${name}
回滚到指定版本
kubectl rollout undo deployment ${name} --to-revision=${version}