k8s服务升级发布pod旧节点延迟下线

方法一,由开发人员在项目代码chart配置中单独配置:

deployment.yaml配置文件中添加策略

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "wzd-service.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "wzd-service.name" . }}
    helm.sh/chart: {{ include "wzd-service.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
spec:
  replicas: {{ .Values.replicaCount }}
  minReadySeconds: 30
  strategy:
    # indicate which strategy we want for rolling update
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: {{ include "basic-service.name" . }}
      app.kubernetes.io/instance: {{ .Release.Name }}

字段解释
revisionHistoryLimit
默认配置下，Kubernetes 只会保留最近的几个 revision，可以在 Deployment 配置文件中通过 revisionHistoryLimit 属性增加 revision 数量。

revisionHistoryLimit（历史版本记录）：Deployment revision history存储在它控制的ReplicaSets中。默认保存记录5个　　　　
.spec.revisionHistoryLimit 是一个可选配置项，用来指定可以保留的旧的ReplicaSet数量。该理想值取决于心Deployment的频率和稳定性。如果该值没有设置的话，默认所有旧的Replicaset或会被保留，将资源存储在etcd中，是用kubectl get rs查看输出。每个Deployment的该配置都保存在ReplicaSet中，然而，一旦删除的旧的RepelicaSet，Deployment就无法再回退到那个revison了。　　
如果将该值设置为0，所有具有0个replica的ReplicaSet都会被删除。在这种情况下，新的Deployment rollout无法撤销，因为revision history都被清理掉了。
PS：为了保存版本升级的历史，需要再创建Deployment对象时，在命令中使用"–record"选项一般配合revisionHistoryLimit使用的strategy (更新策略)
minReadySeconds

Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了，所以这个可以设置的保守一些，比如我们的服务启动从3-20秒不等，我可以设置成30秒，这样防止pod启动了但是服务还没准备好导致系统不可用。
maxSurge

升级过程中最多可以比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。
maxUnavaible

升级过程中最多有多少个POD处于无法提供服务的状态，当maxSurge不为0时，该值也不能为0，最好和maxSurge保持一致。
例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态，可以保证有足够的pod（或者认为是足够的性能）提供服务。
参考文章链接：https://blog.csdn.net/xjjj064/article/details/119605988

方法二由k8s运维人员统一修改