【分享】关于 Phase、State、Conditions 的理解

[xue8]

分享内容

在进行源码阅读的时候，会经常看到资源 Status 里面有 Phase、 State、 Conditions 这几个字段，仔细看会发现它们都是描述资源的状态，那它们到底有什么区别呢，不仔细研究还真是会让人傻傻分清楚。

这里首先给出个人的理解 Conditions 是一组详细状态，描述的是资源当前以及过去的状态；Phase 和 State 描述的是资源的当前状态，这两个的用法是一样的，至于用哪个则根据个人喜好了，Phase、State 的取值来自于 Condtions。

Conditions 已经成为一个用于收集资源的详细状态的标准机制，Conditions 应该是可扩展的，常用一个数组、切片来实现，典型的 condition 的结构如下：

字段名称	描述
type	状况的名称
status	表明该状况是否适用，可能的取值有 "True", "False" 或 "Unknown"
lastProbeTime	上次探测资源状况时的时间戳
lastTransitionTime	上次从一种状态转换到另一种状态时的时间戳
reason	机器可读的、驼峰编码（UpperCamelCase）的文字，表述上次状况变化的原因。用于 kubectl get 显示如 NewReplicaSetAvailable
message	人类可读的消息，给出上次状态转换的详细信息。用于 kubectl describe 显示

• type 状况名称尽量言简意骇，如使用 "Ready" 而不是 "MyResourceReady"，同时应该有较好的可读性，例如 "Ready"、"Succeeded" 就比 "Failed" 更具有可读性，因为 "Failed=Unknown" 或者 "Failed=False" 这时候就不容易判断出状态到底是成功还是失败。
• status 的值通常为 True、False、Unknown，分别代表状况适用、不适用、未知，当 status 缺失的时候应该当作 Unknown 处理。type 描述的应该是资源当前能观察到的状态，而不描述资源当前的状态转换，应该用形容词来作为描述词而不是用动词作为描述词，例如用 Ready、OutOfDisk、Succeeded、Failed 等而不是 Creating、Deloying。

每个 condition 包含资源调谐过程中某个阶段的详细状态，例如一个资源的协调过程中涉及到与组件 A 的交互，这时候可以用一个 type 为 Ready 的condition 描述与组件 A 的交互状态，在请求返回之前 condition 的 status 应该为 Unknown（常用 Unknown 描述未知状态，如结果还未返回） ，这样当有其他请求在同时间协调这个资源的时候，会根据 condition status 的Unknown 状态知道已经与组件 A 交互过了，就会跳过与组件 A 交互的逻辑。

参考：

https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties

分享收获

备注

个人拙见，欢迎大佬补充。