k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患？
考点之什么情况下，需要强制删除 StatefulSet 的 Pod?
考点之如果 StatefulSet 操作不当可能会引发什么很严重的后果？
考点之如果遇到Pod 长时间处于 'Terminating' 或者 'Unknown' 状态情况，有什么安全一些的处理手段吗？
囧么肥事-胡说八道
线上某些特殊情况下可能需要强制删除 StatefulSet 的 Pod？
什么情况下，需要强制删除 StatefulSet 的 Pod?
正常情况下
StatefulSet 常规场景下，不需要强制删除 StatefulSet 管理的 Pod。
StatefulSet 控制器会负责创建、 扩缩和删除 StatefulSet 管理的 Pods。
它尝试确保指定数量的从序数 0 到 N-1 的 Pod 处于活跃状态并准备就绪。
StatefulSet 遵循At Most One（最多一个）规则，确保在任何时候，集群中最多只有一个具有给定标识的 Pod。
特殊情况下
所谓特殊情况下必须进行强制删除，SS感知到当某个节点不可达时，不会引发自动删除 Pod。在无法访问的节点上运行的 Pod 在超时 后会进入'Terminating' 或者 'Unknown' 状态，另外当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。
如果你发现 StatefulSet 的某些 Pod 长时间处于 'Terminating' 或者 'Unknown' 状态
无法自己完成正常的调度，为了k8s集群的稳定服务，这个时候可能需要手动干预，以强制的手段从 API 服务器中删除这些 Pod。
如果StatefulSet 操作不当可能会引发什么很严重的后果？
应谨慎进行手动强制删除操作，因为它可能会违反 StatefulSet 固有的至多一个的规则。
StatefulSets 用于运行分布式和集群级的应用，这些应用需要稳定的网络标识和可靠的存储。
这些应用通常配置为具有固定标识固定数量的成员集合，每个Pod都是唯一的，独立的，你可以理解为每个人的身份证编号都是唯一的。
具有相同身份的多个成员（Pod）可能是灾难性的，可能导致数据丢失 (例如：票选系统中的脑裂场景)。
而强制删除，可能就会导致SS出现多个Pod使用同一张身份证。
违反了”每人一证“原则。
问题来了，为什么就会出现多个相同标识的Pod呢？
原来，不同于Pod体面终止的是，在进行强制删除过程中，API 服务器不会等待来自 kubelet 对 Pod 已终止的确认消息，它会立即从 API 服务器中释放该名字。
我们知道StatefulSet 中每个Pod有固定标识，而且不随着Pod的重新调度而改变。
在进行重新调度的时候，新调度创建的Pod会继承上一个旧Pod的一切有用资源，比如PV，唯一标识，网络标识等。
强制删除，直接从API服务器移除Pod对象，这个时候，StatefulSet 控制器有机会去创建一个具有相同标识的替身 Pod，并且去继承旧Pod的资源。
尚未完全删除Pod，如果创建了替身，那么此时和替身共享一个唯一标识，违反 StatefulSet 固有的至多一个的规则。
这是后果，主要的还是它的附带后果。
是什么呢？最绝的来了，尚未完全删除的 Pod 仍然可以与 StatefulSet 的成员通信，也就是说它仍然可以操作PV，可能导致PV数据流失。
如果遇到Pod 长时间处于 'Terminating' 或者 'Unknown' 状态情况，有什么安全一些的处理手段吗？
安全处理？
既然知道了问题产生的原因，有什么安全一些的处理手段吗？
如果遇到Pod 长时间处于 'Terminating' 或者 'Unknown' 状态情况，再进行强制删除之前可以先考虑以下处理方式：
第一种情况，如果确认节点已经不可用了 (比如，永久断开网络、断电等)， 可以主动删除掉点节点对象，或者通过节点控制器来进行删除。
第二种情况，如果节点遇到网裂问题，请尝试解决该问题或者等待其解决。 当网裂愈合时，kubelet 将完成 Pod 的删除并从 API 服务器上释放其名字。
第三种情况，必须强制，无可选择。⚠️当你确定必须执行强制删除 StatefulSet 类型的 Pod 时，你要确保有问题的 Pod 不会再和 StatefulSet 管理的其他 Pod 通信并且可以安全地释放其名字以便创建替代 Pod。
Kubernetes 推荐学习书