kubernetes - Gitlab Autodevops如何始终保持一个 pods 存活

Question

我正在使用Gitlab Autodevops在我的kubernetes集群上部署应用程序。该应用应始终仅运行一个实例。
问题是，在更新过程中，Helm在新的Pod准备就绪之前会杀死当前正在运行的Pod。这会导致停机时间，即旧版本已被终止而新版本尚未准备就绪。更糟糕的是，应用需要大量时间才能启动(超过2分钟)。

我试图在minAvailable: 1中设置PodDisruptionBudget，但是没有帮助。
任何想法我该如何告诉 Helm 手在杀死旧荚之前等待更新荚的准备？ (对我来说，让两个实例同时运行几秒钟并不是一个问题)

Answer 1

您可以通过几种方式发布新的应用程序版本，有必要选择适合您需求的版本。
我建议以下之一:
加速-缓慢推出

A ramped deployment updates pods in a rolling update fashion, a secondary ReplicaSet is created with the new version of the application, then the number of replicas of the old version is decreased and the new version is increased until the correct number of replicas is reached.

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版本控制问题

A blue/green deployment differs from a ramped deployment because the “green” version of the application is deployed alongside the “blue” version. After testing that the new version meets the requirements, we update the Kubernetes Service object that plays the role of load balancer to send traffic to the new version by replacing the version label in the selector field.

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中找到。
Canary-用于测试

A canary deployment consists of routing a subset of users to a new functionality. In Kubernetes, a canary deployment can be done using two Deployments with common pod labels. One replica of the new version is released alongside the old version. Then after some time and if no error is detected, scale up the number of replicas of the new version and delete the old deployment.

Using this ReplicaSet technique requires spinning-up as many pods as necessary to get the right percentage of traffic. That said, if you want to send 1% of traffic to version B, you need to have one pod running with version B and 99 pods running with version A. This can be pretty inconvenient to manage so if you are looking for a better managed traffic distribution, look at load balancers such as HAProxy or service meshes like Linkerd, which provide greater controls over traffic.

版本A的 list :

spec:
  replicas: 3

版本B的 list :

spec:
  replicas: 1

完整的示例和步骤可以在 here中找到。
您也可以在Kubernetes上使用 Interactive Tutorial - Updating Your App玩。
我建议阅读 Deploy, Scale And Upgrade An Application On Kubernetes With Helm。