k8s線上某些特殊情況強制刪除 StatefulSet 的 Pod 要考慮什麼隱患？
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 推薦學習書
Kubernetes權威指南PDF
鏈接: //pan.baidu.com/s/11huLHJkCeIPZqSyLEoUEmQ 提取碼:sa88
