vs201检查更新不成功_Kubernetes玩转Pod滚动更新123

前言

今天推荐一篇关于Kubernetes上服务滚动更新相关的配置选项的文章，文章列出了最常用的几个配置项，解释了他们是怎么影响调度器对服务进行滚动更新的，同时还带出了Kubernetes项目中Pod这个逻辑单元的Ready状态是怎么确定的，并不是容器运行起来后Pod就进入Ready状态的。总之个人觉得是篇非常好的普及Kubernetes基础的文章，文章由本人完全手工翻译，尽量做到通顺易懂，英文好的同学可以直接看原文。

原文标题：Kubernetes Deployments 滚动更新配置/ Kubernetes Deployments Rolling Update Configration.

发布时间：February 26, 2020

原文链接：https://www.bluematador.com/blog/kubernetes-deployments-rolling-update-configuration

文章作者：Keilan Jackson

文章译者：Keivn Yan

Deployment是Kubernetes中一种常用的Pod控制器，它对Pod提供了细粒度的全面控制：如何进行Pod配置、如何执行Pod更新，应运行多少Pod以及何时终止Pod。有许多这方面的资源会教你如何配置Deployment，但是你可能很难理解每个选项是如何影响滚动更新的执行方式的。在此博客文章中，我们将涵盖以下主题，以帮助您成为Kubernetes Deployment的专家：

Kubernetes Deployment概貌；
Kubernetes服务的滚动更新；
怎么定义Pod的Ready状态；
Pod Affinity和Anti-Affinity；

Deployment 概貌

Deployment实质上是ReplicaSet的上层包装。ReplicaSet管理正在运行的Pod数量，Deployment在其之上实现功能从而拥有了Pod滚动更新，对Pod的运行状况进行健康检查以及轻松回滚更新的能力。在常规运行期间，Deployment仅管理一个ReplicaSet，以确保期望数量的Pod正在运行：

在Kubernetes里我们不应直接操作由Deployment创建的ReplicaSet，对ReplicaSet执行的所有操作应改为在Deployment上执行，然后由Deployment管理更新ReplicaSet的过程。以下是一些通常在Deployment上执行的操作的示例kubectl命令：

# 列出默认命名空间下的所有Deploymentkubectl get deploy

# 通过定义文件更新Deploymentkubectl apply -f test.yaml

# 监控"test"这个Deployment的状态更新kubectl rollout status deploy/test

# 暂停"test"这个Deployment的更新流程:kubectl rollout pause deploy/test

# 恢复"test"这个Deployment的更新流程:kubectl rollout resume deploy/test

# 查看"test"这个Deployment的更新历史:kubectl rollout history deploy/test

# 回退test最近的更新kubectl rollout undo deploy/test

# 把test这个Deployment回滚到指定版本kubectl rollout undo deploy/test --to-revision=1

Pod的滚动更新

使用Deployment来控制Pod的主要好处之一是能够执行滚动更新。滚动更新允许你逐步更新Pod的配置，并且Deployment提供了许多选项来控制滚动更新的过程。

控制滚动更新最重要的选项是更新策略。在Deployment的YAML定义文件中，由spec.strategy.type字段指定Pod的滚动更新策略，它有两个可选值：

RollingUpdate (默认值)：逐步创建新的Pod，同时逐步终止旧Pod，用新Pod替换旧Pod。
Recreate：在创建新Pod前，所有旧Pod必须全部终止。

大多数情况下，RollingUpdate是Deployment的首选更新策略。如果你的Pod需要作为单例运行，并且不允许在任何时间存在多副本，这种时候Recreate更新策略会很有用。

使用RollingUpdate策略时，还有两个选项可以让你微调更新过程：

maxSurge：在更新期间，允许创建超过期望状态定义的Pod数的最大值。
maxUnavailable：在更新期间，容忍不可访问的Pod数的最大值

maxSurge和maxUnavailable选项都可以使用整数(比如：2)或者百分比(比如：50%)进行配置，而且这两项不能同时为零。当指定为整数时，表示允许超期创建或者不可访问的Pod数。当指定为百分比时，将使用期望状态里定义的Pod数作为基数。比如：如果对maxSurge和maxUnavailable都使用默认值25％，并且将更新应用于具有8个容器的Deployment，那么意味着maxSurge为2个容器，maxUnavailable也将为2个容器。这意味着在更新过程中，将满足以下条件：

