1. 寫在前面為什么我推薦用“破壞式”學習 Kubernetes第五篇了我先把話說在前面這篇文章不是給你講 kubectl get pods 怎么用也不是抄一遍 Kubernetes 官方文檔。我想分享的是一套我自己驗證過、也一直在帶新人時用的學習方式——把集群“故意搞壞”再一步步修好。在這個破壞、觀察、修復、復盤的過程中Kubernetes 的組件邊界、調(diào)用鏈、故障表象都會變得異常清晰。我?guī)У倪\維新人經(jīng)常問我“Kubernetes 概念太多了Pod、Deployment、Service、Ingress、CRI、OCI、CNI、CSI……學完就忘怎么才能記住”我給的答案很簡單去把一個正在運行的 Pod 弄掛把一個節(jié)點標記成 NotReady把 CoreDNS 副本數(shù)縮到 0然后親手把它們修好。你踩過一次 ImagePullBackOff 的坑比背十遍 kubelet 工作原理都管用。這一篇是系列第五篇前四篇我們已經(jīng)把 Kubernetes 的架構(gòu)組成、集群部署、工作負載、網(wǎng)絡(luò)與存儲都過了一遍。這一篇我打算徹底換一個畫風先跟你把 kubelet 到 containerd 的實體調(diào)用鏈捋明白因為這是所有“運行時相關(guān)故障”的底層邏輯然后基于這條調(diào)用鏈把從 Pod 到集群的 20 類常見故障全部分類拆開講清楚再分享一套我自己的排錯方法、排查命令和破壞式實驗設(shè)計最后把這些實戰(zhàn)經(jīng)驗對應到 Kubernetes 面試高頻題上。內(nèi)容有點長但都是可以直接抄作業(yè)的。2. 先搞懂調(diào)用鏈kubelet 到底是怎么調(diào)用 containerd 的做故障排查之前我建議先把“一次 Pod 創(chuàng)建”背后的調(diào)用鏈刻在腦子里。因為集群里 80% 的運行時故障表象千奇百怪本質(zhì)都是這條鏈路上某個環(huán)節(jié)斷了。你只有知道了正常的時候數(shù)據(jù)是怎么流的才能在異常的時候快速定位斷點。2.1 從 kubelet 到 CRI一層抽象解決“運行時”之爭Kubernetes 早期版本是直接內(nèi)置支持 Docker 的kubelet 通過 Docker API 操作容器。后來容器運行時越來越多containerd、CRI-O、Kata Containers 紛紛登場Kubernetes 社區(qū)做了一個很重要的決定抽象出一層 CRIContainer Runtime Interface用一套統(tǒng)一的 gRPC 接口把 kubelet 和具體的容器運行時解耦。CRI 定義了兩類核心服務RuntimeService管理 Pod 沙箱Sandbox和容器生命周期比如 RunPodSandbox、CreateContainer、StartContainer、StopContainer。ImageService管理鏡像比如 PullImage、ListImages、RemoveImage。你可以把 CRI 理解成一個“電源插座”kubelet 只需要認準插座規(guī)格至于插座后面插的是 containerd 還是 CRI-O它不關(guān)心。而 containerd 為了接入 Kubernetes在它內(nèi)部實現(xiàn)了一個 CRI Plugin在 config.toml 里通常能看到它把 containerd 原生的 API 翻譯成了 CRI 語義。這一層翻譯是理解整套調(diào)用鏈的鑰匙。2.2 一次 Pod 創(chuàng)建到底發(fā)生了什么實體調(diào)用鏈我直接用文字把這條鏈路一步步畫出來你在看的時候可以想象自己在追一條請求你執(zhí)行 kubectl run 或者創(chuàng)建 Deployment請求先到 kube-apiserver經(jīng)過認證、授權(quán)、準入控制后寫入 etcd。kube-scheduler 通過 watch 機制發(fā)現(xiàn)這個新 Pod經(jīng)過調(diào)度算法選出一個最合適的節(jié)點并把調(diào)度結(jié)果寫回 API Server。目標節(jié)點上的 kubelet 通過 watch 拿到這個 Pod進入 syncPod 流程。kubelet 調(diào)用內(nèi)部的 Container Runtime Manager由它通過 CRI 客戶端向 containerd 的 CRI Plugin 發(fā)起 gRPC 請求。首個請求通常是 RunPodSandbox。containerd 的 CRI Plugin 會先去拉取 sandbox_image默認就是 pause 鏡像然后通過 containerd 的 Task Service 啟動一個 pause 容器作為整個 Pod 的網(wǎng)絡(luò)、IPC、UTS 等命名空間的“錨點”同時調(diào)用 CNI 插件完成 Pod 網(wǎng)絡(luò)配置。沙箱創(chuàng)建完成后kubelet 繼續(xù)發(fā)起 CreateContainer、StartContainer 請求containerd 開始真正創(chuàng)建業(yè)務容器。此時 containerd 會為這個容器拉起一個獨立的 containerd-shim 進程我這套環(huán)境里是 containerd-shim-runc-v2。shim 進程負責調(diào)用 runc create、runc start最終由 runc 通過 Linux 內(nèi)核的 namespace、cgroup、mount 等機制把容器真正跑起來。這里有兩個特別容易忽略的實體pause 容器。它是 Pod 里最先被創(chuàng)建、生命周期貫穿始終的“占位容器”。業(yè)務容器無論怎么重啟只要 pause 在Pod 的網(wǎng)絡(luò)標識和沙箱資源就不會變。這也是為什么你在節(jié)點上用 crictl ps 會看到每個 Pod 都對應一個 pause 容器。containerd-shim。它的存在是為了不讓 containerd 主進程直接當容器的父進程。這樣一來containerd 重啟、升級都不會殺掉正在運行的容器。每個 shim 對應一個容器它負責接管容器的標準輸入輸出、退出狀態(tài)上報并作為 runc 和 containerd 之間的中間人。2.3 順著 socket 摸下去在節(jié)點上“眼見為實”原理講再多不如自己在節(jié)點上敲幾條命令。Kubernetes 和 containerd 之間是 gRPC 通信socket 文件一般位于 /run/containerd/containerd.sock。kubelet 的啟動參數(shù)里一般有--container-runtime-endpointunix:///run/containerd/containerd.sock你可以先在節(jié)點上看一下這個 socket 是否真實存在ls -l /run/containerd/containerd.sock然后重點練熟 crictl 這一組命令它是我們排障時最順手的工具因為 crictl 走的正是 CRI 接口也就是說你手動用 crictl 操作的路徑和 kubelet 調(diào)用 containerd 的路徑是同一個非常有助于把調(diào)用鏈“實體化”crictl pods查看節(jié)點上的 Pod 沙箱列表。crictl ps -a查看所有容器包含已退出的注意區(qū)分 sandbox 容器和業(yè)務容器。crictl inspect 查看單個容器的詳細 spec、掛載、PID 等。crictl logs 直接拿容器日志不經(jīng)過 kubectl。crictl pull手動拉鏡像復現(xiàn) ImagePullBackOff 時好用。另外還有一套工具鏈是 ctr namespaces list它直接調(diào)用 containerd 原生 API和 crictl 的視角不同。兩者區(qū)別要搞清楚crictl 是 CRI 視角能看懂 Pod 和容器ctr 是 containerd 原生視角看不到 Pod 概念。排障時優(yōu)先用 crictl涉及 containerd 底層鏡像、快照、事件時再用 ctr 輔助。2.4 原理照進排錯調(diào)用鏈能幫你做什么為什么要花這么大力氣講調(diào)用鏈因為故障排查的本質(zhì)就是沿著這條鏈逐段做排除。舉個例子業(yè)務容器一直 CreateContainerErrorkubectl describe pod 里只顯示一句失敗的容器創(chuàng)建很多人就懵了。但如果你知道這條鏈是 kubelet → CRI → containerd → shim → runc你的排查思路立刻就有了第一段kubelet 是否正?？?journalctl -u kubelet。第二段CRI 接口是否通直接 crictl ps 看能不能連上 containerd socket。第三段containerd 是否正?？?journalctl -u containerd 和 containerd 的日志。第四段runc 啟動容器時內(nèi)核報了什么錯看 containerd 日志里帶 runc 字樣的 Error。順序排查永遠比盯著 kubelet 日志硬猜要快。后面我們講故障分類時你會發(fā)現(xiàn)所有故障最終都能落到這條鏈路的具體某一段上。3. 從 Pod 到集群20 類常見故障全解析接下來進入正題。我把平時線上和測試環(huán)境里遇過的高頻故障按“從 Pod 到集群”的維度整理成 20 類。先給一張速查表再挑幾類最容易讓人卡殼的展開講排查邏輯和修復手法。3.1 一張速查表先打底故障現(xiàn)象、根因、排查命令層級故障現(xiàn)象常見根因核心排查命令處理方向PodImagePullBackOff鏡像名錯誤、倉庫不存在、認證失敗kubectl describe pod修鏡像名、配 imagePullSecretPodErrImageNeverPullimagePullPolicyNever 但本地無鏡像kubectl describe pod換鏡像拉取策略或預置鏡像PodInvalidImageName鏡像名不合法kubectl describe pod修正鏡像格式PodCrashLoopBackOff啟動命令失敗、配置錯誤、依賴未就緒kubectl logs、kubectl describe pod修應用啟動邏輯PodOOMKilled容器內(nèi)存超 limitkubectl describe pod調(diào) resources.limitsPodPending資源不足、親和性/污點不滿足、PVC 未綁定kubectl describe pod擴容、調(diào)整調(diào)度約束PodCreateContainerError鏡像或運行時層錯誤crictl ps -a、journalctl -u kubelet看 containerd 日志PodCreateContainerConfigErrorConfigMap/Secret 不存在或字段缺失kubectl describe pod檢查引用資源PodRunContainerError運行時啟動容器失敗journalctl -u containerd看 runc 報錯PodDeadlineExceededPod 終止超時kubectl get pod -o yaml調(diào) terminationGracePeriod 或強刪PodInit:CrashLoopBackOffinitContainer 反復失敗kubectl logs pod -c init容器修初始化邏輯節(jié)點NotReadykubelet 心跳中斷、運行時異常kubectl describe node、journalctl -u kubelet逐段排查 kubelet節(jié)點DiskPressure節(jié)點磁盤到達驅(qū)逐閾值df -h、crictl rmi 清理鏡像清鏡像、清日志、加磁盤節(jié)點MemoryPressure節(jié)點內(nèi)存不足free -m驅(qū)逐 Pod、加節(jié)點節(jié)點PIDPressurePID 耗盡cat /proc/sys/kernel/pid_max、ps -eLf查進程泄漏網(wǎng)絡(luò)DNS 解析失敗CoreDNS 異常、上游 DNS 失效kubectl exec -it pod -- nslookup查 CoreDNS 狀態(tài)網(wǎng)絡(luò)Service 不通Endpoints 為空、kube-proxy 規(guī)則異常kubectl get endpoints、iptables-save查 selector網(wǎng)絡(luò)跨節(jié)點 Pod 不通CNI 配置異常、underlay 丟包ping、traceroute、查 CNI 日志查 CNI 插件網(wǎng)絡(luò)NodePort 訪問不通防火墻、安全組、端口占用ss -lntp檢查集群外鏈路存儲PV/PVC 掛載失敗StorageClass 不存在、權(quán)限不足kubectl describe pvc檢查存儲插件與權(quán)限3.2 Pod 生命周期類從 ImagePullBackOff 到 OOMKilled先講出現(xiàn)頻率最高的 ImagePullBackOff。它的表象是 Pod 卡在 ContainerCreatingEvents 里能看到 Failed to pull image。我從排查動作給你拆開第一步kubectl describe pod 看 Events 里的具體報錯。如果報 ErrImagePull多半是鏡像倉庫路徑寫錯、鏡像不存在、或者倉庫需要認證。注意有時候鏡像名寫對了但 tag 打錯了也會報同樣的錯誤。第二步手動在節(jié)點上用 crictl pull 拉一次相同鏡像。這一步能排除“kubelet 到鏡像倉庫的網(wǎng)絡(luò)問題”和“倉庫本身問題”。第三步如果是私有倉庫檢查 Pod 里是否配置了 imagePullSecrets。我踩過最隱蔽的坑是secret 存在但 service account 沒綁定kubelet 壓根沒把 secret 帶給 containerd。再看 CrashLoopBackOff。這個狀態(tài)說明容器起來了但啟動后立刻退出然后又重啟反復循環(huán)。很多人一看到這個狀態(tài)就慌了其實排查路徑非常固定kubectl logs 拿標準輸出和錯誤輸出看應用為什么退出。如果日志為空加 --previous 看上一次容器的日志。如果應用是 init 進程直接退出可能是 entrypoint 腳本問題如果涉及依賴服務數(shù)據(jù)庫、配置中心優(yōu)先看網(wǎng)絡(luò)和配置能否連通。我覺得 CrashLoopBackOff 最容易翻車的地方是進程“假啟動”。比如一個 Java 應用JVM 起來了但連不上配置中心又在代碼里設(shè)了啟動失敗即退出。這時候日志可能會在啟動后 30 秒才刷出來需要耐心看完整日志。然后是 OOMKilled。表象是容器狀態(tài)顯示 OOMKilled退出碼 137。根因往往是容器內(nèi)存超過 resources.limits被 cgroup OOM killer 殺掉。排查時kubectl describe pod 能看到最后狀態(tài)是 OOMKilled以及 reason 為 OOMKilled。用 free -m 看節(jié)點內(nèi)存再用 crictl stats 看各容器真實內(nèi)存占用。如果應用是 Java注意 JVM 默認堆大小可能和容器 limits 不匹配。我的經(jīng)驗是壓測環(huán)境下這類問題特別多JVM 還沒觸發(fā)自己的 OOM就先被 cgroup 殺了。3.3 節(jié)點與 kubeletNotReady、磁盤壓力、運行時失聯(lián)節(jié)點層故障牽扯面大因為一個節(jié)點掛掉上面所有 Pod 都要重建對業(yè)務的影響往往呈指數(shù)級放大。先看 kubectl get node 輸出里 STATUS 為 NotReady 的節(jié)點再用 kubectl describe node 查看 Conditions里面會寫明當前節(jié)點處于哪種壓力狀態(tài)。NotReady 最常見的三種原因我按概率排一下kubelet 與 API Server 的通信斷了?？赡苁蔷W(wǎng)絡(luò)問題、證書過期、或 kubelet 本身崩潰。排查命令是 journalctl -u kubelet -f一定要看實時日志因為很多報錯轉(zhuǎn)瞬即逝。節(jié)點負載過高導致 kubelet 的心跳上報超時。這時候 ssh 上節(jié)點top、free、df 三連看優(yōu)先確認資源水位。容器運行時掛了。也就是 containerd 進程異常kubelet 調(diào)用 CRI 接口超時被迫把節(jié)點標記為 NotReady。排查 containerd 狀態(tài)systemctl status containerd、journalctl -u containerd。DiskPressure、MemoryPressure、PIDPressure 這三類壓力本質(zhì)都是節(jié)點資源達到驅(qū)逐閾值kubelet 開始按照 QoS 等級驅(qū)逐 Pod。排查時DiskPressuredf -h 看根分區(qū)和容器數(shù)據(jù)目錄分區(qū)。很多時候是容器日志、鏡像、已停止容器殘留占滿磁盤。清理思路是先刪無用的鏡像crictl rmi再清理日志journalctl --vacuum-size最后看有沒有被誤寫進容器目錄的大文件。MemoryPressurefree -m 先看可用內(nèi)存用 ps 按內(nèi)存排序找進程。PIDPressure看 /proc/sys/kernel/pid_max 和當前 pid 數(shù)量。這種往往是有進程泄漏瘋狂創(chuàng)建線程或子進程。我遇到過一次 Java 應用線程池參數(shù)寫錯把機器 PID 直接打滿。另外一個很容易被忽略的是 kubelet 和 containerd 之間的狀態(tài)不一致。比如 containerd 重啟過但 kubelet 沒有感知crictl 能看到容器kubectl 里 Pod 一直異常。這種時候先重啟 kubelet 讓狀態(tài)重新對賬往往能自愈。3.4 網(wǎng)絡(luò)與服務DNS 解析失敗、Service 不通、跨節(jié)點連不上網(wǎng)絡(luò)類故障是排障里最燒腦的因為涉及物理網(wǎng)絡(luò)、CNI、kube-proxy、DNS、Service 多層疊加。我按“先從 Pod 內(nèi)部往外逐層測”的方法講。Pod 內(nèi) DNS 解析失敗先做一件事kubectl exec -it -- nslookup 然后根據(jù)報錯分兩種情況如果 getaddrinfo 直接報錯說明 Pod 里的 /etc/resolv.conf 有問題常見原因是 dnsPolicy 被改成 Default導致 Pod 沒有用集群的 CoreDNS。如果能解析到 IP 但訪問超時說明 CoreDNS 本身異常。查 CoreDNS Pod 狀態(tài)和日志看看是否有上游 DNS 配置錯誤。我踩過的一個坑是宿主機 /etc/resolv.conf 里的 nameserver 指向了內(nèi)網(wǎng) DNS但 CoreDNS 把它當上游解析外網(wǎng)域名時經(jīng)常超時。Service 訪問不通按這個順序查kubectl get endpoints 看 Endpoints 是否有 IP。如果沒有說明 Service 的 selector 和 Pod 的 label 不匹配這是最最常見的低級錯誤。如果 Endpoints 有 IP就在集群內(nèi)隨便挑一個 Podcurl 一下 Service 的 ClusterIP看通不通。不通的話檢查 kube-proxy 的規(guī)則。kube-proxy 默認 iptables 模式下用 iptables-save | grep 能看到規(guī)則。如果規(guī)則不存在重啟 kube-proxy Pod 或者直接看它的日志?？绻?jié)點 Pod 網(wǎng)絡(luò)不通屬于 CNI 問題。排查思路先確認 CNI 插件是什么。查看節(jié)點上的 /etc/cni/net.d/ 目錄。查看 CNI Pod 是否正常比如 Calico 的話就是 calico-node 和 calico-kube-controllers。在源 Pod 里 ping 目標 Pod 的 IP逐跳看丟在哪同時檢查節(jié)點的路由表比如 route -n 是否包含到 Pod 網(wǎng)段的路由。如果節(jié)點上有多個網(wǎng)卡常常是因為 CNI 選錯了主網(wǎng)卡導致 VXLAN 或 BGP 隧道建不起來。這種問題用 kubectl logs 看 CNI 組件日志一般都能看到明確的網(wǎng)卡異常提示。3.5 存儲與控制面PV/PVC 掛載失敗、etcd 抖動存儲類故障從使用者視角看就是 Pod 一直 ContainerCreatingEvents 里提示 FailedMount。排查 PV/PVC 有無綁定成功是很關(guān)鍵的一步kubectl get pvc 看 STATUS 是否為 Bound。Pending 狀態(tài)說明 StorageClass 或存儲插件有問題已經(jīng) Bound 但掛載失敗則要看存儲協(xié)議本身比如 NFS 掛載超時、CSI 插件未安裝。我個人的建議是排存儲問題時一定先把 kubelet 日志翻出來看完整報錯不要只看 Events因為頻繁遇到的是宿主機缺少 nfs-utils 這類基礎(chǔ)依賴報錯只出現(xiàn)在 kubelet 的日志里。控制面故障里etcd 抖動最有代表性。etcd 是 Kubernetes 所有狀態(tài)的底座如果它異常你會看到 kube-apiserver 報 etcdserver: request timed out整個集群開始“僵住”。排查時先看 etcd 集群健康狀態(tài)etcdctl endpoint health --cluster。再關(guān)注磁盤 IOetcd 對磁盤延遲極其敏感fsync 太慢會觸發(fā) leader 頻繁切換。用 iostat 看 etcd 數(shù)據(jù)盤的 await 值如果常年高于 50ms就得考慮換 SSD 或者走獨立盤。還有網(wǎng)絡(luò)延遲三個 etcd 節(jié)點之間延遲高也會導致心跳超時。這類問題我踩過一次調(diào)試時發(fā)現(xiàn) etcd 和業(yè)務混部在同一批機器流量高峰期直接拖垮了存儲鏈路。4. 破壞式實驗怎么設(shè)計我的排錯方法論與工具鏈看到這里你可能會說你講的故障我也都見過但每次都是靠運氣或者到處搜怎么能系統(tǒng)地練出排障手感下面這部分就是答案。我把“破壞式學習”落成了一套可執(zhí)行的方法你不妨照著做在測試環(huán)境里把故障一個個制造出來再親手修掉。4.1 分層排查法把故障“釘”在某一段無論遇到什么問題我的第一個判斷永遠是這個故障現(xiàn)在發(fā)生在調(diào)用鏈的哪一段我把 Kubernetes 排障分成四個層次從小到大容器層Pod鏡像、容器創(chuàng)建、應用進程、資源限制。節(jié)點層Nodekubelet、containerd、磁盤、內(nèi)存、網(wǎng)絡(luò)底層。集群網(wǎng)絡(luò)層CoreDNS、Service、Ingress、CNI、網(wǎng)絡(luò)策略?？刂泼鎸觡ube-apiserver、etcd、kube-scheduler、controller-manager。這個分層和調(diào)用鏈是對應的。排查時從上往下走先看最貼近業(yè)務、最容易觀察的一層不要一上來就查 etcd。我有一次帶新人排 Pod 創(chuàng)建失敗新人直接去查 kube-apiserver 日志查了半天發(fā)現(xiàn) API Server 一切正常問題其實是鏡像倉庫地址寫錯了。這就是沒分層導致的“繞遠路”。4.2 一組可以直接照做的“破壞實驗”清單你如果不知道從哪里開始破壞我推薦從這 10 個動作開始。每一個做完都要記錄“現(xiàn)象—根因—修復”三段筆記刪掉一個正在運行的 Deployment觀察 ReplicaSet 怎么重建。把某 Pod 的鏡像名改錯觀察 ImagePullBackOff。給 Pod 設(shè)置一個極小的 memory limit 并壓測觀察 OOMKilled。把 Deployment 的 replicas 調(diào)到調(diào)度器無法滿足的數(shù)量觀察 Pending。手動給節(jié)點添加一個污點 taint觀察已有 Pod 是否被驅(qū)逐、新 Pod 是否調(diào)度不上。停掉 kubelet 服務 30 秒再啟動觀察節(jié)點 NotReady 到 Ready 的轉(zhuǎn)換。在節(jié)點上手動 kill 掉一個業(yè)務容器的進程觀察容器重啟策略。把 CoreDNS 的 Deployment 縮到 0觀察集群內(nèi)域名解析癥狀。改掉 Service 的 selector觀察 Endpoints 為空、Service 不通。刪除一個 PVC 對應的底層存儲目錄觀察 FailedMount。做完這些你會對“Kubernetes 是一個自愈系統(tǒng)但自愈的前提是故障能被它識別到”這件事有極其深的理解。比如你手動 kill 進程后kubelet 會按照 restartPolicy 把容器重新拉起來但你如果把節(jié)點的 kubelet 停了節(jié)點整個進入 NotReady反而不會有人管它。這個邊界不親手做一次破壞是體會不到的。4.3 我在線上驗證過的固定排錯順序線上和測試不一樣最快止損永遠比弄清原理更重要。所以我給自己定了一套固定順序你自己也可以按這套來先看全局kubectl get nodes、kubectl get pods -A確認故障范圍是單 Pod、單節(jié)點還是整個集群。再看事件kubectl describe pod/node 里的 Events 往往能直接指向根因。然后看日志按 pod → kubelet → containerd 的順序逐層追日志。最后動手修復能滾動重啟就先滾能刪異常 Pod 就先刪等業(yè)務恢復后再二次復盤根因。這套順序最大的價值是防止在排查階段花太久。記住線上場景下恢復業(yè)務優(yōu)先級永遠是第一位的。等到故障解除再帶著從現(xiàn)場截取的日志去深挖原因。4.4 順手整理一下排障工具鏈kubectl一切入口。describe、get、logs、exec 是高頻動作。crictl節(jié)點上繞開 kubectl 直接看容器運行時狀態(tài)。ctrcontainerd 原生調(diào)試工具。journalctl看 kubelet 和 containerd 系統(tǒng)服務日志。iptables-save / ipvsadm查 kube-proxy 規(guī)則。nsenter / netstat / ss進到容器的網(wǎng)絡(luò)命名空間里做網(wǎng)絡(luò)排查。etcdctl控制面 etcd 健康檢查和數(shù)據(jù)目錄檢查。5. 從實戰(zhàn)到面試Kubernetes 高頻問題延伸思考很多運維去面試前瘋狂背八股我的建議恰恰相反把實戰(zhàn)里驗證過的東西用自己的話講出來比背概念高級得多。接下來我把這個系列涉及的核心能力對應到面試中最常被問的問題上。5.1 調(diào)用鏈相關(guān)kubelet 和 containerd 的關(guān)系怎么答面試題直接問“kubelet 是如何調(diào)用 containerd 的”其實考察的就是你是否理解 CRI 抽象。你可以這樣組織答案kubelet 并不直接調(diào)用 containerd而是通過 CRI 接口以 gRPC 方式調(diào)用 containerd 內(nèi)置的 CRI Plugin。調(diào)用路徑是 kubelet → CRI gRPC 客戶端 → /run/containerd/containerd.sock → containerd CRI Plugin → containerd-shim → runc。創(chuàng)建 Pod 時第一個關(guān)鍵請求是 RunPodSandboxcontainerd 會拉取 pause 鏡像并創(chuàng)建沙箱隨后 kubelet 發(fā)起 CreateContainer 和 StartContainercontainerd 啟動一個 shim 進程shim 再調(diào)用 runc 完成容器創(chuàng)建。如果能再補上 pause 容器和 shim 進程的作用面試官基本就能確定你是真做過底層排查的人。5.2 故障排查類用“分層排錯”回答拉開差距比如面試官問“Pod 一直 Pending你怎么排查”。很多人上來就答“資源不足”但更好的回答是先 kubectl describe pod 看 EventsPending 的根因可能有資源不足、節(jié)點親和性不滿足、存在污點、PVC 未綁定、或者調(diào)度器異常。資源不足要看 allocatable 和 request污點要看 node 的 taints 和 Pod 的 tolerationsPVC 要看 pvc 的 STATUS 是否 Bound。把每個可能都給出對應驗證命令再給出解決方案這就是“有實戰(zhàn)經(jīng)驗”的回答。另一道高頻題“Service 訪問不通如何排查”我建議按這個順序先 get endpoints 確認后端 Pod 是否被正確關(guān)聯(lián)然后進入集群內(nèi) Pod 直接訪問 ClusterIP 驗證網(wǎng)絡(luò)通路如果還是不通檢查 kube-proxy 模式和 iptables/IPVS 規(guī)則最后看 CNI 底層是否存在跨節(jié)點路由問題。這個回答天然帶著分層排錯的邏輯面試官會看到你腦子里有一條清晰的鏈路。5.3 原理型問題從“會用”到“說清楚”還有一類面試題問的是“為什么 Pod 是最小調(diào)度單元”“為什么不直接在一個容器里跑多個進程”。這些問題的核心其實是 pause 容器和命名空間共享機制。一個 Pod 里的多個容器共享同一個網(wǎng)絡(luò)命名空間、IPC 命名空間、UTS 命名空間也能共享 Volume但它們的進程命名空間默認不共享。這種設(shè)計讓“一個 Pod 里放一個主容器和幾個輔助容器比如日志收集 sidecar”成了可能。如果你能順手解釋一下為什么業(yè)務容器重啟而 Pod IP 不變化——因為 pause 容器決定了網(wǎng)絡(luò)命名空間的生命周期——那這題基本就滿分了。6. 寫在最后我的一點個人體會寫這個系列之前我以為自己已經(jīng)對 Kubernetes 的故障有免疫力了結(jié)果今年在一次壓測環(huán)境里還是被一個 kubelet 版本和 containerd 版本不完全兼容的毛病折騰到凌晨三點。版本不匹配這種問題不親手踩一次光看升級文檔你是永遠記不住的。這也是我為什么一直堅持“破壞式學習”——教訓往往比經(jīng)驗更深刻。如果你現(xiàn)在還在入門階段我的建議是不要怕弄壞集群。搭一套單節(jié)點的 kind 或者 minikube然后照著 4.2 節(jié)里的破壞實驗清單一天破壞一個堅持兩周。等你親手修好了十來個故障再回頭看文檔以前看不懂的部分會變得異常清晰。Kubernetes 這個系統(tǒng)天賦不夠沒關(guān)系踩坑來湊踩得多了你就是那個能一眼定位斷點的人。