Deployment更新策略
在Kubernetes中,Deployment
的更新策略主要有两种:
- 滚动更新(Rolling Update):
- 这是Kubernetes
Deployment
的默认更新策略。 - 在滚动更新过程中,Deployment 控制器会逐步地将新版本的Pod逐个替换旧版本的Pod。这个过程会确保在升级过程中始终有一定数量的可用Pod服务于客户端请求,从而实现平滑的服务过渡。
- 滚动更新有两个重要的参数:
maxUnavailable
和maxSurge
。maxUnavailable
用于指定在滚动更新过程中允许的最大不可用Pod数或百分比;而maxSurge
用于指定在滚动更新过程中可以超出期望副本数的最大Pod数或百分比。 - 滚动更新特别适用于需要确保服务持续可用的场景。
- 重建更新(Recreate):
- 当
.spec.strategy.type
设置为Recreate
时,Deployment 将采取这种策略。 - 使用此策略时,Deployment 会先停止所有旧的Pod副本,等到所有旧副本都终止后,再一次性创建出新的Pod副本。
- 这种策略会导致应用程序的短暂中断,因为在删除旧副本和创建新副本之间存在时间差。
- 重建更新适用于无状态应用程序或可以容忍短暂中断的应用程序。
Pod数量的控制
在Kubernetes中,当使用滚动更新(RollingUpdate)策略时,可以通过设置maxSurge
和maxUnavailable
参数来控制Pod的启动与关闭数量。
- maxSurge: 这个参数决定了在滚动更新过程中,可以超出期望副本数的最大Pod数。它可以是一个整数(表示Pod的绝对数量)或一个百分比(表示相对于期望副本数的百分比)。当设置为百分比时,它默认是期望Pod数量的25%。如果设置为整数,比如
maxSurge: 1
,那么滚动更新过程中,最多可以比期望的副本数多一个Pod。 - maxUnavailable: 这个参数决定了在滚动更新过程中,可以处于不可用状态的最大Pod数。同样,它也可以是一个整数或百分比。当设置为百分比时,它表示相对于期望副本数的百分比。例如,如果设置为
maxUnavailable: 25%
,那么在任何时候,最多只能有25%的Pod处于不可用状态。
以下是一个设置滚动更新策略的示例YAML配置:
apiVersion: apps/v1
kind: Deployment
metadata:
name: pyapp-deploy
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25% # 或者设置为一个整数,如 maxSurge: 1
maxUnavailable: 25% # 或者设置为一个整数,如 maxUnavailable: 1
replicas: 3
selector:
matchLabels:
app: pyapp
template:
metadata:
labels:
app: pyapp
spec:
imagePullSecrets:
- name: harbor-admin
containers:
- name: pyapp-pod
image: harbor.tangotz.com/pyapp/pyapp:v1
ports:
- containerPort: 5000
在上面的示例中,滚动更新策略被设置为允许最多比期望的副本数多25%的Pod,并且在任何时候最多只能有25%的Pod处于不可用状态。你可以根据自己的需要调整这些值。
需要注意的是,maxSurge
和maxUnavailable
是相互影响的。如果同时设置了两者,并且它们的值使得在滚动更新的任何阶段都无法满足(例如,如果maxUnavailable
设置得太高,而maxSurge
设置得太低),那么滚动更新可能会失败。因此,在设置这两个参数时,需要确保它们的值是合理的并且相互兼容的。
触发更新
触发更新有两种方式:
通过kubectl set
kubectl set image deployment/pyapp-deploy ^Capp=harbor.tangotz.com/pyapp/pyapp:v2
通过资源清单
直接编辑资源清单并执行kubectl apply -f 资源清单文件
查看历史记录
使用命令
kubectl rollout history deployment/<deployment-name>
可以查看更新记录
从记录上看CHANGE-CAUSE为<none>,这个值没有设么意义,可以通过命令来记录
kubectl annotate deployment/<deployment-name> kubernetes.io/change-cause="xxxx"
同样也可以用资源描述文件来记录变更。变更记录在metadate.annotations.kubernetes.io/change-cause
中
效果相同
更新回滚
使用kubectl rollout undo 并指定 --to-revision来进行回滚