CRD状态有什么用？
What is the use for CRD status?
我目前正在使用 operator-sdk 在 go 中编写一个 kubernetes 运算符。
此运算符创建两个 StatefulSet 和两个 Service，并带有一些业务逻辑。
我想知道 CRD 状态是什么？在我的协调方法中，我使用默认客户端（即 r.List(ctx, &setList, opts...)）从集群中获取数据，我是否应该将数据存储在状态中以备后用？
如果是这样，这种状态有多可靠？我的意思是它坚持了吗？如果控制平面死亡，它是否仍然可用？
灾难恢复呢，如果持久化数据消失了怎么办？这种情况不会使 CRD 状态的使用无效吗？
一个CRD的status子资源可以认为是和objective非自定义资源一样。虽然 spec 定义了该特定资源的所需状态，但基本上我声明了我想要的，status 反而解释了资源的当前情况我在集群上声明，应该有助于理解期望状态和实际状态之间的区别。
就像一个 StatefulSet spec 可以说我想要 3 个副本并且它的 status 说现在这些副本中只有 1 个准备就绪，下一个仍在启动，自定义资源 status 可能会告诉我我在规范中声明的任何内容的当前情况。
例如，使用 Rook Operator，我可以声明我想要以某种方式制作的 CephCluster。由于 CephCluster 是一个相当复杂的东西（由多个 StatefulSet、守护进程等组成），自定义资源定义的状态将告诉我整个 ceph 集群的当前情况，它是否健康或是否需要我注意和依此类推
根据我对 Kubernetes API 的理解，你不应该依赖状态子资源来决定你的操作员应该对 CRD 做些什么，因为总是检查当前状态更好，也更不容易出错集群的情况（在操作员启动时或定义、更新或删除资源时）
最后，让我引用 Kubernetes API 约定，因为它很好地解释了约定 (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
By convention, the Kubernetes API makes a distinction between the
specification of the desired state of an object (a nested object field
called "spec") and the status of the object at the current time (a
nested object field called "status").
The specification is a complete
description of the desired state, including configuration settings
provided by the user, default values expanded by the system, and
properties initialized or otherwise changed after creation by other
ecosystem components (e.g., schedulers, auto-scalers), and is
persisted in stable storage with the API object. If the specification
is deleted, the object will be purged from the system.
The status
summarizes the current state of the object in the system, and is
usually persisted with the object by automated processes but may be
generated on the fly. At some cost and perhaps some temporary
degradation in behavior, the status could be reconstructed by
observation if it were lost.
When a new version of an object is POSTed or PUT, the "spec" is
updated and available immediately. Over time the system will work to
bring the "status" into line with the "spec". The system will drive
toward the most recent "spec" regardless of previous versions of that
stanza. In other words, if a value is changed from 2 to 5 in one PUT
and then back down to 3 in another PUT the system is not required to
'touch base' at 5 before changing the "status" to 3. In other words,
the system's behavior is level-based rather than edge-based. This
enables robust behavior in the presence of missed intermediate state
changes.
我目前正在使用 operator-sdk 在 go 中编写一个 kubernetes 运算符。
此运算符创建两个 StatefulSet 和两个 Service，并带有一些业务逻辑。
我想知道 CRD 状态是什么？在我的协调方法中，我使用默认客户端（即 r.List(ctx, &setList, opts...)）从集群中获取数据，我是否应该将数据存储在状态中以备后用？
如果是这样，这种状态有多可靠？我的意思是它坚持了吗？如果控制平面死亡，它是否仍然可用？
灾难恢复呢，如果持久化数据消失了怎么办？这种情况不会使 CRD 状态的使用无效吗？
一个CRD的status子资源可以认为是和objective非自定义资源一样。虽然 spec 定义了该特定资源的所需状态，但基本上我声明了我想要的，status 反而解释了资源的当前情况我在集群上声明，应该有助于理解期望状态和实际状态之间的区别。
就像一个 StatefulSet spec 可以说我想要 3 个副本并且它的 status 说现在这些副本中只有 1 个准备就绪，下一个仍在启动，自定义资源 status 可能会告诉我我在规范中声明的任何内容的当前情况。
例如，使用 Rook Operator，我可以声明我想要以某种方式制作的 CephCluster。由于 CephCluster 是一个相当复杂的东西（由多个 StatefulSet、守护进程等组成），自定义资源定义的状态将告诉我整个 ceph 集群的当前情况，它是否健康或是否需要我注意和依此类推
根据我对 Kubernetes API 的理解，你不应该依赖状态子资源来决定你的操作员应该对 CRD 做些什么，因为总是检查当前状态更好，也更不容易出错集群的情况（在操作员启动时或定义、更新或删除资源时）
最后，让我引用 Kubernetes API 约定，因为它很好地解释了约定 (https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)
By convention, the Kubernetes API makes a distinction between the specification of the desired state of an object (a nested object field called "spec") and the status of the object at the current time (a nested object field called "status").
The specification is a complete description of the desired state, including configuration settings provided by the user, default values expanded by the system, and properties initialized or otherwise changed after creation by other ecosystem components (e.g., schedulers, auto-scalers), and is persisted in stable storage with the API object. If the specification is deleted, the object will be purged from the system.
The status summarizes the current state of the object in the system, and is usually persisted with the object by automated processes but may be generated on the fly. At some cost and perhaps some temporary degradation in behavior, the status could be reconstructed by observation if it were lost.
When a new version of an object is POSTed or PUT, the "spec" is updated and available immediately. Over time the system will work to bring the "status" into line with the "spec". The system will drive toward the most recent "spec" regardless of previous versions of that stanza. In other words, if a value is changed from 2 to 5 in one PUT and then back down to 3 in another PUT the system is not required to 'touch base' at 5 before changing the "status" to 3. In other words, the system's behavior is level-based rather than edge-based. This enables robust behavior in the presence of missed intermediate state changes.