Question

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

我尝试在minAvailable: 1中设置PodDisruptionBudget，但没有帮助。我知道如何告诉舵手等待更新的吊舱准备就绪，然后杀死旧的吊舱吗？（让2个实例同时运行几秒钟对我来说不是问题）

Answer 1

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

斜坡化-缓慢推出

经过加速的部署以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 Service对象，该对象扮演负载平衡器的角色，通过替换选择器字段中的版本标签将流量发送到新版本。

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标签的部署来完成金丝雀部署。新版本的一个副本与旧版本一起发布。然后过一会儿，如果未检测到错误，请按比例增加新版本的副本数量并删除旧的部署。

使用此ReplicaSet技术需要旋转尽可能多的Pod，以获取正确百分比的流量。就是说，如果您要将1％的流量发送到版本B，则需要让一个Pod与版本B一起运行，而99个Pod与A版本一起运行。这可能非常不方便管理，因此，如果您正在寻找一种更好的管理方式，流量分布，请查看诸如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。

Gitlab Autodevops如何始终保持一个吊舱存活

1 个答案: