生產環境想要對某個Pod排錯、數據恢復、故障復盤有什麼辦法？
生產環境想要對某個Pod排錯、數據恢復、故障復盤有什麼辦法？
k8s考點靈魂拷問9連擊之5
考點之簡單描述一下k8s副本集ReplicaSet有什麼作用？
考點之為什麼ReplicaSet將取代ReplicationController控制器？
考點之編寫 ReplicaSet 的 spec 有什麼需要注意的點？
考點之k8s集群中創建非模板 Pod 為什麼可能會被副本集自動收納？
考點之線上預警k8s集群循環創建、刪除Pod副本，一直無法穩定指定目標副本數量?
如果排除了是Pod內部發生了故障，從RS角度你猜測可能是什麼原因？
上一期，討論了前面五個考點，感興趣去可以看一看【點我進入傳送門】，好了，接下來繼續看本期4個考點!
考點之標籤Pod和可識別標籤副本集ReplicaSet 先後創建順序不同，會造成什麼影響？
考點之生產環境想要對某個Pod排錯、數據恢復、故障復盤有什麼辦法？
考點之縮放 RepliaSet 有哪些算法策略？
考點之如何去影響淘汰策略，設置單獨偏好？
囧么肥事-胡說八道
考點之標籤Pod和可識別標籤副本集ReplicaSet 先後創建順序不同，會造成什麼影響？
假設給Pod打上的標籤是 AA，同時RS標籤選擇器設置匹配 AA。
分為兩種情況
### 預設RS標籤和副本數量
RS-AA 標籤選擇器可識別 AA 標籤
設置副本15個
### 預設Pod標籤
裸Pod-AA 標誌標籤 AA
第一種：RS已經創建，裸Pod隨後創建
情況一：
副本等於15個，此時創建 Pod-AA
結果：
新的 裸Pod-AA 會被該 RS-AA 識別
副本數 > 15，開啟平衡機制
新Pod立即被 RS 終止並實行刪除操作
情況二：
副本小於15個，此時創建 Pod-AA
結果：
裸Pod-AA 創建後立即被 RS-AA識別
副本數 <= 15，開啟平衡機制，收管裸Pod
第二種：裸Pod先創建，隨後創建RS
情況一：
創建了小於等與15個裸Pod-AA，此時創建 RS-AA
結果：
RS-AA 創建成功後
發現存在有AA標籤的Pod
將所有的Pod-AA納入自己管轄範圍
副本數 < 15，開啟平衡機制
由RS-AA繼續創建剩餘Pod-AA補充夠15個
情況二：
創建了大於15個裸Pod-AA，此時創建 RS-AA
結果：
RS-AA 創建成功後
發現存在有AA標籤的Pod
將所有的Pod-AA納入自己管轄範圍
副本數 > 15，開啟平衡機制
RS-AA實行刪除多餘Pod操作
直到副本數維持在15個
結論：無論RS何時創建，一旦創建，會將自己標籤選擇器能識別到的所有Pod納入麾下，接管生存權，遵循RS規約定義的有效副本數，去開啟平衡機制，維持有效標籤Pod的副本數。
總之，RS儘力保證系統當前正在運行的Pod數等於期望狀態里指定的Pod數目。
如果想要獨立創建可生存的裸Pod，一定要檢查所有的RS標籤選擇器的可識別範圍，避免自己創建的裸Pod被收納接管。
考點之生產環境想要對某個Pod排錯、數據恢復、故障復盤有什麼辦法？
如果線上發現有些Pod沒有按照我們期望的狀態來進行運行，發生了某些故障，但是其他同類型Pod卻沒有發生。
這種故障一般屬於不易復現的故障，只會在某些偶然性的條件下觸發故障，但是這個觸發條件我們又不清楚，所以我們要專門針對這個故障進行問題排查。
這個時候又不希望在排查過程中影響服務的正常響應，那該怎麼辦呢？
隔離法，所謂隔離法，就是將 Pod 從 ReplicaSet 集合中隔離出來，讓Pod脫離RS的管控範圍，額有點類似贖身。
可以通過改變標籤來從 ReplicaSet 的目標集中移除 Pod。
這種技術可以用來從服務中去除 Pod，以便進行排錯、數據恢復等。
以這種方式移除的 Pod 將被自動替換（假設副本的數量沒有改變）。
通過隔離這個目標Pod，RS會自動補充副本Pod去保證集群的高可用，我們不必擔心影響到服務線的正常響應。這時候就可以針對這個目標Pod做排查，研究，里里外外的想幹啥，就幹啥，嘿嘿😋。
班級（標籤666班）
老師（RS-666）
學生15個（學生證標籤666班）
-----------------------------
每天上課，老師都檢查學生證入班
學生1號：學生證-666班，進去
學生2號：學生證-666班，進去
...
學生20號：學生證-666班，進去
某天，學生9號的學生證被人改了999班
學生1號：學生證-666班，進去
學生2號：學生證-666班，進去
...
學生9號：學生證-999班，老師攔住了9號，不許進
...
學生20號：學生證-666班，進去
這個老師跟RS一樣，很偏激，只認學生證（RS只認標籤），不認人。如果改了標籤，就認不出了，自己也不會再去接管了。
考點之縮放 RepliaSet 有哪些算法策略？
通過更新 .spec.replicas 字段，指定目標Pod副本數量，ReplicaSet 可以很輕鬆的實現縮放。
而且，ReplicaSet 控制器能確保經過縮放完成留下來的Pod數量不僅符合要求副本數量，而且Pod是可用，可操作的。
RS擴容不必說，肯定創建新的Pod副本，納入管理。
至於縮容，降低集合規模時ReplicaSet 控制器會對所有可用的Pods 進行一次權重排序，剔除最不利於系統高可用，穩健運行的Pod。
其一般性算法如下：
- 首先優先選擇剔除阻塞（Pending）且不可調度的 Pods。
- 如果設置了
controller.kubernetes.io/pod-deletion-cost註解，則註解值較小的優先被剔除。 - 所處節點上副本個數較多的 Pod 優先於所處節點上副本較少者被剔除。
- 如果 Pod 的創建時間不同，最近創建的 Pod 優先於早前創建的 Pod 被剔除。
如果以上比較結果都相同，則隨機剔除。
考點之如何去影響淘汰策略，設置單獨偏好？
前說了，RS在進行縮容操作時，有自己的一套淘汰策略。根據四種淘汰策略進行權重排序，去剔除RS認為不利於系統穩健運行的Pod。
同一應用的不同 Pods 可能其利用率是不同的。在對應用執行縮容操作時，可能希望移除利用率較低的 Pods。
那麼我們怎麼做，才能去影響到RS的淘汰機制，保留我們自己認為需要保留的Pod呢？
前面提到了controller.kubernetes.io/pod-deletion-cost 註解值較小的Pod會優先被剔除。
我們可以通過這個註解去影響RS淘汰機制，設置個人保留偏好。
那麼什麼是controller.kubernetes.io/pod-deletion-cost 註解？
此註解設置到 Pod 上，取值範圍為 [-2147483647, 2147483647]，如果註解值非法，API 服務器會拒絕對應的 Pod。
表示從RS中刪除Pod所需要花費的開銷。
RS認為刪除開銷較小的 Pods 比刪除開銷較高的 Pods 更容易被刪除，更有利於系統的穩健運行。
不過此機制實施僅是儘力而為，並不能保證一定會影響 Pod 的刪除順序。只能說是愛妃給皇上吹枕邊風，真正做出決定的還是皇上。
注意：
此功能特性處於 Beta 階段，默認被禁用。
通過為 kube-apiserver 和 kube-controller-manager 設置特性門控 PodDeletionCost 開啟功能。
推薦閱讀：【探針配置失誤，線上容器應用異常死鎖後，kubernetes集群未及時響應自愈重啟容器？】
推薦休閑閱讀：【囧么肥事】
