Pod-就地升级2Readiness-gates

33次阅读

共计 1721 个字符，预计需要花费 5 分钟才能阅读完成。

Readiness gates，又被称为 pod“ready++”，该个性 kubernetes1.11 被引入，在 kubernetes1.14 达到稳固状态。

在这之前，咱们通过设置 readiness probe 来决定是否 Pod 能够开始提供服务 – 即 Pod 的地址是否能够呈现在对应 endpoints 的列表中。然而此时可能相关联的其余根底服务并没有真正准备就绪。

例如，在部署滚动更新期间，一个新的 Pod 准备就绪。另一方面，因为任何起因（例如 api machinery，endpoints controller，kube-proxy，iptables 或根底构造编程的速度迟缓），网络策略和负载平衡器尚未为新的 pod 准备就绪。这可能会导致服务中断或后端容量失落。在极其状况下，如果滚动更新在任何新的替换 Pod 理论开始为流量提供服务之前实现，则将导致服务中断。

Readiness gates 正是为了解决此类问题呈现的。它给与了 Pod 之外组件管制 Pod 就绪的能力。

Readiness gates 取决于 Pod 的 status.condition 字段的以后状态。如果 Kubernetes 在 Pod 的 status.conditions 字段中找不到这样的条件，则该条件的状态默认为“False”。

这是一个例子：

kind: Pod
...
spec:
  readinessGates:
    - conditionType: "www.example.com/feature-1"
status:
  conditions:
    - type: Ready                              # a built in PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
    - type: "www.example.com/feature-1"        # an extra PodCondition
      status: "False"
      lastProbeTime: null
      lastTransitionTime: 2018-01-01T00:00:00Z
  containerStatuses:
    - containerID: docker://abcd...
      ready: true
...

此时对于应用自定义条件的 Pod，仅当以下两个语句均实用时，该 Pod 才被评估为就绪：

Pod 中的所有容器均已准备就绪。
ReadinessGates 中指定的所有条件均为 True。

当 Pod 的容器准备就绪，但至多短少一个自定义条件或 False 时，kubelet 将 Pod 的条件设置为 ContainersReady。

kubectl patch 命令不反对批改对象状态。要为 Pod 设置这些状态条件，应用程序和 operator 应用 PATCH 操作。能够应用 Kubernetes 客户端库编写代码来设置 Pod 筹备状态的自定义 Pod 条件。
如何使 ReadinessGates 对 K8s API 用户通明。换句话说，K8s API 用户无需指定 ReadinessGates 即可应用特定性能。这容许现有清单仅与须要 ReadinessGate 的性能一起应用。每个性能都将承当注入 ReadinessGate 的工作，并放弃其自定义 Pod 条件放弃同步。能够在容器创立时应用变异的 Webhook 注入 ReadinessGate。Pod 创立后，只有其 ReadinessGate 存在于 PodSpec 中，每个性能都负责使其自定义 Pod 条件放弃同步。这能够通过运行 k8s 控制器来同步相干 Pod 上的条件来实现。这是为了确保即便在 API 服务器上产生灾难性故障（例如，数据失落）时，PodStatus 也是可察看和可复原的。

为什么说没有 Readiness gates 就没有就地降级？原生的 Pod 降级策略是 recreate。一系列的措施保障了 Pod 在降级过程中，不会服务流量。

就地降级就是通过 Readiness gates 标记就地降级过程中的 Pod，不再就绪，也就不再服务流量。待就地降级结束后，在通过更改 Pod 的 Readiness gates condition 为 true，开始服务流量。

正文完