Pod 就地升级2--Readiness gates

什么是Readiness gates？

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。

如何使用Readiness gates？

• 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

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

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