我目前正在使用operator-sdk. 该运算符创建了 twoStatefulSet和 two Service，并带有一些业务逻辑。
我想知道 CRD 状态是什么？在我的协调方法中，我使用默认客户端（即r.List(ctx, &setList, opts...)）从集群中获取数据，我是否应该将数据存储在状态中以供以后使用？如果是这样，这个状态有多可靠？我的意思是它持续存在吗？如果控制平面死了，它仍然可用吗？灾难恢复怎么办，如果持久化的数据消失了怎么办？这种情况不会使 CRD 状态的使用无效吗？
可以认为 CRD 的状态子资源具有与非自定义资源相同的目标。虽然规范定义了该特定资源的所需状态，但基本上我声明了我想要的，而状态则解释了我在集群上声明的资源的当前情况，并且应该有助于理解所需状态和实际状态之间的不同之处.
就像StatefulSet 规范可以说我想要 3 个副本，它的状态说现在只有 1 个副本已准备好，下一个仍在启动，自定义资源状态可能会告诉我我在眼镜。
例如，使用 Rook Operator，我可以声明我想要一个以某种方式制作的 CephCluster。由于 CephCluster 是一个相当复杂的东西（由几个 StatefulSet、Daemons 等组成），自定义资源定义的状态将告诉我整个 ceph 集群的当前情况，它的健康状况是否正常，或者是否有什么需要我注意和很快。
根据我对 Kubernetes API 的理解，您不应该依赖状态子资源来决定您的操作员应该对 CRD 执行什么操作，因为始终检查集群的当前情况（在操作员启动或当资源被定义、更新或删除时）
最后，让我引用 Kubernetes API 约定，因为它很好地解释了约定（https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and -状态）
按照惯例，Kubernetes API 对对象所需状态的规范（称为“ spec ”的嵌套对象字段）和对象当前的状态（称为“ status ”的嵌套对象字段）进行了区分。
该规范是对所需状态的完整描述，包括用户提供的配置设置、系统扩展的默认值以及其他生态系统组件（例如调度程序、自动缩放器）创建后初始化或以其他方式更改的属性，并且是与 API 对象一起保存在稳定的存储中。如果规范被删除，该对象将从系统中清除。
状态总结了系统中对象的当前状态，通常通过自动化过程与对象一起保存，但也可以动态生成。付出一些代价，也许是行为的一些暂时退化，如果状态丢失，可以通过观察来重建状态。
当一个新版本的对象被 POST 或 PUT 时，“ spec ”被更新并立即可用。随着时间的推移，系统将努力使“状态”与“规范”保持一致。无论该节的先前版本如何，系统都将朝着最新的“规范”发展。换句话说，如果一个 PUT 中的值从 2 更改为 5，然后在另一个 PUT 中又回到 3，则系统不需要在将“状态”更改为 3 之前在 5 处“触底”。换句话说，系统的行为是基于水平的，而不是基于边缘的。这可以在缺少中间状态更改的情况下实现稳健的行为。