1. 手動管理Pod的那段日子ReplicaSet到底在解決什么問題1.1 只創(chuàng)建Pod的暴力做法應(yīng)用掛了就只能認栽剛玩Kubernetes那陣子我干過一件特別傻的事寫了一個nginx的Pod YAMLkubectl apply -f起了三個Pod然后一整天就盯著終端看生怕哪個Pod突然退出。那時候運維群里天天有人喊節(jié)點宕了容器OOM了應(yīng)用半夜掛了我第一反應(yīng)都是回去重新apply一遍YAML。這種手動重建的方式在實驗環(huán)境還能撐一下放到企業(yè)環(huán)境基本就是災(zāi)難。你自己想一套訂單服務(wù)要跑20個副本凌晨兩點掛掉3個服務(wù)降級你能忍就算你能忍誰深更半夜爬起來執(zhí)行那段重建命令這種操作背后本質(zhì)上暴露了一個關(guān)鍵問題——Pod是一次性資源它的宿主機沒救回來這個Pod就沒了它本身崩潰退出也沒有任何東西會把它拉起來。Kubernetes叫容器編排平臺如果連最基本的維持副本數(shù)量都做不到那編排兩個字就名不副實了。ReplicaSet就是來解決這個問題的。它做的事情通俗地講就一句話你告訴它我要3個滿足條件的Pod它就不分晝夜地保證集群里始終有恰好3個這樣的Pod。多了一個就刪掉少了一個就補上死了一個就再拉一個起來。這個機制奠定了Kubernetes里所有無狀態(tài)工作負載的基礎(chǔ)。你平時用的Deployment、StatefulSet、DaemonSet底層其實都躲不開ReplicaSet這套管理邏輯。1.2 一個管家該有的三樣?xùn)|西副本數(shù)、選擇器、Pod模板ReplicaSet的YAML看起來結(jié)構(gòu)簡單但三個核心字段缺一不可我分別說一下它們在企業(yè)環(huán)境里各自承擔什么角色。spec.replicas期望的Pod副本數(shù)量。它只是一個數(shù)字控制器會以這個數(shù)為基準不斷比對集群里的實際數(shù)量。spec.selector選擇器。它決定了ReplicaSet管哪些Pod。ReplicaSet靠Pod上的label來識別自己的手下。你只要給Pod打上對應(yīng)的標簽它就會被這個ReplicaSet接管哪怕這個Pod根本不是這個ReplicaSet創(chuàng)建的它也會被收編。spec.templatePod模板。這是ReplicaSet創(chuàng)建新Pod時用的圖紙——每次需要補齊副本時都照著這張圖紙捏一個Pod出來。這三個字段的關(guān)系我用一個不太嚴謹?shù)芎美斫獾念惐日f明ReplicaSet像一個帶工頭的施工隊replicas是甲方要求的樓層數(shù)selector是工頭認人的標準戴紅帽子的歸我管template是蓋樓用的圖紙。樓層不夠就按圖紙蓋樓蓋多了就拆掉不戴紅帽子的樓工頭每天都在工地數(shù)人頭。1.3 ReplicaSet在企業(yè)集群中的真實定位在企業(yè)生產(chǎn)集群里你直接見到的ReplicaSet往往不是自己寫出來的而是Deployment創(chuàng)建出來的。很多人查完P(guān)od之后會發(fā)現(xiàn)一堆名字帶隨機后綴的rs-xxxxx第一反應(yīng)是我什么時候創(chuàng)建了這玩意兒。其實Deployment本身不直接管Pod它管的是ReplicaSet由ReplicaSet去管Pod。這個層級關(guān)系保證了Deployment可以做滾動更新、可以回滾——每次發(fā)版本Deployment都新建一個ReplicaSet新RS的Pod慢慢頂上舊RS的Pod慢慢撤下回滾的時候直接把舊RS的副本數(shù)擴回來就行。所以我的建議是只要你不是在做控制器本身的開發(fā)日常工作中請把ReplicaSet當作一個底層機制來理解而不是當作一個操作入口。但是底層機制一定要吃透否則你排查Deployment滾動更新卡住、Pod數(shù)量異常這些問題時會像無頭蒼蠅一樣亂撞。2. 拆開RS的黑盒子控制循環(huán)與選擇器匹配的底層邏輯2.1 控制循環(huán)怎么把期望狀態(tài)變成集群里的現(xiàn)實狀態(tài)ReplicaSet能維持副本數(shù)靠的是Kubernetes里最經(jīng)典的控制器模式Control Loop。我調(diào)試的集群版本是v1.26.0這套機制從早期版本到現(xiàn)在基本沒變過后面我會提到的大多數(shù)命令在1.20到1.30系列都能通用?？刂蒲h(huán)大致是這樣的流程ReplicaSet控制器運行在kube-controller-manager這個組件里通過informer機制持續(xù)監(jiān)聽ReplicaSet和Pod的增刪改事件。一旦發(fā)現(xiàn)某個ReplicaSet的期望副本數(shù)和實際匹配Pod數(shù)不一致控制器就把這個ReplicaSet放進自己的同步隊列。控制器從隊列里取出這個對象計算當前的Pod數(shù)量、檢查每個Pod的狀態(tài)然后調(diào)用kube-apiserver創(chuàng)建或刪除Pod。這個機制最巧妙的一點是事件驅(qū)動而不是定時輪詢。也就是說Pod掛了、Pod被刪了、節(jié)點漂移了這些事件會馬上觸發(fā)控制器去校正。你不太需要擔心控制器反應(yīng)遲鈍的問題生產(chǎn)環(huán)境里Pod刪掉之后幾秒鐘內(nèi)就會被重新創(chuàng)建出來。不過這里有個很容易被忽視的細節(jié)控制器判斷要不要創(chuàng)建Pod看的不是這個ReplicaSet以前創(chuàng)建過幾個Pod而是集群中還有多少Pod的標簽匹配這個ReplicaSet的selector。換句話說它只認標簽不認親爹。這既是一個很靈活的設(shè)計也是一顆埋在配置錯誤里的雷。2.2 選擇器的匹配規(guī)則標簽不是裝飾品ReplicaSet的selector支持兩種寫法matchLabels和matchExpressions。matchLabels最常用寫法就是鍵值對精確匹配多個標簽之間是AND關(guān)系。舉個例子selector: matchLabels: app: nginx tier: frontend這段代碼要求匹配的Pod必須同時帶appnginx和tierfrontend兩個標簽。只滿足其中一個是不行的控制器算副本數(shù)的時候不會把它算進去。matchExpressions更靈活支持In、NotIn、Exists、DoesNotExist這幾種操作符。比如下面的寫法表示挑出所有環(huán)境標簽不是prod的Pod來管理selector: matchExpressions: - key: env operator: NotIn values: - prodmatchExpressions和matchLabels可以同時存在多個條件之間同樣是AND關(guān)系。這里有一個我在企業(yè)排障中反復(fù)強調(diào)的要點ReplicaSet的selector一旦創(chuàng)建就不可修改這是API設(shè)計的硬限制。你想改selector刪掉這個ReplicaSet重新建一個吧。為什么這么設(shè)計因為允許運行中的控制器隨意改匹配規(guī)則會造成Pod管理歸屬的混亂——一個RS原本管著10個Podselector一改那10個Pod瞬間變成沒人要的孤兒又有10個別人的Pod可能被它強行接管這是生產(chǎn)環(huán)境里絕對不能接受的。2.3 ReplicaSet的邊界只管數(shù)量不管死活之外的事很多人對ReplicaSet有一個誤解以為它像一個自動恢復(fù)機器人Pod里的容器掛了它會去重啟。其實不是的ReplicaSet管不了這么多。它關(guān)注的只有一件事匹配這個selector的Pod總數(shù)是否等于期望副本數(shù)。如果容器里的進程崩潰了但Pod本身還處于Running狀態(tài)ReplicaSet數(shù)人頭的時候發(fā)現(xiàn)數(shù)量沒變它就不會做任何動作。容器進程崩潰后的重啟通常要交給Pod里的restartPolicy來處理默認的Always策略會讓kubelet嘗試重啟容器這跟ReplicaSet沒有關(guān)系。而當Pod整個被刪除、節(jié)點宕機導(dǎo)致Pod被驅(qū)逐、或者有人手動把Pod標簽改掉了導(dǎo)致它不再匹配selector時ReplicaSet才會介入。也正是因為這個邊界的存在生產(chǎn)環(huán)境里你才需要搭配存活探針和就緒探針讓Pod在看似活著但實際上已經(jīng)無法服務(wù)的時候被標記為不健康觸發(fā)重啟或從Service后端摘除這個話題我在后面的踩坑章節(jié)會展開聊。3. 動手實驗從第一份YAML到故障自愈全流程3.1 第一份RS的YAML應(yīng)該怎么寫紙上談兵說得再多不如自己敲一遍。下面這份YAML我建議你直接存下來作為實驗基準apiVersion: apps/v1 kind: ReplicaSet metadata: name: nginx-rs-demo namespace: default spec: replicas: 3 selector: matchLabels: app: nginx-demo template: metadata: labels: app: nginx-demo spec: containers: - name: nginx image: nginx:1.25 ports: - containerPort: 80注意一下版本apiVersion用的是apps/v1早期版本的extensions/v1beta1早就廢棄了新集群里不要再寫。selector部分模板里的Pod標簽一定要能匹配上selector這是一個新手經(jīng)常犯的低級錯誤——寫完selector和template之后兩臺對不上導(dǎo)致ReplicaSet創(chuàng)建半天Pod數(shù)量還是0。這個文件創(chuàng)建之后控制器會發(fā)現(xiàn)集群里沒有任何Pod帶appnginx-demo這個標簽于是按照template的圖紙連續(xù)創(chuàng)建3個Pod。3.2 創(chuàng)建與驗證常用觀測命令大盤點創(chuàng)建命令沒什么好說的kubectl apply -f rs-demo.yaml驗證的時候別只看一眼Pod列表就完事我建議養(yǎng)成一套標準的觀測順序# 看ReplicaSet整體狀態(tài) kubectl get rs nginx-rs-demo -o wide # 看控制器當前期望數(shù)量和實際數(shù)量 kubectl describe rs nginx-rs-demo # 看它管理的Pod以及Pod歸屬 kubectl get pods -l appnginx-demokubectl describe rs輸出的下半部分非常關(guān)鍵里面有ReplicaSet控制器在運行過程中記錄的Events比如成功創(chuàng)建Pod成功刪除Pod副本數(shù)不滿足目的地狀態(tài)等信息。這些事件是排障的起點但很多同學(xué)一上來就盯著Pod日志看方向就反了。3.3 擴縮容的三種姿勢在ReplicaSet上做擴縮容有三種常見方式我逐一列一下企業(yè)里都會用到第一種原地修改YAML然后用applyvim rs-demo.yaml kubectl apply -f rs-demo.yaml把spec.replicas改成5apply之后控制器會立刻把Pod數(shù)量補齊到5。第二種用scale命令直接指定副本數(shù)kubectl scale rs nginx-rs-demo --replicas5這種方式的本質(zhì)是修改ReplicaSet的/scale子資源。HPA橫向自動擴縮容在底層調(diào)用的也是這個接口后面我會展開說。第三種用patch做局部修改kubectl patch rs nginx-rs-demo -p {spec:{replicas:5}}三種方式的效果完全一樣選哪種取決于你當時的工作習(xí)慣。需要寫成基礎(chǔ)設(shè)施即代碼IaC時用第一種應(yīng)急擴縮容時用第二種腳本自動化時用第三種。3.4 親測Pod故障自愈把Pod刪掉看會發(fā)生什么實驗做到這一步最爽的時刻來了。隨便刪一個ReplicaSet管理的Podkubectl delete pod nginx-rs-demo-xxxxx幾秒鐘內(nèi)你再執(zhí)行kubectl get pods會發(fā)現(xiàn)一個全新的Pod出現(xiàn)在列表里名字后綴跟之前那個完全不一樣。ReplicaSet通過控制器循環(huán)感知到了Pod數(shù)量從3掉到了2立刻按圖施工補了一個新的。這個自愈動作不需要任何人工介入我在生產(chǎn)環(huán)境里驗證過很多次把Pod刪了新Pod生成的速度通常在12秒級別如果集群本身負載比較重可能會慢一些但不至于等很久。這里還可以做一個更極端的實驗把Pod上匹配selector的標簽改掉比如把appnginx-demo改成appnginx-demo-other。你會發(fā)現(xiàn)ReplicaSet根本不跟你商量直接再創(chuàng)建一個新Pod。而被你改掉標簽的那個Pod因為它已經(jīng)不再匹配任何ReplicaSet的selector就變成了一個孤兒Pod孤零零地留在集群里沒人管理它。這種孤兒Pod在生產(chǎn)故障中經(jīng)常出現(xiàn)后面我會專門講它的危害。3.5 修改模板之后的一個大坑舊Pod不會被自動替換很多第一次使用ReplicaSet的人會踩一個隱蔽的坑改了template里的鏡像版本然后apply發(fā)現(xiàn)Pod列表毫無變化。這其實不是bug而是ReplicaSet的天然行為template只影響以后新建的Pod已經(jīng)存在的Pod統(tǒng)統(tǒng)一律不動。你想讓新鏡像生效手動把這幾個Pod挨個刪掉讓ReplicaSet按新模板重建或者直接把整個ReplicaSet刪掉重建。你可以自己實驗一下把image從nginx:1.25改成nginx:1.26然后apply再觀察Pod的鏡像版本你會發(fā)現(xiàn)老Pod紋絲不動。這個體驗跟Deployment的滾動更新相比簡直天差地別這也是為什么真實企業(yè)環(huán)境里幾乎沒人直接裸用ReplicaSet——它真的只負責保數(shù)量至于如何平滑升級這件事它壓根不擅長。4. 企業(yè)環(huán)境里的RSDeployment的“幕后管家”與發(fā)布策略4.1 Deployment與RS的父子關(guān)系你看到的那堆RS才是發(fā)布本體前面提到過Deployment不直接管Pod它管ReplicaSet。這句抽象的話在kubectl get rs的輸出里是能直觀看到的kubectl get rs -n your-namespace你會看到每個Deployment下面掛著好幾個ReplicaSet名字通常是deployment名稱-模板哈希。模板哈希是根據(jù)Pod template算出來的template一變哈希就變Deployment就會新建一個RS。這里有一個很多人在面試或者實際排障中翻車的問題為什么Deployment要設(shè)計成Deployment管RS、RS管Pod這樣的兩層級式結(jié)構(gòu)我的理解是Deployment需要版本化發(fā)布過程。每一次YAML變更、每一次滾動更新都是基于一個模板的變更。如果把Pod模板直接綁在Deployment上就沒有辦法保留上一個版本的Pod長什么樣這個信息。有了RS這一層中介Deployment的每次發(fā)布都會留下一個歷史RS里面凍結(jié)了當時那份Pod模板?；貪L的時候Deployment只需要把流量從當前RS切回歷史RS把舊RS的副本數(shù)擴起來、把新RS的副本數(shù)縮下去整個發(fā)布狀態(tài)就退回去了。這是非常聰明的設(shè)計。4.2 滾動更新過程中的RS數(shù)量變化一升一降的節(jié)奏美學(xué)默認情況下Deployment的滾動更新是先建新RS再縮舊RS的漸進過程。我以一批業(yè)務(wù)服務(wù)為例假設(shè)副本數(shù)10、maxSurge25%、maxUnavailable25%新RS先被創(chuàng)建出來期望副本數(shù)先從0變成某個低于10的過渡值。新RS的Pod逐步Ready之后舊RS的副本數(shù)開始逐步下調(diào)。整個過程中總Pod數(shù)會維持在1012之間maxSurge允許臨時超出不可用的Pod數(shù)控制在2個以內(nèi)maxUnavailable允許臨時減少。如果你在滾動更新過程中不斷執(zhí)行kubectl get rs你會看到新舊兩個RS的副本數(shù)像蹺蹺板一樣一個往上走另一個往下走。這時候如果哪個RS卡住了比如新Pod一直Pending、一直ImagePullBackOff滾動更新就會卡在原地不動Deployment會一直維持這個新舊并存的狀態(tài)。這時候排查目標就非常明確了問題出在新RS而不是Deployment本身。4.3 為什么企業(yè)不建議直接操作RS版本管理的底線我在企業(yè)里做分享的時候經(jīng)常說一句話Deployment是正規(guī)軍裸RS是游擊隊。直接操作ReplicaSet意味著你放棄了幾個企業(yè)級的關(guān)鍵能力第一放棄了滾動升級能力。前面實驗里驗證過改RS的template不會影響舊Pod你要手動刪Pod或者整個重建業(yè)務(wù)會短暫中斷。第二放棄了版本記錄和回滾能力。Deployment天然保留歷史RS你可以一條命令回滾到上一個版本裸RS沒有這個機制你改壞了只能憑記憶恢復(fù)。第三放棄了發(fā)布策略的精細控制。Deployment的strategy字段里支持RollingUpdate、Recreate兩種策略配合maxSurge和maxUnavailable可以精確控制發(fā)布節(jié)奏。裸RS完全不存在這些概念。所以在生產(chǎn)環(huán)境里我的建議非常明確除非你寫的是一個自定義控制器或者明確知道自己在干什么否則永遠不要手寫ReplicaSet來承載業(yè)務(wù)。讓Deployment去創(chuàng)建RS你在旁邊做監(jiān)督和排障就夠了。4.4 資源配額、探針與HPA聯(lián)動RS在企業(yè)中的配套玩法ReplicaSet雖然不管資源配額和健康檢查但它創(chuàng)建的Pod必須滿足這些約束才能正常存活。企業(yè)環(huán)境里我會強調(diào)三件事第一件事是requests和limits必須配好。RS創(chuàng)建Pod時如果template里沒有寫資源請求調(diào)度器會按零請求處理。生產(chǎn)中常見的情況是節(jié)點上明明有資源Pod卻一直Pending因為requests超出了節(jié)點的可分配量。反過來limits不設(shè)容器OOM了ReplicaSet也只能按流程重建業(yè)務(wù)閃斷還是會照常發(fā)生。第二件事是readinessProbe和livenessProbe必須配好。我見過無數(shù)案例RS的副本數(shù)一直是正常的3/3但Service訪問就是報錯因為容器進程活著但內(nèi)部服務(wù)已經(jīng)不可用。就緒探針失敗時Pod不會從Service的Endpoints里摘除嗎會前提是你配置了readinessProbe沒配置的話Kubernetes會默認Pod進入Ready狀態(tài)流量照打故障自然就看起來正常。第三件事是HPA按需擴縮容落地在Scale子資源上。HorizontalPodAutoscaler通過調(diào)ReplicaSet的/scale子資源動態(tài)修改副本數(shù)。這里有一個經(jīng)典沖突要提醒你如果運維同事手動kubectl scale把副本數(shù)改成了10而HPA的期望副本數(shù)是3兩邊的期望狀態(tài)打架最終會以HPA的控制周期為準被拉回。解決方案是別手動scale由HPA管控的資源副本要調(diào)也是調(diào)HPA的min/max值。5. 踩坑實錄副本數(shù)顯示正常但Pod就是不Ready5.1 排障第一原則先看Event再看日志最后看配置每次有同事跑過來跟我說集群出問題了我第一句話都是先把Event貼出來。很多人習(xí)慣先去看Pod日志、看容器狀態(tài)這其實繞了遠路。ReplicaSet相關(guān)的故障事件里通常寫得非常清楚。執(zhí)行這條命令kubectl describe rs rs-name -n namespace我見過太多的事故排查是在Event里一眼就能定位的比如Failed to pull image0/5 nodes are available: 2 Insufficient cpu, 3 Insufficient memoryReadiness probe failed每一條都指向非常具體的故障類別。Event看完再去kubectl logs或者kubectl get pod -o yaml深入分析效率會高很多。5.2 鏡像拉取失敗最沒有技術(shù)含量但最高頻的企業(yè)問題這一類故障在Event里會看到ImagePullBackOff或ErrImagePull單純看Pod狀態(tài)的話它表現(xiàn)為ContainerCreating卡住不動ReplicaSet一直在報副本數(shù)不滿足。我總結(jié)過幾個最常用的原因按出現(xiàn)頻率排序鏡像Tag不存在。把nginx:1.26寫成了nginx:latest后來又改成nginx:1.26.0但鏡像倉庫里沒有1.26.0這個Tag。私有倉庫認證沒配好。imagePullSecrets沒寫或者secret過期了kubelet拉私有鏡像拿不到憑證一直403。鏡像倉庫網(wǎng)絡(luò)不通。企業(yè)在內(nèi)網(wǎng)拉鏡像時節(jié)點訪問不到倉庫地址或DNS解析失敗。Tag漂移。生產(chǎn)環(huán)境最忌諱寫latest這種可變Tag因為每次拉取到的鏡像內(nèi)容可能都不一樣ReplicaSet重建Pod時可能會拉到不同版本版本一致性直接被打亂。排查方式很簡單kubectl describe pod pod-name看一下Events或者直接docker pull那個鏡像在節(jié)點上手動驗證。企業(yè)里的規(guī)范做法是把鏡像Tag釘死到具體版本號并且把私有倉庫的拉取憑證提前配置好。5.3 資源不足導(dǎo)致PendingEvent會直接告訴你差多少ReplicaSet副本數(shù)正常但執(zhí)行kubectl get pods時能看到一個Pod狀態(tài)卡在Pending。Event里通常會寫0/6 nodes are available: 2 Insufficient cpu, 4 Insufficient memory.注意這組數(shù)字它意味著調(diào)度器已經(jīng)把集群里所有節(jié)點都算了一遍沒有一個節(jié)點同時滿足CPU和內(nèi)存的剩余資源。這種故障在早高峰流量上漲或者多個應(yīng)用同時發(fā)布時尤其常見。遇到這類問題排障思路是看節(jié)點真實資源使用情況kubectl top node需要metrics-server沒有就kubectl describe node看Allocated resources?？词遣皇悄硞€節(jié)點被taint污點標記調(diào)度器在默認情況下不會把Pod調(diào)度到帶污點的節(jié)點上。評估requests是不是設(shè)置過高。有些開發(fā)在寫資源請求時喜歡拍腦袋給個8核16G一個Pod就把節(jié)點壓滿了浪費又危險。5.4 就緒探針失敗副本數(shù)達標但流量異常的幕后黑手這個坑我單獨拎出來說因為它最具迷惑性?，F(xiàn)象是kubectl get rs顯示的副本數(shù)是3/3kubectl get pods也是3/3 Running但訪問Service就是間歇性報錯。問題通常出在readinessProbe上。如果探針配置不合理比如超時時間太短、初始等待時間不夠、探針路徑寫錯那么Pod的READY列可能是0/1跟Running狀態(tài)共存。kubectl get endpoints看Service后端時會發(fā)現(xiàn)Available的Pod少于3個甚至有0個。ReplicaSet只關(guān)心Pod的數(shù)量并不會因為就緒探針失敗就去刪除或重建Pod它認為我該管的3個Pod都在那里數(shù)量是對的剩下的事交給Service和下探針機制去處理。你要修正的是探針參數(shù)不是指責ReplicaSet。我在生產(chǎn)里常用的做法是先把探針的initialDelaySeconds稍微調(diào)大一點確保應(yīng)用啟動完成后再開始探測。5.5 選擇器誤配引發(fā)“同室操戈”RS接管了別人的Pod這一類坑屬于配置層面的低級錯誤但破壞力很大。場景是這樣的團隊A部署了一個帶有apporder-service標簽的Deployment團隊B后來也寫了一個ReplicaSetselector里也寫了matchLabels: {app: order-service}。結(jié)果B的ReplicaSet一創(chuàng)建就把A的Deployment下的一部分Pod當成了自己的手下開始按自己的副本數(shù)刪減它們。A的Pod突然少了A的Deployment控制器會立刻補建B的ReplicaSet也會因為數(shù)量不對而繼續(xù)調(diào)整。兩個控制器為了同一批Pod打架整個命名空間里Pod數(shù)量上下跳服務(wù)時好時壞這就是典型的控制器同室操戈。我在前面的原理章節(jié)里說過ReplicaSet只認標簽不認親爹這就是它在實際環(huán)境里的負面體現(xiàn)。企業(yè)里要避免這個問題核心手段是嚴格管控label命名空間和selector。各業(yè)務(wù)團隊用自己專屬的前綴作為標簽名例如app.kubernetes.io/name、app.kubernetes.io/instance這類語義化標簽而不是人人通用的appxxx。還有一個兜底辦法創(chuàng)建ReplicaSet之前先查一下當前集群中是否已有Pod帶相同標簽kubectl get pods -l apporder-service --all-namespaces如果查出來一堆不是你的Pod那你的selector一定要改不要往槍口上撞。5.6 孤兒Pod的危害刪了RS但保留Pod的詭異狀態(tài)還有一種企業(yè)里常見的場景有人刪除了一個ReplicaSet但使用了--cascadeorphan參數(shù)比如kubectl delete rs rs-name --cascadeorphan這個命令的意思是刪除ReplicaSet本身但保留它下面那些Pod不讓垃圾回收機制級聯(lián)刪除。執(zhí)行完之后你會發(fā)現(xiàn)一堆Pod仍然在Running但它們的ownerReference指向的那個RS已經(jīng)不存在了變成了一堆無人認領(lǐng)的Pod。這種孤兒Pod非常危險它們不受任何控制器管理你手動刪掉就刪掉了永遠不會被重建。如果這些Pod恰好帶了舊鏡像、帶著錯誤的標簽混在Service后端里流量還是會被派到它們頭上造成難以排查的詭異故障。遇到孤兒Pod處理辦法也簡單要么手動標注好標簽新建一個ReplicaSet或Deployment把它們接管起來要么直接刪掉它們讓真正的Deployment按模板重建。反正我的建議是別留這種三不管的在集群里清理干凈再睡踏實覺。6. 哪些場景能直接繞開Deployment只用ReplicaSet6.1 我認為可以直接裸用RS的少數(shù)場景前面章節(jié)反復(fù)強調(diào)企業(yè)里不要直接操作ReplicaSet但這話不能說死。在我實際接觸過的項目里有幾種場景裸用ReplicaSet是合適的甚至比用Deployment更干凈。一是自定義控制器場景。如果你自己寫了一個Kubernetes Operator或Controller需要管理一組無狀態(tài)Pod并且你打算自己實現(xiàn)發(fā)布策略和版本管理那你不依賴Deployment直接用ReplicaSet更純粹。比如某些定時任務(wù)系統(tǒng)或者分布式計算框架它們希望Pod生命周期完全受自己掌控Deployment那套自動滾動反而不是它們想要的。二是只關(guān)心數(shù)量、完全不關(guān)心版本的臨時服務(wù)。比如一個性能壓測集群壓力機不需要滾動升級壞了就按模板重建。這種場景創(chuàng)建一個裸RS副本數(shù)寫10完全不關(guān)心鏡像變不變化因為它本來就不需要發(fā)布變更。三是作為CRD的底層實現(xiàn)。有些自定義資源在API層對外暴露的是CRD控制器把用戶請求轉(zhuǎn)換成ReplicaSet的創(chuàng)建與伸縮邏輯。這時候ReplicaSet就像一張低調(diào)但可靠的內(nèi)核幫自定義控制器完成最基礎(chǔ)的Pod運維。除了這幾類日常業(yè)務(wù)我還是那句話老老實實用Deployment省心。6.2 操作RS時必須養(yǎng)成的幾個職業(yè)習(xí)慣如果你確實要在測試環(huán)境或者特定場景操作ReplicaSet我建議養(yǎng)成下面幾個習(xí)慣都是我在群里看別人踩坑、自己也踩過坑之后總結(jié)出來的創(chuàng)建之前先檢查標簽沖突。用kubectl get pods -l 標簽掃一遍全局確認沒有別人在用同一組標簽。這一步花費不到10秒但能避免同室操戈級別的事故。刪除之前想清楚是否要級聯(lián)。默認刪除RS會級聯(lián)刪除Pod這是絕大多數(shù)時候想要的行為。如果你用了--cascadeorphan刪完RS一定要立刻處理遺留的Pod要么接管要么清除別讓孤兒Pod在集群里游蕩。改模板之前先確認舊Pod是否需要保留。記住前面那個實驗改RS的template不重建舊Pod這意味著你可能要手動刪Pod才能讓新配置生效。動手之前把這波操作對業(yè)務(wù)的影響評估清楚。把RS當作只讀對象來觀察。生產(chǎn)環(huán)境里我把kubectl get rs和kubectl describe rs當作日常巡檢標配但幾乎不會去寫RS的YAML?？磾?shù)量、看事件、看歷史revison這些就夠了。6.3 最后再分享一個我實測有效的排障技巧用Deployment發(fā)布業(yè)務(wù)時如果滾動更新卡住了別急著點回滾。先找到當前卡住的那個新RS看它的事件比如FailedCreate、ImagePullBackOff、Insufficient cpu大概率問題就鎖定了。如果你發(fā)現(xiàn)新RS本身沒有任何事件Pod狀態(tài)也正常但Deployment就是不往前推進那問題可能出在maxUnavailable和maxSurge的配置上——比如你設(shè)置了maxUnavailable為0而集群里又沒有足夠的資源創(chuàng)建臨時的新Pod滾動更新就會僵持。這時臨時把maxUnavailable調(diào)大一點比如從0改成1讓舊Pod先釋放一個位置出來更新就又能往前走了。我在幾套環(huán)境里用這個辦法救過好幾次發(fā)布事故。ReplicaSet這套機制說破天也就是維持副本數(shù)五個字但它背后牽出來的控制器模式、標簽選擇器、發(fā)布策略這些概念卻是理解整個Kubernetes工作負載體系的鑰匙。你把它的脾氣摸透了以后再看到Deployment滾動更新、StatefulSet有序擴縮容、DaemonSet節(jié)點級部署這些機制都會有一種殊途同歸的通透感。