最近有個朋友問我說他們公司的業(yè)務跑在幾十臺虛擬機上運維靠人工擴容靠加班。身邊的同行都在聊K8s老板也跟風問了一句“別人都在用我們是不是也該上”他被問住了于是跑來找我聊了整整一個下午。這個問題其實特別典型。K8sKubernetes從2015年正式發(fā)布到成為容器編排的事實標準速度之快在基礎設施領域幾乎沒有先例。但“大家都在用”不代表“你也要跟風用”更不代表“用了K8s就萬事大吉”。企業(yè)真正應該關心的不是K8s火不火而是它到底解決了哪些傳統(tǒng)部署方式解決不了的問題以及這些問題的嚴重程度是否已經(jīng)到達了你的痛點閾值。這篇文章我就把這幾年和K8s打交道的經(jīng)驗攤開來講把它的核心價值拆成幾個層次它解決什么底層矛盾、設計理念為什么能成、企業(yè)實際能獲得什么收益以及最容易被忽略的——什么時候不該用K8s。話不多說直接進入正題。1. K8s到底解決了什么問題先搞懂痛點在哪兒1.1 環(huán)境一致性從“在我機器上是好的”到“所有節(jié)點一個樣”在沒有容器之前開發(fā)和運維之間的矛盾從第一天就存在開發(fā)在筆記本上代碼跑得飛起運維部署到服務器上就是起不來。常見的解釋是“環(huán)境不一樣”——操作系統(tǒng)的版本不一樣依賴庫的版本不一樣配置文件的路徑不一樣甚至連系統(tǒng)時區(qū)都能導致問題。處理辦法也五花八門有人寫部署文檔幾十頁的文檔沒幾個人認真讀有人用配置管理工具統(tǒng)一環(huán)境但每來一個新版本的操作系統(tǒng)就要重新適配一輪。K8s解決這個問題的關鍵其實在容器層。容器把應用代碼連同它依賴的運行環(huán)境語言運行時、系統(tǒng)庫、配置文件一起打包成鏡像。鏡像一旦構(gòu)建完成從開發(fā)環(huán)境到測試環(huán)境再到生產(chǎn)環(huán)境跑的都是同一個東西。K8s作為容器的編排平臺負責把這套“同一個東西”穩(wěn)定地調(diào)度到集群里的任何一臺機器上。所以“環(huán)境不一致”這個老大難問題在K8s體系里是天然不存在的。舉一個更直白的例子傳統(tǒng)虛擬機的交付物是一個“配置好的機器”但機器上裝了什么、補丁打到什么版本、哪個服務被意外停掉了你很難完全掌控。容器的交付物是鏡像鏡像的內(nèi)容是只讀的、可校驗的。這就好比以前你送人一臺組裝電腦里面裝了什么全看裝機師傅的心情現(xiàn)在你打包的是整機鏡像拉到哪一臺服務器上都是同一個系統(tǒng)還能校驗它的哈希值。1.2 伸縮性難題高峰期來了你的系統(tǒng)能扛住嗎第二個痛點是伸縮性。傳統(tǒng)方式下業(yè)務流量上來了運維要做的事情是申請新的虛擬機、安裝運行環(huán)境、拉取代碼、修改配置、啟動服務、接入負載均衡。這一套流程手工走下來運氣好要半小時運氣不好要半天。等機器終于加好了流量高峰可能已經(jīng)過去了。K8s的做法是把“部署一組副本”變成一個聲明式的操作——你告訴集群“我有這個鏡像幫我跑3個副本”集群就會自動把任務分配到合適的主機上。流量漲了你可以手動把副本數(shù)改成6個也可以配置自動擴縮容讓系統(tǒng)根據(jù)CPU、內(nèi)存或者自定義的業(yè)務指標動態(tài)調(diào)整。我實測下來的經(jīng)驗是一個配置好自動擴縮容的應用遇到流量突增時從監(jiān)控指標觸發(fā)到新增的Pod真正開始接收流量通常在1到3分鐘以內(nèi)。這個速度是手工操作完全無法比的。而且K8s的擴縮容是基于Pod粒度而不是整機粒度幾個應用共享一臺服務器資源利用率也上去了。1.3 故障恢復凌晨兩點手機不響鈴嗎傳統(tǒng)的故障處理流程是報警響鈴、運維被叫醒、排查日志、定位問題、手動重啟或切換流量。整個過程依賴人的響應速度和經(jīng)驗而且夜間被人為叫醒的次數(shù)多了人的狀態(tài)和判斷力都會下降。K8s的自愈機制改變的是“故障響應”的底層邏輯——它把“檢查故障、決定重啟、執(zhí)行重啟”這套流程自動化、制度化。當應用進程異常退出時K8s會自動拉起重啟當整個節(jié)點宕機時節(jié)點上的工作負載會被自動調(diào)度到其他健康的節(jié)點當應用不響應健康檢查探針時K8s會先把流量摘掉然后重啟容器。這些動作不用人參與。很多剛接觸K8s的人低估了這個能力覺得“重啟一下而已有什么了不起”。但實際在企業(yè)環(huán)境里這個“重啟一下”對應的是全年無數(shù)個深夜電話和無數(shù)次手忙腳亂。K8s的核心價值之一就是把這些低水平但緊急的工作從人身上卸載掉讓人去做更有價值的事情。2. K8s的核心價值拆解聲明式、自愈與資源效率2.1 聲明式API告訴系統(tǒng)“要什么”而不是“怎么干”K8s的理念里有一個非常關鍵的轉(zhuǎn)變傳統(tǒng)的運維工具告訴你的是“做什么操作”比如啟動服務、停止服務、增加節(jié)點K8s告訴你的是“期望狀態(tài)”比如“請保持這個應用始終有3個副本在運行”。這種“聲明式”的設計有什么好處最大的好處是可審計、可回放、可防止漂移。你的部署配置是一份YAML文件存在代碼倉庫里任何對系統(tǒng)的變更都必須通過修改這份文件來完成。因為文件有版本歷史你能知道誰在什么時間改了什么東西出問題了還能快速回退。這比某個人半夜登錄服務器手動跑了一條命令靠譜得多。聲明式API背后是K8s的控制器模型Controller。以Deployment為例它的控制器會持續(xù)做一件看起來枯燥的事對比“當前副本數(shù)”和“期望副本數(shù)”如果發(fā)現(xiàn)不一致就創(chuàng)建或刪除Pod來對齊。這個過程叫“調(diào)和循環(huán)”聽起來很簡單但它是整個系統(tǒng)穩(wěn)定性的基石。我在這里提醒一句如果你上了K8s之后還是習慣直接ssh進容器里改配置那等于把K8s用成了虛擬機完全沒發(fā)揮出它該有的價值。正確的做法是什么都走聲明式文件讓Git成為唯一的事實來源這就是這兩年大家常說的GitOps。2.2 調(diào)度與資源利用率把服務器的每一分錢花明白傳統(tǒng)部署里有個非常常見的浪費場景為了保障核心業(yè)務的穩(wěn)定性一臺物理機或虛擬機只跑一個應用。結(jié)果是什么呢數(shù)據(jù)庫機器CPU常年5%Redis機器內(nèi)存用了30%應用服務器峰值也只有40%。整個機房的平均資源利用率能到15%就已經(jīng)謝天謝地了。K8s的調(diào)度器解決的是“裝箱”問題——把很多個容器合理地塞進有限的節(jié)點里讓資源得到充分利用。調(diào)度器會綜合考量每個Node的CPU、內(nèi)存剩余量、已經(jīng)運行的Pod情況、親和性規(guī)則幫每個新Pod找到最合適的位置。你只需要在部署配置里寫上每個容器請求多少資源requests、最多能用多少資源limits剩下的交給調(diào)度器。從成本角度看這是一個很直接的賬假設你有10臺物理機每臺用了15%的資源。理論上有3臺機器就可以承載同樣的業(yè)務另外7臺可以下線、可以給別的團隊用、可以節(jié)約電力和機房空間。雖然實際調(diào)度沒有這么完美還要考慮冗余、分片、數(shù)據(jù)局部性但資源利用率提升一倍以上是完全做得到的。2.3 服務發(fā)現(xiàn)與流量治理長得像微服務的功能現(xiàn)在原生就有在傳統(tǒng)架構(gòu)里服務要互相調(diào)用運維要維護一份IP清單或者接入一個注冊中心。每當有服務擴容或遷移IP變了要么人工改配置要么靠各種注冊中心搞定。K8s內(nèi)置了Service、DNS、負載均衡機制服務之間只需要通過固定的內(nèi)部域名互訪集群自動把請求轉(zhuǎn)發(fā)到存活的Pod上。流量治理相關的功能也下沉到了平臺層滾動更新時新的Pod一個一個起來老的Pod一個一個下線流量的切換平滑得用戶幾乎無感知一旦新版本發(fā)布后負載異常一條命令回滾到上一個版本幾十秒鐘完成。這些能力如果全要自研別說小團隊很多中大型團隊都得投入好幾個人力專門維護。3. 企業(yè)為什么紛紛轉(zhuǎn)向K8s從成本、速度與標準化算賬3.1 基礎設施成本賬利用率、多云與避免鎖定企業(yè)上K8s的感受最直觀的是成本結(jié)構(gòu)的變化。前面提到的資源裝箱能力能直接減少服務器的采購量。上云的企業(yè)感受更明顯業(yè)務流量有明顯的波峰波谷——工作日的白天高夜間低促銷節(jié)點高日常低。沒有彈性伸縮機制時云服務器的賬單是按峰值需求計費的意味著你為了撐住一個月里那幾天的流量為整個月付了額外的費用。K8s的動態(tài)擴縮容配合云的按量付費理論上可以做到“用多少付多少”。比如一個應用平時5個副本促銷來了自動擴到20個促銷結(jié)束后自動縮回5個。這個場景下的賬單對比一年省下來的錢足夠覆蓋團隊學習和維護K8s的投入了。還有多云和避免廠商鎖定的考量。K8s的API是標準化的雖然每家云廠商的托管K8s服務在一些細節(jié)上有差異但基本的Deployment、Service、Ingress、ConfigMap這些對象是跨平臺一致的。這意味著你的架構(gòu)可以在不同云之間遷移也可以做到混合云部署。對于已經(jīng)把“不用把身家性命押在一朵云上”當成原則的企業(yè)來說這是很強的吸引力。3.2 研發(fā)效率賬從“等運維排期”到“自助發(fā)布”傳統(tǒng)模式下研發(fā)要發(fā)一個版本流程通常是提工單、等運維審批、運維執(zhí)行發(fā)布、出問題再回滾。這個流程短則半天長則一天甚至更久。如果每天要發(fā)布多個版本運維團隊的人力馬上就成為瓶頸。K8s配合CI/CD流水線之后發(fā)布這件事變成了“開發(fā)者自己按一下按鈕”或者“代碼合并后自動觸發(fā)”。鏡像構(gòu)建、推送到鏡像倉庫、更新K8s工作負載這一整條鏈路是自動化的。低風險的發(fā)布可以做到一天好幾次而且因為滾動更新和快速回滾機制發(fā)布失敗的代價也大大降低。對于追求快速迭代的互聯(lián)網(wǎng)業(yè)務來說這種“發(fā)布自由”帶來的價值很難用金錢去衡量。3.3 環(huán)境標準化開發(fā)、測試、預發(fā)、生產(chǎn)“長得一模一樣”很多企業(yè)的環(huán)境多到數(shù)不清有人有本地開發(fā)環(huán)境還有開發(fā)環(huán)境、聯(lián)調(diào)環(huán)境、測試環(huán)境、預發(fā)布環(huán)境、生產(chǎn)環(huán)境。傳統(tǒng)方式下這些環(huán)境的配置靠人工維護環(huán)境之間配置漂移是常態(tài)——生產(chǎn)環(huán)境有個特殊配置預發(fā)環(huán)境沒有結(jié)果每次預發(fā)測完都好好的一上生產(chǎn)就出問題。K8s的價值在于一套部署文件可以在多個環(huán)境間復用只需要切換不同的配置項比如環(huán)境的域名、數(shù)據(jù)庫地址、密鑰。環(huán)境的差異被顯式地管理在配置中心或ConfigMap/Secret里而不是散落在某臺服務器的某個角落。開發(fā)如果要在本地起一套和新環(huán)境一致的K8s集群借助工具比如minikube這類也能很接近地模擬出來。環(huán)境一致性帶來的“測完就能上”的確定性是很多團隊從K8s獲得的最大改善。4. 別盲目跟風什么時候該上K8s什么時候該說“不”4.1 適合上K8s的典型場景結(jié)合我自己見過的大量案例有以下特征的業(yè)務場景是比較適合上K8s的微服務化程度高服務數(shù)量上來了光靠手工維護各個服務的部署和通信已經(jīng)力不從心。流量有明顯的峰谷波動或者存在大促、活動日這類流量突增場景需要快速擴縮容。發(fā)布頻率高每周甚至每天都要發(fā)多個版本需要對發(fā)布效率和回滾速度有強要求。團隊里有專人或者有決心培養(yǎng)專人負責基礎設施愿意接受長期維護集群的成本。業(yè)務邏輯需要多環(huán)境一致地運行客戶現(xiàn)場部署或多云部署的需求比較強烈。如果你所在的團隊同時命中上述多條那K8s大概率是值得投入的方向。4.2 不適合或暫時不需要上K8s的場景有些場景強行上K8s反而是災難。我把這些典型情況列出來你對照一下只有一個單體應用幾臺服務器就能搞定沒有明顯的擴容壓力——上了K8s只是徒增復雜度。團隊沒有容器化基礎Docker都不熟悉就想一步到位——基礎設施的新概念一股腦砸過來開發(fā)運維都會很痛苦。沒有專門的運維或基礎設施角色全靠研發(fā)兼職——K8s的維護成本絕對被低估了尤其是控制平面的升級、etcd備份、網(wǎng)絡方案調(diào)優(yōu)這些事。業(yè)務規(guī)模小到一臺高性能服務器就能扛住全部負載——這時候談資源利用率沒有意義因為再高也就省一臺機器的錢。應用是無狀態(tài)還好如果大量有狀態(tài)應用數(shù)據(jù)庫、中間件在K8s上運行它們需要額外付出很多學習成本。我親眼見過一個團隊業(yè)務只有幾個內(nèi)部使用的管理系統(tǒng)總共幾百個用戶強行追趕時髦上了一套K8s。結(jié)果幾個月過去版本沒升級過證書過期了沒人管節(jié)點被一次日志占滿導致集群故障最后項目無疾而終。這個例子我每次講都覺得很可惜——不僅是資源浪費更重要的是讓團隊成員對K8s留下了“這玩意兒很麻煩”的負面印象。4.3 一個可量化的判斷方式你不妨算一筆賬把你過去一年因為“手工部署”“環(huán)境問題”“擴容不及時”“發(fā)布故障”帶來的直接工時損失和環(huán)境成本加起來再預估一個K8s落地需要投入的成本人力學習、遷移、維護如果前者明顯大于后者上K8s就是劃算的。這個公式很粗糙但比“大家都在用”靠譜一百倍。5. 落地K8s的五個真實坑來自一線的避坑清單5.1 網(wǎng)絡方案選型必須先想清楚K8s集群的網(wǎng)絡方案是整個平臺最容易出問題、也最影響使用體驗的一環(huán)。常見的方案有Flannel、Calico等。它們的區(qū)別主要是數(shù)據(jù)平面的性能、是否支持網(wǎng)絡策略以及功能的豐富程度。Flannel部署簡單適合剛學習的時候用。但如果你在跑生產(chǎn)集群我建議認真考慮Calico這類支持網(wǎng)絡策略的方案。生產(chǎn)環(huán)境里的安全隔離很重要比如不同團隊之間默認不允許互相訪問或者某個應用只允許被特定調(diào)用方訪問這些要在網(wǎng)絡層做不能在業(yè)務代碼里做。我踩過的坑是最開始圖省事選了最簡單的網(wǎng)絡方案后續(xù)業(yè)務要求網(wǎng)絡策略時發(fā)現(xiàn)底層方案不支持只好推倒重來遷移集群。這種遷移對運行中的業(yè)務是有損的代價遠比當初多花一天選型高得多。所以網(wǎng)絡方案建議在一開始就按生產(chǎn)標準來規(guī)劃。5.2 有狀態(tài)應用別照搬無狀態(tài)的經(jīng)驗數(shù)據(jù)庫要不要跑在K8s里是社區(qū)里爭論了幾年的話題。我的觀點是沒有足夠的K8s經(jīng)驗之前先不要動核心數(shù)據(jù)庫。K8s對有狀態(tài)應用的支持雖然在逐年完善但它的復雜度和運維難度依然明顯高于無狀態(tài)應用。如果你一定要在有狀態(tài)應用上使用K8s請接受一個前提你必須嚴格遵守K8s的存儲抽象PersistentVolume/PersistentVolumeClaim來做數(shù)據(jù)持久化并且做好備份。親手把數(shù)據(jù)搞丟過一次之后你就能體會什么叫“敬畏心”。5.3 版本升級是有節(jié)奏的不是想升就升K8s的版本升級有一個原則跨版本升級需謹慎。每個大版本之間可能有API對象的增刪、字段的變更、行為的變化跨多個大版本直接升級容易踩到兼容性的坑。我見過有人從1.20直接升到1.28結(jié)果一堆資源對象的API版本變了折騰了好幾個通宵。更合理的節(jié)奏是跟蹤整個社區(qū)的版本發(fā)布節(jié)奏至少一個季度維護一次保持集群在一個相對穩(wěn)定的版本區(qū)間內(nèi)。避免用太老的版本因為有些安全漏洞和功能缺陷只在新版本修復也別用太新的版本因為新版本剛發(fā)布時可能會有一些潛在問題。還有一條容易被忽略的etcd的備份比什么都重要。集群出事時etcd經(jīng)常是唯一的救命稻草——請定時做自動化備份否則到時就晚了。5.4 資源配額和LimitRange不設限制的系統(tǒng)遲早會出事很多團隊剛上K8s時開發(fā)人員圖省事部署文件里不寫requests和limits?？雌饋眄樌\行了其實是把風險留給了整個集群——某個應用內(nèi)存暴漲時會拖垮同一節(jié)點上的所有其他應用。正確做法是在集群側(cè)建立資源配額機制ResourceQuota和LimitRange讓namespace下的每個工作負載都必須聲明資源請求和限制。從規(guī)范上約定下來從制度上避免濫用的可能性。在配置方面我建議先為Container設置合理的requests和limits再以Paas或模板的方式固化下來防止新成員不按規(guī)則來。5.5 不要忘了監(jiān)控、日志和告警最后這一個坑我?guī)缀趺看慰吹叫聢F隊踩都會心疼一下應用業(yè)務是遷移上了K8s但監(jiān)控體系和日志系統(tǒng)沒有跟著升級。當Pod漂移、新節(jié)點加入、舊節(jié)點下線時傳統(tǒng)基于虛擬機的監(jiān)控體系已經(jīng)失效了而團隊還渾然不覺直到線上出了故障才發(fā)現(xiàn)什么數(shù)據(jù)都看不到排查無從下手。K8s上比較好的實踐是進程級監(jiān)控和資源監(jiān)控用Prometheus生態(tài)體系日志采集用Filebeat或Fluentd這類工具把容器日志統(tǒng)一收集到集中存儲調(diào)用鏈追蹤根據(jù)公司的技術棧選擇合適的工具。監(jiān)控預警體系建議在遷移過程中就要同步建設不要等出了事故再補救。6. 寫在最后我個人的一點實際體會和K8s打交道的這幾年我最大的感受是K8s的本質(zhì)不是簡化了某個具體的部署操作而是把運維工作從“操作一個系統(tǒng)”提升到了“聲明一種期望狀態(tài)”的層級。很多剛上手時的繁瑣學習YAML、理解控制器、研究網(wǎng)絡插件其實是把前幾年手工運維欠下的技術債一次性補齊。如果你正在評估是否要上K8s別急著問“怎么部署”先想想“我現(xiàn)在的痛點是什么”。如果痛點是環(huán)境不一致、擴容慢、發(fā)布難回滾、機器利用率低那K8s確實是你需要的答案如果痛點不明顯那就先把容器化做好把Docker用好也完全沒問題。另外分享一個實用技巧即使決定上K8s也不要一下子把全部業(yè)務塞進去。挑一個非核心的、適合做實驗的服務先跑起來讓團隊把整個鏈路跑通、把坑踩一遍再逐步擴大范圍。這種漸進式的遷移在成功率和團隊接受度上遠遠好于一次性全量遷移。記住K8s是給業(yè)務提效的工具不是拿來向同行炫耀的裝飾品。