Docker 和 K8s 的關(guān)系每隔一段時(shí)間就會(huì)有人拿出來(lái)問(wèn)一次既然 Docker 已經(jīng)把應(yīng)用打包成鏡像一條命令就能啟動(dòng)為什么還要搞出 Kubernetes 這么重的東西我先給出一個(gè)直接判斷Docker 解決的是“單臺(tái)機(jī)器上如何把應(yīng)用跑起來(lái)”的問(wèn)題K8s 解決的是“很多臺(tái)機(jī)器上如何保證這些應(yīng)用不掛、可調(diào)度、能擴(kuò)容、好管理”的問(wèn)題。短期單機(jī)開(kāi)發(fā)Docker 足夠生產(chǎn)環(huán)境、多實(shí)例、微服務(wù)、流量波動(dòng)、節(jié)點(diǎn)故障只有 Docker 往往會(huì)失控。這篇就圍繞“為什么還要 K8s”拆開(kāi)講包括兩者到底差在哪、K8s 多做了什么、什么時(shí)候才需要上、以及從 Docker 平滑過(guò)渡到 K8s 的實(shí)際路徑。很多人學(xué)容器技術(shù)時(shí)最先接觸的都是 Docker鏡像、容器、端口映射、數(shù)據(jù)卷、docker-compose。這套東西確實(shí)好用開(kāi)發(fā)環(huán)境一條命令拉起來(lái)打包鏡像發(fā)給別人也能復(fù)現(xiàn)。但一旦應(yīng)用規(guī)模變大比如你手上有 10 個(gè)服務(wù)部署在 3 臺(tái)機(jī)器上問(wèn)題很快就來(lái)了流量高了想把某個(gè)服務(wù)多開(kāi)幾個(gè)誰(shuí)來(lái)調(diào)度某個(gè)節(jié)點(diǎn)宕機(jī)了上面的容器怎么遷移新加一臺(tái)機(jī)器怎么讓服務(wù)自動(dòng)用上新資源這些都不是 Docker 本身能直接回答的。K8s 就是在這個(gè)層面把事情接過(guò)去的。下面按實(shí)際理解路徑拆開(kāi)講先解決兩者關(guān)系再看 K8s 做了什么然后討論什么場(chǎng)景必須上 K8s最后聊怎么從 Docker 平滑過(guò)渡。1. 先用一句話理清 Docker 和 K8s 的分工1.1 Docker 是單機(jī)容器引擎K8s 是集群編排系統(tǒng)Docker 的核心能力圍繞“單個(gè)容器”展開(kāi)拉鏡像、建容器、啟停、刪除、端口映射、數(shù)據(jù)卷掛載。你可以在一個(gè)節(jié)點(diǎn)上同時(shí)跑多個(gè)容器但所有容器都共享這臺(tái)機(jī)器的 CPU、內(nèi)存、磁盤(pán)和網(wǎng)絡(luò)沒(méi)有跨節(jié)點(diǎn)的調(diào)度概念。K8s 的核心能力圍繞“一批容器”展開(kāi)它管理的是一個(gè)集群由多個(gè) Node節(jié)點(diǎn)組成Kubernetes 決定每個(gè) Pod 放在哪個(gè)節(jié)點(diǎn)、資源夠不夠、要不要重啟、要不要擴(kuò)容。K8s 不直接操作容器而是通過(guò)容器運(yùn)行時(shí)常見(jiàn)的就是 containerd以前很多環(huán)境用 Docker來(lái)拉起容器。換句話說(shuō)Docker 是 K8s 集群中單個(gè)節(jié)點(diǎn)上可能用到的容器運(yùn)行層K8s 是更高一層的控制系統(tǒng)。這個(gè)關(guān)系經(jīng)常被誤解成“K8s 是 Docker 的升級(jí)版”不準(zhǔn)確。更貼切的比喻是Docker 像你手里的集裝箱單個(gè)箱子怎么裝、怎么搬它管得不錯(cuò)K8s 像整個(gè)港口的調(diào)度系統(tǒng)哪個(gè)箱子放哪個(gè)泊位、哪艘船先裝卸、什么時(shí)候調(diào)幾臺(tái)吊車(chē)過(guò)來(lái)Docker 管不了。1.2 為什么“有了 Docker”還會(huì)覺(jué)得不夠單機(jī)場(chǎng)景下Docker docker-compose 已經(jīng)能解決很多問(wèn)題比如 LNMP 環(huán)境一鍵拉起、MySQL 和 Redis 主從測(cè)試、開(kāi)發(fā)環(huán)境隔離。但生產(chǎn)環(huán)境面對(duì)的問(wèn)題不一樣故障恢復(fù)一個(gè)容器進(jìn)程掛了Docker 單機(jī)重啟策略有限節(jié)點(diǎn)宕機(jī)之后容器不會(huì)自動(dòng)跑到另一臺(tái)機(jī)器上。流量調(diào)度業(yè)務(wù)漲了需要從 1 個(gè)實(shí)例擴(kuò)到 10 個(gè)實(shí)例Docker 沒(méi)有自動(dòng)伸縮、負(fù)載均衡和統(tǒng)一入口。服務(wù)發(fā)現(xiàn)A 服務(wù)要調(diào)用 B 服務(wù)B 有多份實(shí)例Docker 默認(rèn)不會(huì)自動(dòng)維護(hù)一個(gè)可用的服務(wù)地址列表。升級(jí)發(fā)布滾動(dòng)更新、回滾、金絲雀發(fā)布Docker 本身沒(méi)有這套流程。配置和密鑰管理多套環(huán)境、多個(gè)配置項(xiàng)Docker 不是不能做但集群規(guī)模一大就非常零散。這些痛點(diǎn)疊加起來(lái)才是“為什么還要 K8s”的真正答案。2. K8s 到底多做了什么單機(jī) Docker 做不到的事2.1 調(diào)度把 Pod 放到合適的節(jié)點(diǎn)上K8s 里最小的調(diào)度單位不是容器而是 Pod。一個(gè) Pod 可以包含一個(gè)或多個(gè)容器這些容器共享網(wǎng)絡(luò)和存儲(chǔ)。調(diào)度器會(huì)綜合考慮每個(gè)節(jié)點(diǎn)的資源、標(biāo)簽、污點(diǎn)和親和性決定 Pod 最終落到哪臺(tái)機(jī)器。這個(gè)能力在單機(jī) Docker 里完全不存在。你在 Docker 里跑一個(gè)容器它就在當(dāng)前這臺(tái)機(jī)器上要跑在別的機(jī)器你得手動(dòng)登錄那臺(tái)機(jī)器再 docker run。K8s 則是你告訴它“我要 3 個(gè)副本每個(gè)副本需要 1 核 2G”調(diào)度器自己去選節(jié)點(diǎn)。機(jī)器有多臺(tái)、資源不均衡、部分節(jié)點(diǎn)有特殊硬件時(shí)這個(gè)差異會(huì)非常明顯。2.2 自愈不用半夜爬起來(lái)重啟服務(wù)K8s 的 Deployment 和 ReplicaSet 會(huì)持續(xù)對(duì)比“期望副本數(shù)”和“實(shí)際副本數(shù)”。某個(gè) Pod 掛了控制器立刻創(chuàng)建新 Pod 頂上節(jié)點(diǎn)宕機(jī)默認(rèn)情況下過(guò)一段時(shí)間后會(huì)將該節(jié)點(diǎn)上的 Pod 在其他節(jié)點(diǎn)重建容器存活但業(yè)務(wù)異常ReadinessProbe 和 LivenessProbe 會(huì)配合探針做更精細(xì)的處理。Docker 單機(jī)也有 restart 策略比如 always、on-failure但那只是解決“這臺(tái)機(jī)器上容器退出了要不要拉起來(lái)”的問(wèn)題。節(jié)點(diǎn)斷電、磁盤(pán)故障、整機(jī)網(wǎng)絡(luò)隔離Docker 的 restart 無(wú)能為力。K8s 的自愈能力是集群級(jí)別的。2.3 服務(wù)發(fā)現(xiàn)與統(tǒng)一入口集群內(nèi)服務(wù)之間的調(diào)用K8s 通過(guò) Service、DNS 和 Endpoints 來(lái)做。每個(gè) Service 有固定的虛擬 IP 和 DNS 名稱(chēng)Pod 變化、IP 變化都不會(huì)影響服務(wù)間的調(diào)用關(guān)系。對(duì)外流量再多加一層 Ingress比如 Nginx Ingress Controller 或 Traefik按域名和路徑路由到不同 Service。Docker 場(chǎng)景下服務(wù)間調(diào)用通常靠手動(dòng)維護(hù) IP 或者自定義配置docker-compose 里用服務(wù)名也能互相訪問(wèn)但那只局限于一個(gè) compose 項(xiàng)目?jī)?nèi)部。跨機(jī)、跨網(wǎng)絡(luò)、跨環(huán)境Docker 的方式會(huì)變得很辛苦而 K8s 把“服務(wù)發(fā)現(xiàn)”做成了平臺(tái)能力。2.4 彈性伸縮從 1 個(gè)副本到 20 個(gè)副本K8s 的 HPAHorizontalPodAutoscaler可以根據(jù) CPU、內(nèi)存或自定義指標(biāo)自動(dòng)調(diào)整副本數(shù)。這個(gè)能力在流量波動(dòng)明顯的業(yè)務(wù)里非常實(shí)用。Docker 要擴(kuò)容就必須手動(dòng)執(zhí)行 docker run或者自己寫(xiě)腳本、接 CI/CD 和外部調(diào)度平臺(tái)本質(zhì)還是沒(méi)有內(nèi)生的“按指標(biāo)自動(dòng)擴(kuò)容”機(jī)制。需要注意的是HPA 不是銀彈。指標(biāo)采集和延遲、應(yīng)用啟動(dòng)時(shí)間、Pod 快速擴(kuò)容時(shí)的資源競(jìng)爭(zhēng)都會(huì)影響實(shí)際效果。但 K8s 至少把這道自動(dòng)化能力直接開(kāi)放出來(lái)了。2.5 聲明式管理把系統(tǒng)狀態(tài)變成數(shù)據(jù)這是 K8s 和 Docker 使用模式上最本質(zhì)的區(qū)別。Docker 是命令式的你執(zhí)行 docker run、docker stop、docker rm每一步都是你主動(dòng)操作。K8s 是聲明式的你編寫(xiě) YAML聲明“我要什么狀態(tài)”剩下的由控制器不斷調(diào)解讓集群狀態(tài)逼近你的聲明。這個(gè)差異帶來(lái)的好處是配置可以版本化變更可以走 Git 工作流出問(wèn)題可以快速回滾到上一版 YAML。團(tuán)隊(duì)協(xié)作時(shí)K8s 的對(duì)象描述比一堆 shell 歷史記錄可靠得多。3. 什么時(shí)候才真正需要 K8s什么時(shí)候沒(méi)必要3.1 沒(méi)必要上 K8s 的典型場(chǎng)景不是所有項(xiàng)目都要上 K8s。以下場(chǎng)景用 Docker docker-compose 反而更輕個(gè)人學(xué)習(xí)和小型實(shí)驗(yàn)單機(jī)跑一個(gè) LNMP 環(huán)境、裝 MySQL、Redis 做測(cè)試docker-compose 足夠。公司內(nèi)部一次性工具比如臨時(shí)起一個(gè)數(shù)據(jù)庫(kù)、跑一次數(shù)據(jù)遷移任務(wù)不需要長(zhǎng)期穩(wěn)定集群。節(jié)點(diǎn)數(shù)量很少、沒(méi)有橫向擴(kuò)容需求兩三臺(tái)機(jī)器服務(wù)總量固定手動(dòng)維護(hù)成本可以接受。團(tuán)隊(duì)沒(méi)有容器編排經(jīng)驗(yàn)強(qiáng)行上 K8s控制面組件、網(wǎng)絡(luò)插件、存儲(chǔ)插件、升級(jí)流程每一個(gè)都可能成為新的故障源。在這些場(chǎng)景里K8s 帶來(lái)的復(fù)雜度遠(yuǎn)大于收益。這也是我一直強(qiáng)調(diào)“低配置能跑不代表適合能跑通也不代表當(dāng)前就該上”的原因。3.2 值得上 K8s 的典型信號(hào)以下情況碰到兩三條就可以認(rèn)真評(píng)估 K8s服務(wù)數(shù)量超過(guò) 10 個(gè)手動(dòng)維護(hù)部署腳本越來(lái)越亂。需要多副本部署某幾個(gè)核心服務(wù)且副本數(shù)經(jīng)常變化。節(jié)點(diǎn)數(shù)量超過(guò) 3 臺(tái)需要統(tǒng)一管理資源。發(fā)布頻率高需要滾動(dòng)更新、回滾和金絲雀發(fā)布。業(yè)務(wù)對(duì)故障恢復(fù)要求高不能接受節(jié)點(diǎn)宕機(jī)后長(zhǎng)時(shí)間不可用。需要按環(huán)境隔離配置、密鑰又不希望散落在各個(gè)服務(wù)器上。多個(gè)服務(wù)間調(diào)用頻繁需要穩(wěn)定的服務(wù)發(fā)現(xiàn)和 DNS 機(jī)制。有一個(gè)常見(jiàn)誤區(qū)認(rèn)為“上了 K8s 就一定比 Docker 穩(wěn)定”。其實(shí) K8s 只是把很多原來(lái)運(yùn)維手工做的事情自動(dòng)化了但 K8s 本身也有升級(jí)、網(wǎng)絡(luò)、存儲(chǔ)、證書(shū)過(guò)期等問(wèn)題。如果你的應(yīng)用架構(gòu)和團(tuán)隊(duì)能力沒(méi)有準(zhǔn)備好K8s 會(huì)把原本顯性的單機(jī)故障變成隱性的集群調(diào)度故障。4. 從 Docker 到 K8s 的平滑過(guò)渡路線4.1 先做好容器化再談編排不管最終是否上 K8s第一步都是把應(yīng)用正確容器化。Docker 階段要關(guān)注的不是“鏡像能不能 build 出來(lái)”而是鏡像是否足夠小基礎(chǔ)鏡像是否包含大量無(wú)關(guān)依賴(lài)。容器是否有非 root 用戶(hù)運(yùn)行是否適合安全掃描。日志是否輸出到 stdout而不是寫(xiě)在容器內(nèi)某個(gè)文件。配置文件是否通過(guò)環(huán)境變量或掛載注入而不是打進(jìn)鏡像。有狀態(tài)數(shù)據(jù)是否落在命名卷或外部存儲(chǔ)而不是寫(xiě)在容器可寫(xiě)層。容器化不規(guī)范后面上 K8s 會(huì)把這些問(wèn)題放大幾十倍。比如日志不輸出到 stdoutK8s 里你就看不到有效排障信息有狀態(tài)數(shù)據(jù)寫(xiě)在容器可寫(xiě)層Pod 一重建數(shù)據(jù)就丟了。4.2 用 docker-compose 模擬多服務(wù)部署在單機(jī)上先跑通多服務(wù)的編排是很好的過(guò)渡練習(xí)。把應(yīng)用拆成 web、api、db、cache 等幾個(gè)服務(wù)用 docker-compose 管理網(wǎng)絡(luò)、依賴(lài)順序和數(shù)據(jù)卷。這個(gè)階段你會(huì)自然理解“服務(wù)之間如何通過(guò)服務(wù)名通信”“外部如何訪問(wèn)內(nèi)部服務(wù)”“數(shù)據(jù)應(yīng)該如何持久化”。等這些概念都清楚了再遷移到 K8s很多 YAML 里的字段就不會(huì)顯得那么抽象。比如 compose 里的 service 對(duì)應(yīng) K8s 里的 Servicecompose 里的 restart 對(duì)應(yīng) K8s 里的 restartPolicy 和控制器自動(dòng)重啟邏輯compose 里的 volumes 對(duì)應(yīng) K8s 里的 PersistentVolumeClaim。4.3 從最小的 K8s 集群開(kāi)始不要一上來(lái)就生產(chǎn)學(xué)習(xí)階段推薦先用輕量方案搭一個(gè)單節(jié)點(diǎn)或三節(jié)點(diǎn)集群。常見(jiàn)的選擇包括 k3s、minikube、kind、kubeadm。沒(méi)有哪個(gè)是絕對(duì)最好的取決于你想學(xué)什么minikube適合在本地電腦快速體驗(yàn) K8s 的基礎(chǔ)對(duì)象啟動(dòng)快但和真實(shí)多節(jié)點(diǎn)集群有差距。kind適合用容器模擬節(jié)點(diǎn)做 CI、測(cè)試、本地實(shí)驗(yàn)很方便。k3s占用資源少適合低配機(jī)器或邊緣場(chǎng)景也能跑正式工作負(fù)載。kubeadm更接近生產(chǎn)環(huán)境安裝方式適合想了解 K8s 組件交互的讀者。我建議先在 minikube 或 kind 上把 Deployment、Service、Ingress、ConfigMap、Secret 這些對(duì)象跑一遍再考慮用 kubeadm 搭多節(jié)點(diǎn)集群。不要一上來(lái)就去網(wǎng)上找一條命令安裝生產(chǎn)集群的腳本裝完之后你不知道里面發(fā)生了什么出了問(wèn)題很難排查。4.4 把 LNMP 這類(lèi)經(jīng)典架構(gòu)從 Docker 搬到 K8s網(wǎng)絡(luò)上常見(jiàn)的 LNMP 實(shí)驗(yàn)即 Nginx PHP MySQL 的部署方式是一個(gè)很好的 K8s 練習(xí)項(xiàng)目。Docker 里你會(huì)寫(xiě)一個(gè) compose 文件定義 nginx、php-fpm、mysql 三個(gè)服務(wù)。K8s 里則需要拆成這套對(duì)象Deployment 或 StatefulSetMySQL 有狀態(tài)數(shù)據(jù)適合 StatefulSet至少需要 PersistentVolumeClaim。DeploymentNginx 和 PHP-FPM 分別作為無(wú)狀態(tài)服務(wù)Nginx 通過(guò) FastCGI 轉(zhuǎn)發(fā)給 PHP-FPM。Service每個(gè)服務(wù)暴露一個(gè)穩(wěn)定 DNS 地址。ConfigMapNginx 配置和 PHP 配置通過(guò) ConfigMap 掛載進(jìn)容器。SecretMySQL 密碼通過(guò) Secret 注入。這個(gè)實(shí)驗(yàn)做完你基本就理解了 K8s 的配置、存儲(chǔ)、網(wǎng)絡(luò)和服務(wù)發(fā)現(xiàn)核心概念也會(huì)發(fā)現(xiàn) K8s 里做 LNMP 比 Docker compose 多好幾倍的文件這正是“編排能力換復(fù)雜度”的實(shí)際感受。4.5 漸進(jìn)式遷移不要重寫(xiě)一切如果已經(jīng)有服務(wù)在 Docker 里跑得好好的完全沒(méi)必要一次性把所有服務(wù)都遷到 K8s。建議按優(yōu)先級(jí)逐步遷移優(yōu)先遷移無(wú)狀態(tài)服務(wù)比如 Web API、前端靜態(tài)資源、任務(wù)處理 Worker。數(shù)據(jù)庫(kù)、Redis、消息隊(duì)列這類(lèi)有狀態(tài)組件先評(píng)估是否有成熟的 Operator 或外部托管方案。保持一段時(shí)間混合模式部分服務(wù)在 K8s部分服務(wù)仍在原 Docker 環(huán)境通過(guò)網(wǎng)絡(luò)打通或統(tǒng)一入口轉(zhuǎn)發(fā)。把遷移過(guò)程中遇到的配置、存儲(chǔ)、日志、監(jiān)控問(wèn)題記錄下來(lái)形成自己的檢查清單。遷移過(guò)程中最容易被忽略的是日志和監(jiān)控。Docker 里你可以在節(jié)點(diǎn)上 docker logsK8s 換節(jié)點(diǎn)、滾動(dòng)更新后日志會(huì)散落在多個(gè)節(jié)點(diǎn)沒(méi)有集中收集很難排查。建議在上 K8s 前先搭建日志收集方案比如 Loki、Elasticsearch 或云廠商日志服務(wù)再把應(yīng)用日志輸出規(guī)范同步處理。5. K8s 學(xué)習(xí)中最容易踩的坑和排查思路5.1 網(wǎng)絡(luò)問(wèn)題大多和 CNI 插件有關(guān)K8s 集群中 Pod 之間、Pod 與 Service 之間通信依賴(lài) CNI 網(wǎng)絡(luò)插件常見(jiàn)的有 Calico、Flannel、Cilium、Weave。新手經(jīng)常遇到“Pod 起來(lái)了但互相 ping 不通”或“Service 地址訪問(wèn)超時(shí)”大多數(shù)不是應(yīng)用問(wèn)題而是網(wǎng)絡(luò)插件沒(méi)有調(diào)好。排查順序建議先看kubectl get pods -n kube-system確認(rèn)網(wǎng)絡(luò)插件 Pod 都是 Running?？垂?jié)點(diǎn)內(nèi)核模塊是否開(kāi)啟比如 Calico 依賴(lài)的 ipip、veth、nf_conntrack 等。檢查防火墻或安全組是否放行節(jié)點(diǎn)間通信端口。再看網(wǎng)絡(luò)策略是否誤攔截。不要一遇到 Pod 之間連不通就懷疑應(yīng)用代碼先確認(rèn)集群網(wǎng)絡(luò)數(shù)據(jù)面是正常的。5.2 資源不足導(dǎo)致的連環(huán)故障K8s 集群最隱蔽的問(wèn)題之一是對(duì)每個(gè)容器不設(shè)置 requests 和 limits。完全不設(shè)置Pod 可能把節(jié)點(diǎn)內(nèi)存打爆觸發(fā) OOM Killer系統(tǒng) Pod 也可能被擠出最后整個(gè)控制面都不穩(wěn)定。設(shè)置得太緊又會(huì)導(dǎo)致 Pod 不斷重啟、調(diào)度失敗。我的建議是每個(gè)工作負(fù)載至少設(shè)置 requestslimits 可以按業(yè)務(wù)需求決定但不要長(zhǎng)期不設(shè)置。requests 決定了調(diào)度器怎么判斷節(jié)點(diǎn)是否合適limits 決定了容器是否會(huì)被 cgroup 限制。發(fā)布到生產(chǎn)前先用壓測(cè)或歷史監(jiān)控?cái)?shù)據(jù)確定合理區(qū)間。5.3 Pod 一直 CrashLoopBackOff先看日志再改代碼CrashLoopBackOff 是新手最容易慌的報(bào)錯(cuò)。遇到時(shí)不要急著改代碼先按順序確認(rèn)kubectl describe pod pod-name看事件確認(rèn)是鏡像拉取失敗、還是探針失敗、還是容器退出。kubectl logs pod-name看應(yīng)用日志確認(rèn)啟動(dòng)時(shí)缺了哪個(gè)配置或依賴(lài)。確認(rèn) ConfigMap 和 Secret 是否掛載正確環(huán)境變量是否注入。確認(rèn)資源限制是否太小導(dǎo)致容器剛啟動(dòng)就被 OOM Kill。大多數(shù) CrashLoopBackOff 是配置和環(huán)境問(wèn)題真正的代碼問(wèn)題反而好定位。5.4 服務(wù)升級(jí)后不回滾依賴(lài)版本混亂團(tuán)隊(duì)剛上 K8s 時(shí)常見(jiàn)的壞習(xí)慣是直接改 YAML 或者用kubectl edit在線改對(duì)象。這樣改完雖然能生效但配置沒(méi)有入庫(kù)下次重裝集群、新成員接手都不知道當(dāng)前版本長(zhǎng)什么樣。更穩(wěn)妥的做法是所有 YAML 都放進(jìn) Git 倉(cāng)庫(kù)用 Git 記錄每次變更能用 Helm Chart 就用 Helm把版本號(hào)、鏡像 Tag、副本數(shù)這些變量抽出來(lái)發(fā)布走 CI/CD 流程而不是手動(dòng)執(zhí)行 kubectl apply。5.5 別把“能啟動(dòng)”當(dāng)成“可以上生產(chǎn)”K8s 里把服務(wù)跑起來(lái)不難難的是跑起來(lái)之后還能長(zhǎng)期穩(wěn)定。生產(chǎn)環(huán)境至少要額外考慮監(jiān)控指標(biāo)CPU、內(nèi)存、帶寬、Pod 重啟次數(shù)、錯(cuò)誤率。告警規(guī)則核心服務(wù)不可用、Pod 長(zhǎng)時(shí)間重啟、磁盤(pán)使用率過(guò)高。備份策略數(shù)據(jù)庫(kù)定時(shí)備份、對(duì)象存儲(chǔ)冗余、跨區(qū)域容災(zāi)。升級(jí)演練控制面組件升級(jí)、節(jié)點(diǎn)替換、網(wǎng)絡(luò)插件升級(jí)。安全基線鏡像掃描、密鑰掃描、RBAC 權(quán)限最小化。這些都不是 K8s 安裝完成后自動(dòng)有的需要團(tuán)隊(duì)規(guī)劃和持續(xù)迭代。6. 給不同學(xué)習(xí)階段讀者的實(shí)操建議6.1 剛學(xué)完 Docker準(zhǔn)備了解 K8s可以先在自己的電腦上用 Docker Desktop 或 minikube 起一個(gè)單節(jié)點(diǎn)集群然后跑這個(gè)練習(xí)清單創(chuàng)建 Deployment副本數(shù)為 3觀察 Pod 分布和滾動(dòng)更新。創(chuàng)建 Service用 ClusterIP 方式在集群內(nèi)訪問(wèn)再用 NodePort 從宿主機(jī)訪問(wèn)。創(chuàng)建 ConfigMap 和 Secret掛載到 Pod修改配置后滾動(dòng)更新。創(chuàng)建 Ingress給兩個(gè)不同服務(wù)設(shè)置兩個(gè)不同路徑。手動(dòng)刪除一個(gè) Pod觀察 ReplicaSet 是否自動(dòng)創(chuàng)建新 Pod。每個(gè)練習(xí)都用kubectl get和kubectl describe查看狀態(tài)變化。6.2 有一定 K8s 基礎(chǔ)想進(jìn)一步了解生產(chǎn)落地這時(shí)候重點(diǎn)要關(guān)注的是網(wǎng)絡(luò)插件的工作原理Calico 的 BGP 模式和 IPIP 模式有什么區(qū)別。存儲(chǔ)方案本地存儲(chǔ)、NFS、CSI 插件的區(qū)別和適用場(chǎng)景。有狀態(tài)應(yīng)用如何用 StatefulSet 和 Operator 管理。多集群、多環(huán)境的管理方式比如 Kustomize 和 Helm 怎么選。故障演練主動(dòng)模擬節(jié)點(diǎn)宕機(jī)、Pod 驅(qū)逐、網(wǎng)絡(luò)分區(qū)看看系統(tǒng)是否真的自愈。6.3 準(zhǔn)備面試可以關(guān)注這些高頻考點(diǎn)網(wǎng)上關(guān)于 K8s 的面試題很多核心考點(diǎn)通常集中在為什么有 Docker 還需要 K8s兩者的分工和邊界。K8s 控制面組件有哪些每個(gè)組件負(fù)責(zé)什么。Pod、Deployment、Service 的關(guān)系和區(qū)別。如何保證服務(wù)滾動(dòng)更新不中斷。節(jié)點(diǎn)資源不足時(shí)會(huì)發(fā)生什么驅(qū)逐策略是什么。如何排查 Pod 一直 Pending、ImagePullBackOff、CrashLoopBackOff。這些題看起來(lái)很散但背后都指向同一個(gè)能力你能否在故障發(fā)生時(shí)從現(xiàn)象倒推原因而不是只會(huì)背概念。7. 最后幾條真心話Docker 和 K8s 不是二選一的對(duì)立關(guān)系而是容器技術(shù)棧里的上下游配合。K8s 離不開(kāi)容器運(yùn)行時(shí)但容器運(yùn)行時(shí)不等于編排平臺(tái)。生產(chǎn)環(huán)境里K8s 也不一定是你唯一的選擇Docker Swarm、HashiCorp Nomad、云廠商的 Serverless 容器服務(wù)都可能在某些場(chǎng)景更合適。但就目前的主流趨勢(shì)、社區(qū)生態(tài)、資料完整度、人才儲(chǔ)備來(lái)看K8s 依然是容器編排方向最值得投入的學(xué)習(xí)對(duì)象。學(xué)習(xí)節(jié)奏上我更建議先把 Docker 的單機(jī)能力和 Compose 多服務(wù)編排練熟再進(jìn) K8s。不要跳步也不要反向“鄙視”Docker。很多 K8s 里的疑難問(wèn)題追根溯源還是容器鏡像不規(guī)范、依賴(lài)版本不明確、環(huán)境配置沒(méi)收斂。最重要的一點(diǎn)K8s 的能力不是裝好就自然擁有的也不是把 YAML 復(fù)制到生產(chǎn)環(huán)境就萬(wàn)事大吉。它把原本手工運(yùn)維的流程平臺(tái)化同時(shí)也把“責(zé)任”集中到了控制面上。你會(huì)發(fā)現(xiàn)很多服務(wù)沒(méi)有上 K8s 時(shí)問(wèn)題出在某臺(tái)機(jī)器上了 K8s 之后問(wèn)題變成“為什么會(huì)選中這個(gè)節(jié)點(diǎn)”“為什么這個(gè) Pod 被驅(qū)逐”“為什么升級(jí)后流量有抖動(dòng)”排查鏈路更長(zhǎng)、更抽象了。所以面對(duì)“有了 Docker為什么還要 K8s”這個(gè)問(wèn)題我會(huì)這樣回答如果你只有一臺(tái)機(jī)器、幾個(gè)服務(wù)、流量穩(wěn)定Docker 就夠如果你想解決多機(jī)器調(diào)度、故障自愈、自動(dòng)擴(kuò)縮容、統(tǒng)一發(fā)布流程K8s 是當(dāng)前最通用的一套答案。但答案本身不會(huì)替你消除復(fù)雜度它只是讓復(fù)雜度從“人肉處理”轉(zhuǎn)成“平臺(tái)處理”前提是你得先學(xué)會(huì)跟平臺(tái)對(duì)話。