最多有10个Pod(8个期望状态里指定的Pod和2个maxSurge允许超期创建的Pod)在更新过程中处于Ready状态。
最少有6个Pod(8个期望状态里指定的Pod和2个maxUnavailable允许不可访问的Pod)将始终处于Ready状态。

值得注意的一点是，在考虑Deployment应在更新期间运行的Pod数量时，使用的是在Deployment的更新版本中指定的副本数，而不是现有Deployment版本的期望状态中指定的副本数。

可以用另外一种方式理解这两个选项：maxSurge是一次将创建的新Pod的最大数量，maxUnavailable是一次将被删除的旧Pod的最大数量。让我们具体看一下使用以下更新策略将具有3个副本的Deployment从"v1"更新为" v2"的过程：

replicas: 3  strategy:    type: RollingUpdate    rollingUpdate:      maxSurge: 1      maxUnavailable: 0

这个更新策略是，我们想一次新建一个Pod，并且应该始终保持Deployment中的Pod有三个是Ready状态。下面的动图说明了滚动更新的每一步都发生了什么。如果Deployment看到Pod已经完全部署好了将会把Pod标记为Ready，创建中的Pod标记为NotReady，正在被删除的Pod标记为Terminating。

Deployment滚动更新Pod的过程

怎么判读Pod是否Ready

Kubernetes自身实现了一个叫做Ready Pod的概念来辅助滚动更新。具体来说就是，ReadinessProbe (就绪探针)可以使Deployment逐步更新Pod，同时也可以使用它控制何时才能进行滚动更新，Service也使用它来确定应该将哪些Pod包含在服务的Endpoints中。就绪探针与活动性探针相似但不相同，活性探针使kubelet可以根据其“重新启动策略”来确定哪些Pod需要重新启动，并且它们与就绪性探针分开配置，不会影响Deployment的滚动更新的过程。

译者注：关于就绪探针和活性探针详细的解释可以看我以前的文章：浅析Kubernetes Pod重启策略和健康检查

一个Ready状态的Pod是指：Pod通过了就绪探针的测试，并且自创建以来经过了spec.minReadySeconds指定的秒数则被视为已经Ready。这些选项的默认值将导致Pod内部的容器启动后Pod立即进入Ready状态。

事实上，有几个原因通常让你并不想让容器启动后Pod立即进入Ready状态：

希望在接收流量前，Pod能够先通过健康检查。
服务需要先预热，然后再提供流量。
你要放慢部署速度，以减少对运行中的系统的影响。

对于Web应用程序，要求通过健康检查非常常见，这对于以最小的中断执行更新至关重要。下面是为了对一个Web应用进行健康检查而配置的就绪探针：

readinessProbe:          periodSeconds: 15          timeoutSeconds: 2          successThreshold: 2          failureThreshold: 2          httpGet:            path: /health            port: 80

这个探针要求对端口80上的/health的调用在2秒内成功完成，每15秒执行一次，并且在Pod准备就绪之前必须进行2次成功的调用。这意味着在最佳情况下，Pod将在约30秒内准备就绪。许多应用程序在启动后2秒钟之内无法立即提供服务，即使是简单的请求，因此应该为前1项或2次检查的失败做好准备，这种情况下实际需要约60秒的准备时间Pod才能进入Ready状态。

您还可以配置在容器上执行命令的就绪探针。这让你可以编写可执行的自定义脚本，并确定Pod是否已准备好，Deployment是否可以继续执行滚动更新：

readinessProbe:          exec:            command:              - /startup.sh          initialDelaySeconds: 5          periodSeconds: 15          successThreshold: 1

在这个配置中，Deployment在Pod创建成功后将等待5秒钟，然后每15秒钟执行一次命令。脚本的exit code为0被认为是执行成功。使用命令脚本的灵活性让你可以执行以下类似操作，例如将数据加载到缓存中或预热JVM，或在不修改应用程序代码的情况下对下游服务进行运行状况检查。

我们将在这里讨论的最后一种情况是故意减慢更新过程，以最大程度地减少对系统的影响。乍一看似乎不需要，但是在某些情况下它可能非常有用，包括事件处理系统，监视工具和预热时间较长的Pod。通过在Deployment定义中指定spec.minReadySeconds字段可以轻松实现此目标。当指定minReadySeconds时，Pod必须运行这么多秒，而且其容器中的任何一个都不能崩溃，才能被Deployment视为进入Ready状态。

