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, 开始服务流量。

你可能感兴趣的:(k8s,kubernetes)