k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()
k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患?
考点之什么情况下,需要强制删除 StatefulSet 的 Pod?
考点之如果 StatefulSet 操作不当可能会引发什么很严重的后果?
考点之如果遇到Pod 长时间处于 'Terminating' 或者 'Unknown' 状态情况,有什么安全一些的处理手段吗?
![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/3bf0d376d6f24b73bf1362eab9aab789.gif)
文章图片
囧么肥事-胡说八道
![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/efe39f351597449e8d4c112ceb3e09d1.jpg)
文章图片
![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/276864deb2e247e8911f5ce308924181.jpg)
文章图片
线上某些特殊情况下可能需要强制删除 StatefulSet 的 Pod?
什么情况下,需要强制删除 StatefulSet 的 Pod?
正常情况下
StatefulSet
常规场景下,不需要强制删除 StatefulSet
管理的 Pod。StatefulSet
控制器会负责创建、 扩缩和删除 StatefulSet
管理的 Pods。它尝试确保指定数量的从序数
0 到 N-1 的 Pod
处于活跃状态并准备就绪。StatefulSet
遵循At Most One
(最多一个)规则,确保在任何时候,集群中最多只有一个具有给定标识的 Pod。![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/7ab55b27274648bab2b8b7e2954cea64.gif)
文章图片
特殊情况下
所谓特殊情况下必须进行强制删除,SS感知到当某个节点不可达时,不会引发自动删除 Pod。在无法访问的节点上运行的 Pod 在超时 后会进入'
Terminating
' 或者 'Unknown
' 状态,另外当用户尝试体面地删除无法访问的节点上的 Pod 时 Pod 也可能会进入这些状态。如果你发现 StatefulSet 的某些 Pod 长时间处于 '
Terminating
' 或者 'Unknown
' 状态无法自己完成正常的调度,为了k8s集群的稳定服务,这个时候可能需要手动干预,以强制的手段从 API 服务器中删除这些 Pod。
如果StatefulSet 操作不当可能会引发什么很严重的后果?
应谨慎进行手动强制删除操作,因为它可能会违反 StatefulSet 固有的至多一个的规则。
StatefulSets
用于运行分布式和集群级的应用,这些应用需要稳定的网络标识和可靠的存储。这些应用通常配置为具有固定标识固定数量的成员集合,每个Pod都是唯一的,独立的,你可以理解为每个人的身份证编号都是唯一的。
具有相同身份的多个成员(Pod)可能是灾难性的,可能导致数据丢失 (例如:票选系统中的脑裂场景)。
而强制删除,可能就会导致SS出现多个Pod使用同一张身份证。
违反了”每人一证“原则。
![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/c9bb653321d14a279e6cd428c759635f.jpg)
文章图片
问题来了,为什么就会出现多个相同标识的Pod呢?
原来,不同于Pod体面终止的是,在进行强制删除过程中,API 服务器不会等待来自 kubelet 对 Pod 已终止的确认消息,它会立即从 API 服务器中释放该名字。
我们知道
StatefulSet
中每个Pod有固定标识,而且不随着Pod的重新调度而改变。在进行重新调度的时候,新调度创建的Pod会继承上一个旧Pod的一切有用资源,比如PV,唯一标识,网络标识等。
强制删除,直接从API服务器移除Pod对象,这个时候,
StatefulSet
控制器有机会去创建一个具有相同标识的替身 Pod,并且去继承旧Pod的资源。尚未完全删除Pod,如果创建了替身,那么此时和替身共享一个唯一标识,违反 StatefulSet 固有的至多一个的规则。
这是后果,主要的还是它的附带后果。
是什么呢?最绝的来了,尚未完全删除的 Pod 仍然可以与 StatefulSet 的成员通信,也就是说它仍然可以操作PV,可能导致PV数据流失。
![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/c9e343f327c24403a66622dcbc0db70a.gif)
文章图片
如果遇到Pod 长时间处于 '
Terminating
' 或者 'Unknown
' 状态情况,有什么安全一些的处理手段吗?安全处理?
既然知道了问题产生的原因,有什么安全一些的处理手段吗?
如果遇到Pod 长时间处于 '
Terminating
' 或者 'Unknown
' 状态情况,再进行强制删除之前可以先考虑以下处理方式:第一种情况,如果确认节点已经不可用了 (比如,永久断开网络、断电等), 可以主动删除掉点节点对象,或者通过节点控制器来进行删除。
第二种情况,如果节点遇到网裂问题,请尝试解决该问题或者等待其解决。 当网裂愈合时,
kubelet
将完成 Pod 的删除并从 API 服务器上释放其名字。第三种情况,必须强制,无可选择。??当你确定必须执行强制删除
StatefulSet
类型的 Pod 时,你要确保有问题的 Pod 不会再和 StatefulSet 管理的其他 Pod 通信并且可以安全地释放其名字以便创建替代 Pod。![k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()](https://img.it610.com/image/info8/658c986134e04201887a3f2507aedbf2.gif)
文章图片
获取更多干货,欢迎关注微信公众号:囧么肥事Kubernetes 推荐学习书
【k8s线上某些特殊情况强制删除|k8s线上某些特殊情况强制删除 StatefulSet 的 Pod 要考虑什么隐患()】Kubernetes权威指南PDF
链接: https://pan.baidu.com/s/11huLHJkCeIPZqSyLEoUEmQ 提取码:sa88
推荐阅读
- 二进制部署1.23.4版本k8s集群-3-部署架构及根证书签发
- 微服务从代码到k8s部署应有尽有系列(十四、部署环境搭建)
- k8s|k8s pod报错Process failed to launch spawn E2BIG
- python|python selenium禁止加载某些请求的实现
- 二进制部署1.23.4版本k8s集群-2-安装DNS服务
- 二进制部署1.23.4版本k8s集群-1-系统安装及环境准备
- 19.容器交付介绍
- k8s之service实现服务发现和负载均衡
- Kubernetes|k8s 1.20.2 coredns解析问题
- k8s部署一个带有mysql应用_Kubernetes之有状态应用实践-搭建MySQL集群