官方参考:https://kubernetes.io/zh/docs/concepts/workloads/controllers/deployment/
https://www.kubernetes.org.cn/deployment
Deployments
Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法,用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括:
- 定义Deployment来创建Pod和ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续Deployment
你只需要在Deployment中描述你想要的目标状态是什么,Deployment controller就会帮你将Pod和Replica Set的实际状态改变到你的目标状态。你可以定义一个全新的Deployment,也可以创建一个新的替换旧的Deployment。
一个典型的用例如下
- 使用Deployment来创建ReplicaSet。ReplicaSet在后台创建pod。检查启动状态,看它是成功还是失败。
- 然后,通过更新Deployment的PodTemplateSpec字段来声明Pod的新状态。这会创建一个新的ReplicaSet,Deployment会按照控制的速率将pod从旧的ReplicaSet移动到新的ReplicaSet中。
- 如果当前状态不稳定,回滚到之前的Deployment revision。每次回滚都会更新Deployment的revision。
- 扩容Deployment以满足更高的负载。
- 暂停Deployment来应用PodTemplateSpec的多个修复,然后恢复上线。
- 根据Deployment 的状态判断上线是否hang住了。
- 清除旧的不必要的ReplicaSet。
创建Deployment
下面是 Deployment 示例。创建一个 ReplicaSet 展开三个 nginx
Pods:
该示例为官方示例下载地址是
https://raw.githubusercontent.com/kubernetes/website/master/content/zh/examples/controllers/nginx-deployment.yaml
# cat nginx-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: labels: app: nginx name: nginx-deployment spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - image: nginx:1.15.4 name: nginx ports: - containerPort: 80
也可以通过以下命令生成该yaml文档然后修改
# kubectl create deployment nginx-deployment --image=nginx:1.15.4 --dry-run -o yaml apiVersion: apps/v1 kind: Deployment metadata: creationTimestamp: null labels: app: nginx-deployment name: nginx-deployment spec: replicas: 1 selector: matchLabels: app: nginx-deployment strategy: {} template: metadata: creationTimestamp: null labels: app: nginx-deployment spec: containers: - image: nginx:1.15.4 name: nginx resources: {} status: {}
在该例中
- 创建名为nginx-deployment的Deployment,由metadata.name字段指示
- Deployment创建3个复制的Pods,由spec.replicas字段指示,该字段可以没有默认即为1
- selector字段定义Deployment如何查找要管理的Pods。在这种情况下只需要在Pod模板(app:nginx)中定义的标签。
注意:`matchLabels` 字段是 {key,value} 的映射。单个 {key,value}在 `matchLabels` 映射中的值等效于 `matchExpressions` 的元素,其键字段是“key”,运算符为“In”,值数组仅包含“value”。所有要求,从 `matchLabels` 和 `matchExpressions`,必须满足才能匹配。
- template字段包含以下子字段
- Pod使用labels字段标记为app:nginx
- template.spec字段指示Pod运行一个容器nginx
- 创建一个容器并使用name字段将其命名为nginx
通过运行以下命令创建Deployment
kubectl apply -f nginx-deployment.yaml
注意:将kubectl的 —record 的flag设置为 true可以在annotation中记录当前命令创建或者升级了该资源。这在未来会很有用,例如,查看在每个Deployment revision中执行了哪些命令。
--record示例如下
运行kubectl get deployments
以检查 Deployment 是否已创建。输出以下内容:
# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 48s
显示以下字段
`READY` 3/3左边3是真正运行的副本数右边3是期望的副本数即replicas定义的副本数。 `UP-TO-DATE`显示已更新以实现期望状态的副本数。 `AVAILABLE`显示应用程序可供用户使用的副本数。 `AGE` 显示应用程序运行的时间量。
要查看Deployment创建的ReplicaSet(rs),运行kubectl get rs输出
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-67656986d9 3 3 3 108s
请注意, ReplicaSet 的名称始终被格式化为`[DEPLOYMENT-NAME]-[RANDOM-STRING]`。随机字符串是随机生成并使用 pod-template-hash 作为种子
要查看每个Pod自动生成的标签,运行kubectl get pods --show-labels输出
# kubectl get pods --show-labels NAME READY STATUS RESTARTS AGE LABELS nginx-deployment-67656986d9-996kk 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9 nginx-deployment-67656986d9-fgdwz 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9 nginx-deployment-67656986d9-j8jt8 1/1 Running 0 3m35s app=nginx,pod-template-hash=67656986d9
刚创建的Replica Set将保证总是有3个nginx的pod存在。并且创建的Pod名为[DEPLOYMENT-NAME]-[pod-template-hash]-[RANDOM-STRING]
注意: 你必须在Deployment中的selector指定正确pod template label(在该示例中是 app = nginx),不要跟其他的controller搞混了(包括Deployment、Replica Set、Replication Controller等)。Kubernetes本身不会阻止你这么做,如果你真的这么做了,这些controller之间会相互打架,并可能导致不正确的行为。
Pod-template-hash 标签
注意:不要更改此标签
Deployment 控制器将 pod-template-hash
标签添加到 Deployment 创建或使用的每个 ReplicaSet 。
此标签可确保 Deployment 的子 ReplicaSets 不重叠。它通过对 ReplicaSet 的 PodTemplate
进行哈希处理,并使用生成的哈希值添加到 ReplicaSet 选择器、Pod 模板标签,并在 ReplicaSet 可能具有的任何现有 Pod 中。
更新Deployment
注意: Deployment的rollout当且仅当Deployment的pod template(例如.spec.template)中的label更新或者镜像更改时被触发。其他更新,例如扩容Deployment不会触发rollout。
安装以下步骤更新Deployment
首先修改yaml把nginx版本修改成1.7.9
应用一下各项nginx Pods,使用nginx:1.9.1镜像,而不是nginx:1.7.9
# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1 deployment.apps/nginx-deployment image updated
说明:设置更新Deployment名为nginx-deployment镜像的镜像为nginx:1.9.1
也可以使用edit
命令来编辑Deployment,修改 .spec.template.spec.containers[0].image
,将nginx:1.7.9
改写成nginx:1.9.1
。
kubectl edit deployment/nginx-deployment
修改完输出
deployment.apps/nginx-deployment edited
查看rollout的状态,只要执行:
# kubectl rollout status deployment/nginx-deployment deployment "nginx-deployment" successfully rolled out
rollout成功后查看deployment
# kubectl get deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 9m37s
UP-TO-DATE的replica的数目已经达到了配置中要求的数目。
CURRENT的replica数表示Deployment管理的replica数量,AVAILABLE的replica数是当前可用的replica数量。
我们通过执行kubectl get rs
可以看到Deployment更新了Pod,通过创建一个新的Replica Set并扩容了3个replica,同时将原来的Replica Set缩容到了0个replica。
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 0 0 0 12m nginx-deployment-56f8998dbc 3 3 3 9m6s
执行 get pods
只会看到当前的新的pod:
# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-56f8998dbc-8j49x 1/1 Running 0 5m25s nginx-deployment-56f8998dbc-fpzwt 1/1 Running 0 5m26s nginx-deployment-56f8998dbc-r2wvp 1/1 Running 0 5m28s
下次更新这些Pod的时候,只需要更新Deployment中pod的template即可
Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下,它确保至少 75%所需 Pods 运行(25%最大不可用)。
Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下,它可确保最多增加 25% 期望 Pods 数(25%最大增量)。
例如,如果仔细查看上述 Deployment ,将看到它首先创建了一个新的 Pod,然后删除了一些旧的 Pods,并创建了新的 Pods。它不会杀死老 Pods,直到有足够的数量新的 Pods 已经出现,并没有创造新的 Pods,直到足够数量的旧 Pods 被杀死。它确保至少 2 个 Pods 可用,并且总共最多 4 个 Pods 可用。
获取Deployment更多信息
# kubectl describe deployments nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Fri, 20 Mar 2020 16:01:54 +0800 Labels: app=nginx Annotations: deployment.kubernetes.io/revision: 2 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d... Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.9.1 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: nginx-deployment-56f8998dbc (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 53s deployment-controller Scaled up replica set nginx-deployment-54f57cf6bf to 3 Normal ScalingReplicaSet 8s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 1 Normal ScalingReplicaSet 6s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 2 Normal ScalingReplicaSet 6s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 2 Normal ScalingReplicaSet 5s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 1 Normal ScalingReplicaSet 5s deployment-controller Scaled up replica set nginx-deployment-56f8998dbc to 3 Normal ScalingReplicaSet 3s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 0
可以看到,当第一次创建 Deployment 时,它创建了一个 ReplicaSet (nginx-deployment-54f57cf6bf)并将其直接扩展至 3 个副本。更新 Deployment 时,它创建了一个新的 ReplicaSet (nginx-deployment-56f8998dbc),并将其扩展为 1,然后将旧 ReplicaSet 缩小到 2,以便至少有 2 个 Pod 可用,并且最多创建 4 个 Pod。然后,它继续向上和向下扩展新的和旧的 ReplicaSet ,具有相同的滚动更新策略。最后,将有 3 个可用的副本在新的 ReplicaSet 中,旧 ReplicaSet 将缩小到 0。
Rollover(多个rollout并行)
每当Deployment controller观测到有新的Deployment被创建时,如果没有已存在的ReplicaSet来创建期望个数的Pod的话,就会创建一个新的ReplicaSet来做这件事。如果更新了Deployment,则控制其标签的Pods的现有ReplicaSet匹配.spec.selector但是template跟.spec.tmplate不匹配的Pod缩容。最终,新的ReplicaSet将会扩容出.spec.replicas
指定数目的Pod,旧的Replica Set会缩容到0。
如果你更新了一个的已存在并正在进行中的Deployment,每次更新Deployment都会创建一个新的Replica Set并扩容它,同时回滚之前扩容的Replica Set——将它添加到旧的Replica Set列表,开始缩容。
例如,假设创建一个 Deployment 以创建 nginx:1.7.9
的 5 个副本,然后更新 Deployment 以创建 5 个 nginx:1.9.1
的副本,而此时只有 3 个nginx:1.7.9
的副本已创建。在这种情况下, Deployment 会立即开始杀死3个 nginx:1.7.9
Pods,并开始创建 nginx:1.9.1
Pods。它不等待 nginx:1.7.9
的 5 个副本创建完毕再更新新的副本。
使用标签选择器进行更新
通常不鼓励更新标签选择器,建议提前规划选择器。在任何情况下,如果需要执行标签选择器更新,请格外小心,并确保已掌握所有的含义。
注意: 在 API 版本 apps/v1 中, Deployment 标签选择器在创建后是不可变的。
- 选择器添加还需要使用新标签更新 Deployment 规范中的 Pod 模板标签,否则将返回验证错误。此更改是非重叠的,这意味着新的选择器不选择使用旧选择器创建的 ReplicaSets 和 Pod,从而导致弃用所有旧 ReplicaSets 和创建新的 ReplicaSet 。
- 选择器更新更改选择器键中的现有值 – 导致发生与添加相同的行为。
- 选择器删除从 Deployment 选择器中删除现有密钥 – 不需要在Pod 模板标签做任意更改。现有 ReplicaSets 不会孤立,并且不会创建新的 ReplicaSet ,但请注意,已删除的标签仍然存在于任何现有的 Pods 和 ReplicaSets 中。
回滚Deployment
有时,可能需要回滚 Deployment ;例如,当 Deployment 不稳定时,例如循环崩溃。
默认情况下,kubernetes会在系统中保存前两次的Deployment的rollout历史记录,以便你可以随时会退(你可以修改revision history limit
来更改保存的revision数)
注意: 只要Deployment的rollout被触发就会创建一个revision。也就是说当且仅当Deployment的Pod template(如.spec.template)被更改,例如更新template中的label和容器镜像时,就会创建出一个新的revision。
其他的更新,比如扩容Deployment不会创建revision——因此我们可以很方便的手动或者自动扩容。
例如修改副本数由3修改成5再查看revision是没有新的revision的
# kubectl rollout history deployment/nginx-deployment --record deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 <none>
假设我们在更新Deployment的时候犯了一个拼写错误,将镜像的名字写成了nginx:1.91
,而正确的名字应该是nginx:1.9.1
:
# kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record deployment.apps/nginx-deployment image updated
Rollout将会卡住
# kubectl rollout status deployment nginx-deployment Waiting for deployment "nginx-deployment" rollout to finish: 1 out of 3 new replicas have been updated...
按住Ctrl-C停止上面的rollout状态监控。
查看ReplicaSet
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 3 3 3 5m20s nginx-deployment-84fdd4f88c 1 1 0 2m
查看创建的 Pod,看到由新 ReplicaSet 创建的 1 个 Pod 卡在镜像拉取循环中。
# kubectl get pod NAME READY STATUS RESTARTS AGE nginx-deployment-54f57cf6bf-67bhs 1/1 Running 0 6m1s nginx-deployment-54f57cf6bf-dgrw7 1/1 Running 0 6m43s nginx-deployment-54f57cf6bf-n5mjc 1/1 Running 0 6m43s nginx-deployment-84fdd4f88c-cmzw6 0/1 ImagePullBackOff 0 3m23s
注意,Deployment controller会自动停止坏的rollout,并停止扩容新的Replica Set。
获取deploym描述信息
# kubectl describe deployment nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Fri, 20 Mar 2020 16:51:44 +0800 Labels: app=nginx Annotations: deployment.kubernetes.io/revision: 2 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{},"labels":{"app":"nginx"},"name":"nginx-deployment","namespace":"d... Selector: app=nginx Replicas: 3 desired | 1 updated | 4 total | 3 available | 1 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.91 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True ReplicaSetUpdated OldReplicaSets: nginx-deployment-54f57cf6bf (3/3 replicas created) NewReplicaSet: nginx-deployment-84fdd4f88c (1/1 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 9m34s deployment-controller Scaled up replica set nginx-deployment-54f57cf6bf to 3 Normal ScalingReplicaSet 8m52s deployment-controller Scaled up replica set nginx-deployment-54f57cf6bf to 5 Normal ScalingReplicaSet 6m45s deployment-controller Scaled down replica set nginx-deployment-54f57cf6bf to 3 Normal ScalingReplicaSet 6m14s deployment-controller Scaled up replica set nginx-deployment-84fdd4f88c to 1
为了修复这个问题,我们需要回退到稳定的Deployment revision。
检查升级历史记录
注意:检查历史记录需要在创建的Deployment的时候加了参数--record否则历史记录只记录version号,记录历史命令为none
# kubectl rollout history deployment/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 kubectl apply --filename=nginx-deployment.yaml --record=true 2 kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true
查看修改历史的详细信息,查看version为2的详细信息
# kubectl rollout history deployment/nginx-deployment --revision=2 deployment.apps/nginx-deployment with revision #2 Pod Template: Labels: app=nginx pod-template-hash=84fdd4f88c Annotations: kubernetes.io/change-cause: kubectl set image deployment/nginx-deployment nginx=nginx:1.91 --record=true Containers: nginx: Image: nginx:1.91 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none>
回滚到上一次的修改
# kubectl rollout undo deployment/nginx-deployment deployment.apps/nginx-deployment rolled back
或者,可以通过使用 `--to-revision` 来回滚到特定修改版本:
# kubectl rollout undo deployment/nginx-deployment --to-revision=2 deployment.apps/nginx-deployment rolled back
检查回滚是否成功Deployment是否正常运行
# kubectl get deployment nginx-deployment NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 8m19s
获取Deployment描述信息
# kubectl describe deployment nginx-deployment Name: nginx-deployment Namespace: default CreationTimestamp: Fri, 20 Mar 2020 17:07:51 +0800 Labels: app=nginx Annotations: deployment.kubernetes.io/revision: 5 kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"kubernetes.io/change-cause":"kubectl apply --filename=nginx-deploy... kubernetes.io/change-cause: kubectl apply --filename=nginx-deployment.yaml --record=true Selector: app=nginx Replicas: 3 desired | 3 updated | 3 total | 3 available | 0 unavailable StrategyType: RollingUpdate MinReadySeconds: 0 RollingUpdateStrategy: 25% max unavailable, 25% max surge Pod Template: Labels: app=nginx Containers: nginx: Image: nginx:1.7.9 Port: 80/TCP Host Port: 0/TCP Environment: <none> Mounts: <none> Volumes: <none> Conditions: Type Status Reason ---- ------ ------ Available True MinimumReplicasAvailable Progressing True NewReplicaSetAvailable OldReplicaSets: <none> NewReplicaSet: nginx-deployment-54f57cf6bf (3/3 replicas created) Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ScalingReplicaSet 9m25s deployment-controller Scaled up replica set nginx-deployment-54f57cf6bf to 3 Normal ScalingReplicaSet 3m49s (x2 over 9m17s) deployment-controller Scaled up replica set nginx-deployment-84fdd4f88c to 1 Normal ScalingReplicaSet 2m35s (x2 over 5m54s) deployment-controller Scaled down replica set nginx-deployment-84fdd4f88c to 0
你可以通过设置.spec.revisonHistoryLimit
项来指定deployment最多保留多少revison历史记录。默认的保留2次revision;如果将该项设置为0,Deployment就不允许回退了。
缩放Deployment
可以使用如下指令缩放 Deployment
# kubectl scale deployment/nginx-deployment --replicas=10 deployment.apps/nginx-deployment scaled
假设你的集群中启用了horizontal pod autoscaling,你可以给Deployment设置一个autoscaler,基于当前Pod的CPU利用率选择最少和最多的Pod数。
kubectl autoscale deployment/nginx-deployment --min=10 --max=15 --cpu-percent=80
比例缩放
RollingUpdate Deployment支持同时运行一个应用的多个版本。当你活着autoscaler扩容RollingUpdate Deployment的时候,正在中途的rollout(进行中或者已经暂停的),为了降低风险,Deployment controller将会平衡已存在的活动中的ReplicaSets(有Pod的ReplicaSets)和新加入的replicas。这被称为比例扩容。
例如,你真在运行的10个ReplicaSet的Deployment 。maxSurge=3,maxUnavailable=2即最多增加为3 最大不可用为2
maxSurge和maxUnavailable默认百分百为25% 可以编辑修改如此例副本数为10则maxSurge修改为30% maxUnavailable修改为20%
查看Deployment包含10个ReplicaSet修改参数以后maxSurge=3,maxUnavailable=2。
# kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 10/10 10 10 17m
更新了一个镜像,而在集群内部无法解析
# kubectl set image deploy/nginx-deployment nginx=ngina:sametag deployment.apps/nginx-deployment image updated
镜像更新启动了一个包含ReplicaSet 名称为nginx-deployment-55866c9bf7的rollout,但是它被阻塞了,因为前面提到的maxUnavailable最大不可用为2最大增加maxSurge为3所以新的ReplicaSet有5个Pod阻塞了
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 8 8 8 18m nginx-deployment-55866c9bf7 5 5 0 14m
查看Pod
然后发起了一个新的Deployment扩容请求。autoscaler将Deployment的repllica数目增加到了15个。Deployment controller需要判断在哪里增加这5个新的replica。如果我们没有用比例扩容,所有的5个replica都会加到一个新的ReplicaSet中。如果使用比例扩容,新添加的replica将传播到所有的ReplicaSet中。大的部分加入replica数最多的ReplicaSet中,小的部分加入到replica数少的ReplciaSet中。0个replica的ReplicaSet不会被扩容。
# kubectl scale --replicas=15 deploy/nginx-deployment deployment.apps/nginx-deployment scaled
在该例中有4个replica加入到旧ReplicaSet中新的ReplicaSet有3个
# kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 12/15 8 12 29m [root@localhost deployment]# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 12 12 12 29m nginx-deployment-55866c9bf7 8 8 0 25m
通过Pod的运行时间可以区分加入新旧ReplicaSet的副本数
暂停和恢复Deployment
可以在触发一个或多个更新之前暂停 Deployment ,然后继续它。这允许在暂停和恢复之间应用多个修补程序,而不会触发不必要的rollout。
例如对于一个刚刚创建的Deployment获取Deployment信息
# kubectl get deploy NAME READY UP-TO-DATE AVAILABLE AGE nginx-deployment 3/3 3 3 3s
获取rs
# kubectl get rs NAME DESIRED CURRENT READY AGE nginx-deployment-54f57cf6bf 3 3 3 35s
使用以下命令暂停Deployment
# kubectl rollout pause deploy/nginx-deployment deployment.apps/nginx-deployment paused
更新镜像
# kubectl set image deploy/nginx-deployment nginx=nginx:1.9.1 deployment.apps/nginx-deployment image updated
查看rollout没有记录
# kubectl rollout history deploy/nginx-deployment deployment.apps/nginx-deployment REVISION CHANGE-CAUSE 1 <none>
恢复Deployment
# kubectl rollout resume deploy/nginx-deployment deployment.apps/nginx-deployment resumed
注意: 暂停的 Deployment 不可以回滚,除非恢复它以后。
暂停的Deployment管理的Pod功能正常运行
Deployment状态
Deployment在生命周期中有多种状态。在创建一个新的ReplicaSet的时候它可以是 progressing 状态, complete 状态,或者fail to progress状态。
Progressing Deployment
Kubernetes将执行过下列任务之一的Deployment标记为progressing状态:
- Deployment正在创建新的ReplicaSet过程中。
- Deployment正在扩容一个已有的ReplicaSet。
- Deployment正在缩容一个已有的ReplicaSet。
- 有新的可用的pod出现。
你可以使用kubectl roullout status
命令监控Deployment的进度。
Complete Deployment
Kubernetes将包括以下特性的Deployment标记为complete状态:
- Deployment最小可用。最小可用意味着Deployment的可用replica个数等于或者超过Deployment策略中的期望个数。
- 所有与该Deployment相关的replica都被更新到了你指定版本,也就说更新完成。
- 该Deployment中没有旧的Pod存在。
你可以用kubectl rollout status
命令查看Deployment是否完成。如果rollout成功完成,kubectl rollout status
将返回一个0值的Exit Code。
# kubectl rollout status deploy/nginx-deployment deployment "nginx-deployment" successfully rolled out [root@localhost deployment]# echo $? 0
Failed Deployment
- 无效的引用
- 不可读的probe failure
- 镜像拉取错误
- 权限不够
- 范围限制
- 程序运行时配置错误
探测这种情况的一种方式是,在你的Deployment spec中指定spec.progressDeadlineSeconds
。spec.progressDeadlineSeconds
表示Deployment controller等待多少秒才能确定(通过Deployment status)Deployment进程是卡住的。
下面的kubectl
命令设置progressDeadlineSeconds
使controller在Deployment在进度卡住10分钟后报告:
# kubectl patch deployment/nginx-deployment -p '{"spec":{"progressDeadlineSeconds":600}}'
PS:默认的参数值就是600秒,可以使用以下命令查看
kubectl edit deploy/nginx-deployment
超过截止时间后, Deployment 控制器将添加具有以下属性到 Deployment 的 .status.conditions
:
- Type=Progressing
- Status=False
- Reason=ProgressDeadlineExceeded
注意: kubernetes除了报告Reason=ProgressDeadlineExceeded状态信息外不会对卡住的Deployment做任何操作。更高层次的协调器可以利用它并采取相应行动,例如,回滚Deployment到之前的版本。 注意: 如果你暂停了一个Deployment,在暂停的这段时间内kubernetnes不会检查你指定的deadline。你可以在Deployment的rollout途中安全的暂停它,然后再恢复它,这不会触发超过deadline的状态。
清理策略
可以在 Deployment 中设置 .spec.revisionHistoryLimit
,以指定保留多少此 Deployment 的 ReplicaSets。其余的将在后台进行垃圾回收。默认情况下,是10。
注意: 将该值设置为0,将导致所有的Deployment历史记录都会被清除,该Deploynent就无法再回退了。
编写Deployment脚本
在所有的Kubernetes配置中,Deployment也需要apiVersion
,kind
和metadata
这些配置项。
Pod Template
.spec仅需要.spec.template和.spec.selector.
.spec.template是 pod template. 它跟 Pod有一模一样的schema,除了它是嵌套的并且不需要apiVersion
和 kind
字段。
另外为了划分Pod的范围,Deployment中的pod template必须指定适当的label(不要跟其他controller重复了)和适当的重启策略。
.spec.template.spec.restartPolicy
可以设置为 Always
, 如果不指定的话这就是默认配置。
Replicas
.spec.replicas是可选字段,指定期望的副本即Pod数量,默认是1。
Selector
.spec.selector
是可选字段,用来指定 label selector ,圈定Deployment管理的pod范围。
如果被指定, .spec.selector
必须匹配 .spec.template.metadata.labels
,否则它将被API拒绝。
在 API apps/v1
版本中,.spec.selector
和 .metadata.labels
不会被默认设置为 .spec.template.metadata.labels
,如果没有设置的话。所以需要明确进行设置。同时在 apps/v1
版本中, Deployment 创建后 .spec.selector
是可变的
如下所示需要匹配
在Pod的template跟.spec.template
不同或者数量超过了.spec.replicas
规定的数量的情况下,Deployment会杀掉label跟selector不同的Pod。
注意: 不应创建其标签与此选择器匹配的 Pods,或者直接创建另一个 Deployment ,或通过创建其他控制器(如 ReplicaSet 或复制控制器)。如果这样做,第一个 Deployment 认为它创建了这些其他 Pods。Kubernetes 不会阻止你这么做。
如果有多个具有重叠选择器的控制器,则控制器之间会因冲突而故障。
策略
.spec.strategy
指定新的Pod替换旧的Pod的策略。 .spec.strategy.type
可以是”Recreate”或者是 “RollingUpdate”。”RollingUpdate”是默认值。
Recreate Deployment
.spec.strategy.type==Recreate
时,在创建出新的Pod之前会先杀掉所有已存在的Pod。
Rolling Update Deployment
.spec.strategy.type==RollingUpdate
时,Deployment使用rolling update 的方式更新Pod 。你可以指定maxUnavailable
和maxSurge
来控制 rolling update 进程。
Max Unavailable
.spec.strategy.rollingUpdate.maxUnavailable
是可选配置项,用来指定在升级过程中不可用Pod的最大数量。该值可以是一个绝对值(例如5),也可以是期望Pod数量的百分比(例如10%)。通过计算百分比的绝对值向下取整。如果.spec.strategy.rollingUpdate.maxSurge
为0时,这个值不可以为0。默认值是1。
例如,该值设置成30%,启动rolling update后旧的ReplicatSet将会立即缩容到期望的Pod数量的70%。新的Pod ready后,随着新的ReplicaSet的扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻可以用的Pod数量至少是期望Pod数量的70%。
Max Surge
.spec.strategy.rollingUpdate.maxSurge
是可选配置项,用来指定可以超过期望的Pod数量的最大个数。该值可以是一个绝对值(例如5)或者是期望的Pod数量的百分比(例如10%)。当MaxUnavailable
为0时该值不可以为0。通过百分比计算的绝对值向上取整。默认值是1。
例如,该值设置成30%,启动rolling update后新的ReplicatSet将会立即扩容,新老Pod的总数不能超过期望的Pod数量的130%。旧的Pod被杀掉后,新的ReplicaSet将继续扩容,旧的ReplicaSet会进一步缩容,确保在升级的所有时刻所有的Pod数量和不会超过期望Pod数量的130%。
Progress Deadline Seconds
.spec.progressDeadlineSeconds
是可选配置项,用来指定在系统报告Deployment的failed progressing ——表现为resource的状态中type=Progressing
、Status=False
、 Reason=ProgressDeadlineExceeded
前可以等待的Deployment进行的秒数。Deployment controller会继续重试该Deployment。未来,在实现了自动回滚后, deployment controller在观察到这种状态时就会自动回滚。
如果设置该参数,该值必须大于 .spec.minReadySeconds
。
Min Ready Seconds
.spec.minReadySeconds
是一个可选配置项,用来指定没有任何容器crash的Pod并被认为是可用状态的最小秒数。默认是0(Pod在ready后就会被认为是可用状态)。进一步了解什么什么后Pod会被认为是ready状态。
Rollback To
.spec.rollbackTo
是一个可以选配置项,用来配置Deployment回退的配置。设置该参数将触发回退操作,每次回退完成后,该值就会被清除。
Revision
.spec.rollbackTo.revision
是一个可选配置项,用来指定回退到的revision。默认是0,意味着回退到历史中最老的revision。
Revision History Limit
Deployment revision history存储在它控制的ReplicaSets中。
.spec.revisionHistoryLimit
是一个可选配置项,用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话,默认所有旧的Replicaset或会被保留,将资源存储在etcd中,是用kubectl get rs
查看输出。每个Deployment的该配置都保存在ReplicaSet中,然而,一旦你删除的旧的RepelicaSet,你的Deployment就无法再回退到那个revison了。
如果你将该值设置为0,所有具有0个replica的ReplicaSet都会被删除。在这种情况下,新的Deployment rollout无法撤销,因为revision history都被清理掉了。
Paused
.spec.paused
是可以可选配置项,boolean值。用来指定暂停和恢复Deployment。Paused和没有paused的Deployment之间的唯一区别就是,所有对paused deployment中的PodTemplateSpec的修改都不会触发新的rollout。Deployment被创建之后默认是非paused。
Deployment的替代方案
Kubectl rolling update 虽然使用类似的方式更新Pod和ReplicationController。但是我们推荐使用Deployment,因为它是声明式的,客户端侧,具有附加特性,例如即使滚动升级结束后也可以回滚到任何历史版本。