时间戳

首页 > 解决方案 > 如何处理 RWO 卷服务的滚动更新部署策略？

kubernetes - 如何处理 RWO 卷服务的滚动更新部署策略？

问题描述

我们在 AKS 中托管了服务，该服务具有 RWO 卷，部署策略为重新创建。我们最近上线了这项新服务，每天都有许多功能/问题要交付。由于部署策略是重新创建，业务团队正在经历一些停机时间（最多 2 分钟），但这很烦人。是否有更好的方法来使用滚动更新策略来管理 RWO 卷？

标签： kuberneteskubernetes-helmkubernetes-pod

解决方案

在指定更新部署的方式时，您有两种类型的策略可供选择：

默认和更推荐的一个是.spec.strategy.type==RollingUpdate. 请参阅以下示例：

spec:
  replicas: 2
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 1
     maxUnavailable: 0

在此示例中，将maxSurge: 1在所需数量 2 之上增加一个 Pod ( )，并且可用 Pod 的数量不能低于该数量 ( maxUnavailable: 0)。

选择这个配置，Kubernetes 将启动一个额外的 Pod，然后停止一个“旧的”。如果有另一个节点可用于部署此 Pod，系统将能够在部署期间处理相同的工作负载。如果没有，该 Pod 将部署在已使用的节点上，代价是来自同一节点上托管的其他 Pod 的资源。

你也可以尝试这样的事情：

spec:
  replicas: 2
  strategy:
   type: RollingUpdate
   rollingUpdate:
     maxSurge: 0
     maxUnavailable: 1

对于上面的示例，将没有额外的 Pod ( maxSurge: 0)，并且一次只有一个 Pod 不可用 ( maxUnavailable: 1)。

在这种情况下，Kubernetes 会先停止一个 Pod，然后再启动一个新的 Pod。这样做的好处是基础架构不需要扩展，但最大工作负载会更少。

如果您选择使用百分比值maxSurge并且maxUnavailable您需要记住：

  • maxSurge- 绝对数字是通过四舍五入的百分比计算得出的

  • maxUnavailable- 绝对数字是通过四舍五入的百分比计算得出的

正确定义后，RollingUpdate您还必须确保您的应用程序提供端点以供 Kubernetes 查询并返回应用程序的状态。下面是一个/greeting端点，当它准备好处理请求时返回 HTTP 200 状态，而不是返回 HTTP 500：

readinessProbe:
  httpGet:
    path: /greeting
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 5
  successThreshold: 1
  timeoutSeconds: 1

  • initialDelaySeconds- 完成第一次就绪检查之前的时间（以秒为单位）。

  • periodSeconds- 第一次之后的两次就绪检查之间的时间（以秒为单位）。

  • successThreshold- 探测失败后被视为成功的最小连续成功次数。默认为 1。活性必须为 1。最小值为 1。

  • timeoutSeconds- 探测超时的秒数。默认为 1 秒。最小值为 1。

可以在此处找到有关活性/就绪性探测的更多信息。

这些只是示例，但它们应该让您了解可以使用的特定更新策略，以消除停机的可能性。

推荐阅读