比如说，假设一个Deployment管控着5个Pod副本，它们从事件流读取、处理事件，然后把数据保存在数据库中。每个Pod需要预热60秒后才能全速处理事件，如果使用默认的选项值，Pod创建后立即进入Ready状态，但是它们在第一分钟内处理事件的速度会很慢。更新完成后，由于所有Pod同时预热，因此事件将会堆积在事件流里面。相反，你可以将maxSurge设置为1，将maxUnavailable设置为0，将minReadySeconds设置为60。这将确保一次创建一个新的Pod，在经过一分钟预热后新建的Pod才能进入Ready状态，并且旧Pod在新Pod就绪之前不会被删除。这样，就可以在大约5分钟的时间内更新所有Pod，并且能保持更新期间服务的稳定。

Pod Affinity和Anti-Affinity

PodAffinity和PodAntiAffinity这两个配置让你可以控制将Deployment的Pod调度到哪些节点上。尽管这个功能并非Deployment控制器特有的，但对于许多应用程序来说可能非常有用。在配置PodAffinity或PodAntiAffinity时，你必须选择在不同环境条件下要添加给新建的Pod的调度偏好。这里有两个选项：

requiredDuringSchedulingIgnoredDuringExecution：除非节点与Affinity配置相匹配，否则即使没有匹配的节点，直接调度失败，也不会把Pod调度到不匹配的节点上去。
preferredDuringSchedulingIgnoredDuringExecution：调度程序将尝试在与配置匹配的节点上调度Pod，但如果无法这样做，则仍将Pod调度在另一个节点上。

podAffinity用于将Pod调度到某些节点上。如果知道某个Pod具有特定的资源要求(例如，只有一组特定的，带有GPU的节点或者某个区域中的节点)，则通常需要进行podAffinity配置。或者你希望Pod与其他Pod并置在一个节点上：

affinity:    podAffinity:      requiredDuringSchedulingIgnoredDuringExecution:      - labelSelector:          matchExpressions:          - key: app            operator: In            values:            - cache        topologyKey: "kubernetes.io/hostname"    podAntiAffinity:      preferredDuringSchedulingIgnoredDuringExecution:      - weight: 100        podAffinityTerm:          labelSelector:            matchExpressions:            - key: app              operator: In              values:              - web          topologyKey: kubernetes.io/hostname

相反地，podAntiAffinity在确保同属一个Deployment的Pod不被调度到同一个节点上时非常有用，上面例子偏向于将标签为app:web的Pod部署到不同的节点上，降低服务的所有Pod因为节点出问题同时出故障的可能性。

使用affinity配置时，要注意非常重要的一点是，affinity规则是在对Pod进行调度时进行评估的。而调度器无法预见Pod的调度位置，这意味着affinity配置可能无法达到预期的效果。考虑有一个拥有3个节点的集群，一个拥有3个Pod副本的使用了上面示例affinity规则的Deployment，Deployment把maxSurge配置成1。你期望的调度目标可能是，在每个节点上运行Deployment的一个Pod，但是由于maxSurge设置为1，在滚动更新期间调度器每次只能创建一个新Pod。这意味着随着时间的流逝，你可能最终会得到一个更新后没有任何这些Pod的节点，然后所有或大多数Pod将在下一次更新时移至该节点。调度程序不知道你将要终止旧的Pod，在做affinity规则判断时仍然会算上旧Pod，这就是导致上面说的可能情况的原因。如果确实需要在每个节点上只能运行一个Pod副本，则应使用DaemonSets控制器。如果您的应用程序可以接受，另一种选择是将更新策略更改为“重新创建”。这样，当调度程序评估affinity规则时，将不会算上旧的Pod。

podAffinity和PodAntiAffinity有很多选项可以影响Pod的调度方式，但通常无法保证滚动更新也能满足规则。在某些情况下，这是一个非常有用的功能，但是除非真的需要控制Pod的运行位置，否则应让kubernetes调度程序来做出这些决定。可以在此处^[1]找到有关podAffinity和podAntiAffinity的详细文档。

总结

我们已经介绍了Deployment的基本用法，滚动更新的工作方式以及用于微调更新和Pod调度的许多配置选项。此时，你应该能够使用更新策略，就绪探针和Pod关联性(affinity)来自信地创建和修改Deployment的定义文件，以达到应用程序期望的状态。有关Deployment支持的所有选项的详细参考，请查看Kubernetes文档。

引用链接

[1]

此处: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity

推荐阅读

深入理解StatefulSet，用Kubernetes编排有状态应用
常用限流算法的应用场景和实现原理
觉得WaitGroup不好用？试试ErrorGroup吧！

- END -

关注公众号，获取更多精选技术原创文章