我有一个想法，即编写一个控制器来监视某些集群状态数据，然后在受影响的 Pod 中“标记”额外数据，从而提供有关 Kubernetes 集群租户 Pod 的一些额外元数据status。但我不确定是否可以将额外数据写入该字段——是否有任何官方 Kubernetes 文档说明第三方控制器是否可以写入 Pod 的状态字段？我找不到任何文档。
这可能听起来有点像 XY 问题，所以我将在下面解释为什么我想要这样做，如果您对如何解决这个问题有更好的建议，我洗耳恭听。
我的团队拥有并运营着许多大型、多租户 Kubernetes 集群，供公司开发人员使用。我们只拥有 Kubernetes 环境，而不是应用程序，并且我们对开发人员如何部署他们的应用程序没有任何影响力，除了集群范围内的事情，例如将开发人员锁定在他们自己的命名空间组中，在命名空间之间实施合理的网络策略，诸如此类的事情。
我们有一类开发人员，出于超出本问题范围的原因，在我们的 Kubernetes 集群中运行“单例”应用程序（单个 pod），因此当该单个 pod 从其运行的节点上被驱逐时，他们的应用程序会中断（通常是由于我们为集群工作器提供的自动排水-补丁-重启机制）。这些开发人员一直向我们抱怨，虽然 pod 驱逐是 Kubernetes 环境中运行的一部分，但很麻烦，因为它们发生在意想不到的时间。他们希望有机会计划对于这些预定的 pod 驱逐，以便他们可以通知他们的客户，在同一时间安排自己的维护等。
现在，我们可以采用 BOFH 方法，只需说“抱歉，您没有在 Kubernetes 中运行 12 要素应用程序，您付出的代价就是这些”，然后打发他们走。但这不会赢得他们的高管的青睐，更不用说我们的 CIO 了。因此，我们希望“友好”一点，至少尝试为这些开发人员提供某种机制来预测和准备这些事件。但我们拒绝放弃我们努力实现的任何平台自动化。绝对不会“手把手”或手动安排工作节点修补来适应这些单例应用程序。
我们已经实施了一个系统，该系统将标签应用于每个工作节点，以指示每个节点计划何时停机进行修补。这在一定程度上有所帮助，但也有点尴尬：租户必须先查找他们的 pod 在哪个节点上运行，然后查找该节点以获取答案。他们要求更直接的东西——他们可以运行一个查询，该查询只返回他们的 pod 列表以及一个时间戳，指示该 pod 下一次预计何时因计划的维护活动而中断。
我考虑过的一个可能的解决方案是编写一个控制器，执行“节点到 pod”链接，然后更新 Pod 规范中的字段（大概在 下status）以提供此信息。然后我们的租户可以使用一个简单的kubectl get pods -o jsonpath=...方法返回 pod 列表及其预期的下一次中断时间戳。这样做的好处是完全在集群的 RBAC 框架内工作，因此租户只能检查自己的 pod。如果我将其编写为某种外部 API，我将不得不笨拙地重新实现 Kubernetes RBAC，以确保租户只能查询自己的 pod，而不能枚举来自同一集群的对等团队的 pod。
假设从 K8s 机制的角度来看，使用该status字段是合法的，我觉得这是最干净的解决方案，因此我提出了这个问题。但我找不到任何关于 pod 字段“正确使用”或“可接受使用”的权威文档status。我可以使用标签或注释来实现同样的效果，但对我来说，这似乎可能会造成阻碍——例如，可能有些开发人员有他们使用和期望的非常具体的标签或注释，而我塞入一个他们意想不到的新标签或注释可能会破坏 CI/CD 流程，甚至导致停机（请记住，我们无法控制应用程序本身，只能控制集群）。