我正在使用Gitlab Autodevops在我的kubernetes集群上部署应用程序。该应用程序应始终只运行一个实例。问题是，在更新过程中，Helm在新pod准备就绪之前杀死当前正在运行的pod。这会导致停机时间段，此时旧版本已经被杀死，而新版本尚未就绪。更糟糕的是，app需要很长时间才能启动（2分钟以上）。
我试图在minAvailable: 1设置PodDisruptionBudget，但没有帮助。任何想法我怎么能告诉掌舵等待更新pod的准备就绪才能杀死旧的？ （有两个实例同时运行几秒钟对我来说不是一个问题）
您可以通过几种方式发布新的应用程序版本，有必要选择适合您需求的版本。我会推荐以下之一：
斜坡 - 慢速展开
渐变部署以rolling update方式更新pod，使用新版本的应用程序创建辅助ReplicaSet，然后减少旧版本的副本数量并增加新版本，直到达到正确数量的副本。
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2 # how many pods we can add at a time
maxUnavailable: 0 # maxUnavailable define how many pods can be unavailable
# during the rolling update
完整的例子和步骤可以找到here。
蓝/绿 - 最好避免API版本问题
蓝色/绿色部署与渐变部署不同，因为应用程序的“绿色”版本与“蓝色”版本一起部署。在测试新版本满足要求后，我们更新扮演负载均衡器角色的Kubernetes服务对象，通过替换选择器字段中的版本标签将流量发送到新版本。
apiVersion: v1
kind: Service
metadata:
name: my-app
labels:
app: my-app
spec:
type: NodePort
ports:
- name: http
port: 8080
targetPort: 8080
# Note here that we match both the app and the version.
# When switching traffic, we update the label “version” with
# the appropriate value, ie: v2.0.0
selector:
app: my-app
version: v1.0.0
完整的例子和步骤可以找到here。
金丝雀 - 用于测试
金丝雀部署包括将用户子集路由到新功能。在Kubernetes中，可以使用两个具有常见pod标签的Deploy来完成canary部署。新版本的一个副本与旧版本一起发布。然后在一段时间后如果没有检测到错误，请扩展新版本的副本数量并删除旧部署。
使用此ReplicaSet技术需要根据需要启动尽可能多的pod以获得正确的流量百分比。也就是说，如果你想将1％的流量发送到版本B，你需要有一个运行版本B的pod和99个运行版本A的pod。如果你正在寻找更好的托管，那么管理起来非常不方便流量分配，查看负载平衡器，如HAProxy或服务网格，如Linkerd，提供更大的流量控制。
版本A的清单：
spec:
replicas: 3
版本B的清单：
spec:
replicas: 1
完整的例子和步骤可以找到here。
您还可以在Kubernetes上玩Interactive Tutorial - Updating Your App。
我建议阅读Deploy, Scale And Upgrade An Application On Kubernetes With Helm。