kubernetes - CRD状态有什么用？

Question

我目前正在使用 operator-sdk 在 go 中编写一个 kubernetes 运算符。该运算符创建了两个 StatefulSet 和两个 Service，并带有一些业务逻辑。

我想知道 CRD 状态是什么？在我的协调方法中，我使用默认客户端(即 r.List(ctx, &setList, opts...))从集群中获取数据，我是否应该将数据存储在状态中以使用它之后 ？如果是这样，这种状态有多可靠？我的意思是它坚持了吗？如果控制平面死亡，它是否仍然可用？灾难恢复呢，如果持久化数据消失了怎么办？这种情况不会使 CRD 状态的使用无效吗？

Answer 1

CRD 的状态子资源可以被认为具有与非自定义资源相同的目标。虽然 spec 定义了该特定资源的所需状态，但基本上我声明了我想要的内容，而 status 却解释了我在集群上声明的资源的当前情况，并且应该有助于理解理想状态和实际状态之间的差异。

就像一个 StatefulSet spec 可以说我想要 3 个副本，它的status 说现在这些副本中只有 1 个准备好了，下一个仍在开始，自定义资源 status 可能会告诉我我在规范中声明的任何内容的当前情况。

例如，使用 Rook Operator，我可以声明我想要以某种方式构建的 CephCluster。由于 CephCluster 是一个相当复杂的东西(由多个 StatefulSet、守护进程等组成)，自定义资源定义的状态将告诉我整个 ceph 集群的当前情况，它是否健康或是否需要我注意和等等。

根据我对 Kubernetes API 的理解，你不应该依赖状态子资源来决定你的运算符(operator)应该对 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 thespecification of the desired state of an object (a nested object fieldcalled "spec") and the status of the object at the current time (anested object field called "status").

The specification is a completedescription of the desired state, including configuration settingsprovided by the user, default values expanded by the system, andproperties initialized or otherwise changed after creation by otherecosystem components (e.g., schedulers, auto-scalers), and ispersisted in stable storage with the API object. If the specificationis deleted, the object will be purged from the system.

The statussummarizes the current state of the object in the system, and isusually persisted with the object by automated processes but may begenerated on the fly. At some cost and perhaps some temporarydegradation in behavior, the status could be reconstructed byobservation if it were lost.

When a new version of an object is POSTed or PUT, the "spec" isupdated and available immediately. Over time the system will work tobring the "status" into line with the "spec". The system will drivetoward the most recent "spec" regardless of previous versions of thatstanza. In other words, if a value is changed from 2 to 5 in one PUTand 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. Thisenables robust behavior in the presence of missed intermediate statechanges.