我有一个HA kubernetes设置，包含3个复制主节点和几个工作节点，分为3个区域（这些是AWS可用区域，但它也可以是3个虚拟化硬件机器或类似）。其中一个服务（或者更确切地说，服务的pod）正在跨区域形成一个集群，以便在一个区域出现故障时仍然可用。使用反关联性规则分发pod。我将在服务的pod中运行的单个应用程序称为“应用程序节点”（而不是“节点”，它只是一个kubernetes节点）。
群集应用程序能够检测网络分区，并通过关闭少数区域中的容器中的应用程序来避免裂脑情况。让我们考虑以下布局：
如果在（A，B）和（C）之间进行网络分区，则在区域C中运行的应用程序将自行关闭。
现在麻烦的是，区域C中的主人将重新创建该服务的pod，从而形成一个全新的应用程序集群，这正是我们在这种情况下要避免的。
我想告诉kubernetes不要在区域C中为此服务重新创建pod，直到解析网络分区。据我所知，这将涉及：
1）告诉kubernetes不要在区域C中重新创建pod 2）告诉kubernetes允许在区域C中创建pod，网络分区已经结束
我认为这可以通过相应创建和删除的节点污点来实现。
1）理想情况下，我希望能够通过退出代码发出信号，尽管我不认为这是可用的。我可以通过从C区域中的应用程序节点调用kubernetes API来设置节点污染，然后关闭它自己，尽管如果可以在部署中声明这种行为可能会很好。
对于2）我不太清楚如何继续。 Kubernetes可能会将区域C中的主节点和工作节点视为区域A和B不健康，但我不知道是否有任何特定事件会发出信号表明它们再次健康并且可以利用它来消除区域中的节点在这种情况下是C.我认为在kubernetes中没有办法做到这一点所以我认为我必须在应用程序层上设置这个逻辑并监听（？）与节点运行状况相关的事件，然后调用kubernetes API来消除污染节点。
因此我的问题是：
1）是否有一个API端点，我可以查询以获取与节点运行状况相关的事件，以及这些类型的事件是什么？
2）更一般地说，kubernetes调度程序是否有任何设计考虑/功能计划来解决网络分区/故障的主题？我没有在HA主人的documentation或design document上找到关于此的更多信息。我认为，需要在kubernetes和kubernetes本身部署的群集感知应用程序之间进行协调。
假设我们正在讨论的应用程序是某种外部暴露的服务，我建议在检测到拆分时不要退出应用程序，而应该开始为准备探测返回错误代码。这样你就不会关闭pod - 所以没有娱乐，但是在分裂发生时将它们标记为不准备服务生产流量。