<關(guān)注公眾號(hào)，回復(fù)“排查”獲取下載鏈接>

《深入淺出 Kubernetes》開放下載

本書作者羅建龍（花名聲東），阿里云技術(shù)專家，有著多年操作系統(tǒng)和圖形顯卡驅(qū)動(dòng)調(diào)試和開發(fā)經(jīng)驗(yàn)。目前專注云原生領(lǐng)域，容器集群和服務(wù)網(wǎng)格。本書分為理論篇和實(shí)踐篇，共匯集了 12 篇技術(shù)文章，深入解析了集群控制、集群伸縮原理、鏡像拉取等理論，帶你實(shí)現(xiàn)從基礎(chǔ)概念的準(zhǔn)確理解到上手實(shí)操的精準(zhǔn)熟練，深入淺出使用 Kubernetes！

本書共有以下四大亮點(diǎn)：

• 線上海量真實(shí)案例的沉淀
• 理論和實(shí)踐的完美契合
• 理論闡述深入淺出
• 技術(shù)細(xì)節(jié)追根究底

幫助你一次搞懂 6 個(gè)核心原理，吃透基礎(chǔ)理論，一次學(xué)會(huì) 6 個(gè)典型問(wèn)題的華麗操作！

（本書目錄）

如何免費(fèi)下載？

關(guān)注“阿里巴巴云原生”，回復(fù)?**排查?**，即可免費(fèi)下載此書。

前言

以下內(nèi)容節(jié)選自《深入淺出 Kubernetes》一書。

阿里云有自己的 Kubernetes 容器集群產(chǎn)品。隨著 Kubernetes 集群出貨量的劇增，線上用戶零星的發(fā)現(xiàn)，集群會(huì)非常低概率地出現(xiàn)節(jié)點(diǎn) NotReady 情況。

據(jù)我們觀察，這個(gè)問(wèn)題差不多每個(gè)月就會(huì)有一到兩個(gè)客戶遇到。在節(jié)點(diǎn) NotReady 之后，集群 Master 沒有辦法對(duì)這個(gè)節(jié)點(diǎn)做任何控制，比如下發(fā)新的 Pod，再比如抓取節(jié)點(diǎn)上正在運(yùn)行 Pod 的實(shí)時(shí)信息。

在上面的問(wèn)題中，我們的排查路徑從 K8s 集群到容器運(yùn)行時(shí)，再到 sdbus 和 systemd，不可謂不復(fù)雜。這個(gè)問(wèn)題目前已經(jīng)在 systemd 中做了修復(fù)，所以基本上能看到這個(gè)問(wèn)題的幾率是越來(lái)越低了。

但是，集群節(jié)點(diǎn)就緒問(wèn)題還是有的，然而原因卻有所不同。

今天這篇文章，將側(cè)重和大家分享另外一例集群節(jié)點(diǎn) NotReady 的問(wèn)題。這個(gè)問(wèn)題和上面問(wèn)題相比，排查路徑完全不同。

問(wèn)題現(xiàn)象

這個(gè)問(wèn)題的現(xiàn)象，也是集群節(jié)點(diǎn)會(huì)變成 NotReady 狀態(tài)。問(wèn)題可以通過(guò)重啟節(jié)點(diǎn)暫時(shí)解決，但是在經(jīng)過(guò)大概 20 天左右之后，問(wèn)題會(huì)再次出現(xiàn)。

問(wèn)題出現(xiàn)之后，如果我們重啟節(jié)點(diǎn)上 kubelet，則節(jié)點(diǎn)會(huì)變成 Ready 狀態(tài)，但這種狀態(tài)只會(huì)持續(xù)三分鐘。這是一個(gè)特別的情況。

大邏輯

在具體分析這個(gè)問(wèn)題之前，我們先來(lái)看一下集群節(jié)點(diǎn)就緒狀態(tài)背后的大邏輯。K8s 集群中，與節(jié)點(diǎn)就緒狀態(tài)有關(guān)的組件，主要有四個(gè)，分別是：集群的核心數(shù)據(jù)庫(kù) etcd、集群的入口 API Server、節(jié)點(diǎn)控制器以及駐守在集群節(jié)點(diǎn)上直接管理節(jié)點(diǎn)的 kubelet。

一方面，kubelet 扮演的是集群控制器的角色，它定期從 API Server 獲取 Pod 等相關(guān)資源的信息，并依照這些信息，控制運(yùn)行在節(jié)點(diǎn)上 Pod 的執(zhí)行；另外一方面，kubelet 作為節(jié)點(diǎn)狀況的監(jiān)視器，它獲取節(jié)點(diǎn)信息，并以集群客戶端的角色，把這些狀況同步到 API Server。

在這個(gè)問(wèn)題中，kubelet 扮演的是第二種角色。

Kubelet 會(huì)使用上圖中的 NodeStatus 機(jī)制，定期檢查集群節(jié)點(diǎn)狀況，并把節(jié)點(diǎn)狀況同步到 API Server。而 NodeStatus 判斷節(jié)點(diǎn)就緒狀況的一個(gè)主要依據(jù)，就是 PLEG。

PLEG是Pod Lifecycle Events Generator的縮寫，基本上它的執(zhí)行邏輯，是定期檢查節(jié)點(diǎn)上Pod運(yùn)行情況，如果發(fā)現(xiàn)感興趣的變化，PLEG 就會(huì)把這種變化包裝成 Event 發(fā)送給 Kubelet 的主同步機(jī)制 syncLoop 去處理。但是，在 PLEG 的 Pod 檢查機(jī)制不能定期執(zhí)行的時(shí)候，NodeStatus 機(jī)制就會(huì)認(rèn)為，這個(gè)節(jié)點(diǎn)的狀況是不對(duì)的，從而把這種狀況同步到 API Server。

而最終把 kubelet 上報(bào)的節(jié)點(diǎn)狀況，落實(shí)到節(jié)點(diǎn)狀態(tài)的是節(jié)點(diǎn)控制這個(gè)組件。這里我故意區(qū)分了 kubelet 上報(bào)的節(jié)點(diǎn)狀況，和節(jié)點(diǎn)的最終狀態(tài)。因?yàn)榍罢?#xff0c;其實(shí)是我們 describe node 時(shí)看到的 Condition，而后者是真正節(jié)點(diǎn)列表里的 NotReady 狀態(tài)。

就緒三分鐘

在問(wèn)題發(fā)生之后，我們重啟 kubelet，節(jié)點(diǎn)三分鐘之后才會(huì)變成 NotReady 狀態(tài)。這個(gè)現(xiàn)象是問(wèn)題的一個(gè)關(guān)鍵切入點(diǎn)。

在解釋它之前，請(qǐng)大家看一下官方這張 PLEG 示意圖。這個(gè)圖片主要展示了兩個(gè)過(guò)程。

• 一方面，kubelet 作為集群控制器，從 API Server 處獲取 pod spec changes，然后通過(guò)創(chuàng)建 worker 線程來(lái)創(chuàng)建或結(jié)束掉 pod；
• 另外一方面，PLEG 定期檢查容器狀態(tài)，然后把狀態(tài)，以事件的形式反饋給 kubelet。

在這里，PLEG 有兩個(gè)關(guān)鍵的時(shí)間參數(shù)：一個(gè)是檢查的執(zhí)行間隔，另外一個(gè)是檢查的超時(shí)時(shí)間。以默認(rèn)情況為準(zhǔn)，PLEG 檢查會(huì)間隔一秒，換句話說(shuō)，每一次檢查過(guò)程執(zhí)行之后，PLEG 會(huì)等待一秒鐘，然后進(jìn)行下一次檢查；而每一次檢查的超時(shí)時(shí)間是三分鐘，如果一次 PLEG 檢查操作不能在三分鐘內(nèi)完成，那么這個(gè)狀況，會(huì)被上一節(jié)提到的 NodeStatus 機(jī)制，當(dāng)做集群節(jié)點(diǎn) NotReady 的憑據(jù)，同步給 API Server。

而我們之所以觀察到節(jié)點(diǎn)會(huì)在重啟 kubelet 之后就緒三分鐘，是因?yàn)?kubelet 重啟之后，第一次 PLEG 檢查操作就沒有順利結(jié)束。節(jié)點(diǎn)就緒狀態(tài)，直到三分鐘超時(shí)之后，才被同步到集群。

如下圖，上邊一行表示正常情況下 PLEG 的執(zhí)行流程，下邊一行則表示有問(wèn)題的情況。relist 是檢查的主函數(shù)。

止步不前的 PLEG

了解了原理，我們來(lái)看一下 PLEG 的日志。日志基本上可以分為兩部分，其中 skipping pod synchronization 這部分是 kubelet 同步函數(shù) syncLoop 輸出的，說(shuō)明它跳過(guò)了一次 pod 同步；而剩余 PLEG is not healthy: pleg was last seen active ago; threshold is 3m0s，則很清楚的展現(xiàn)了，上一節(jié)提到的 relist 超時(shí)三分鐘的問(wèn)題。

17:08:22.299597 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m0.000091019s ago; threshold is 3m0s] 17:08:22.399758 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m0.100259802s ago; threshold is 3m0s] 17:08:22.599931 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m0.300436887s ago; threshold is 3m0s] 17:08:23.000087 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m0.700575691s ago; threshold is 3m0s] 17:08:23.800258 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m1.500754856s ago; threshold is 3m0s] 17:08:25.400439 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m3.100936232s ago; threshold is 3m0s] 17:08:28.600599 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m6.301098811s ago; threshold is 3m0s] 17:08:33.600812 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m11.30128783s ago; threshold is 3m0s] 17:08:38.600983 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m16.301473637s ago; threshold is 3m0s] 17:08:43.601157 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m21.301651575s ago; threshold is 3m0s] 17:08:48.601331 kubelet skipping pod synchronization - [PLEG is not healthy: pleg was last seen active 3m26.301826001s ago; threshold is 3m0s]

能直接看到 relist 函數(shù)執(zhí)行情況的，是 kubelet 的調(diào)用棧。我們只要向 kubelet 進(jìn)程發(fā)送 SIGABRT 信號(hào)，golang 運(yùn)行時(shí)就會(huì)幫我們輸出 kubelet 進(jìn)程的所有調(diào)用棧。需要注意的是，這個(gè)操作會(huì)殺死 kubelet 進(jìn)程。但是因?yàn)檫@個(gè)問(wèn)題中，重啟 kubelet 并不會(huì)破壞重現(xiàn)環(huán)境，所以影響不大。

以下調(diào)用棧是 PLEG relist 函數(shù)的調(diào)用棧。從下往上，我們可以看到，relist 等在通過(guò) grpc 獲取 PodSandboxStatus。

kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc/transport.(*Stream).Header() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.recvResponse() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.invoke() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.Invoke() kubelet: k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2.(*runtimeServiceClient).PodSandboxStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/remote.(*RemoteRuntimeService).PodSandboxStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/kuberuntime.instrumentedRuntimeService.PodSandboxStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/kuberuntime.(*kubeGenericRuntimeManager).GetPodStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/pleg.(*GenericPLEG).updateCache() kubelet: k8s.io/kubernetes/pkg/kubelet/pleg.(*GenericPLEG).relist() kubelet: k8s.io/kubernetes/pkg/kubelet/pleg.(*GenericPLEG).(k8s.io/kubernetes/pkg/kubelet/pleg.relist)-fm() kubelet: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil.func1(0xc420309260) kubelet: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.JitterUntil() kubelet: k8s.io/kubernetes/vendor/k8s.io/apimachinery/pkg/util/wait.Until()

使用 PodSandboxStatus 搜索 kubelet 調(diào)用棧，很容易找到下邊這個(gè)線程，此線程是真正查詢 Sandbox 狀態(tài)的線程，從下往上看，我們會(huì)發(fā)現(xiàn)這個(gè)線程在 Plugin Manager 里嘗試去拿一個(gè) Mutex。

kubelet: sync.runtime_SemacquireMutex()kubelet: sync.(*Mutex).Lock() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim/network.(*PluginManager).GetPodNetworkStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim.(*dockerService).getIPFromPlugin() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim.(*dockerService).getIP() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim.(*dockerService).PodSandboxStatus() kubelet: k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2._RuntimeService_PodSandboxStatus_Handler() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).processUnaryRPC() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).handleStream() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1() kubelet: created by k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).serveStreams.func1

而這個(gè) Mutex 只有在 Plugin Manager 里邊有用到，所以我們查看所有 Plugin Manager 相關(guān)的調(diào)用棧。線程中一部分在等 Mutex，而剩余的都是在等 Terway cni plugin。

kubelet: syscall.Syscall6()kubelet: os.(*Process).blockUntilWaitable() kubelet: os.(*Process).wait()kubelet: os.(*Process).Wait() kubelet: os/exec.(*Cmd).Wait()kubelet: os/exec.(*Cmd).Run() kubelet: k8s.io/kubernetes/vendor/github.com/containernetworking/cni/pkg/invoke.(*RawExec).ExecPlugin() kubelet: k8s.io/kubernetes/vendor/github.com/containernetworking/cni/pkg/invoke.(*PluginExec).WithResult() kubelet: k8s.io/kubernetes/vendor/github.com/containernetworking/cni/pkg/invoke.ExecPluginWithResult() kubelet: k8s.io/kubernetes/vendor/github.com/containernetworking/cni/libcni.(*CNIConfig).AddNetworkList() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim/network/cni.(*cniNetworkPlugin).addToNetwork() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim/network/cni.(*cniNetworkPlugin).SetUpPod() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim/network.(*PluginManager).SetUpPod() kubelet: k8s.io/kubernetes/pkg/kubelet/dockershim.(*dockerService).RunPodSandbox() kubelet: k8s.io/kubernetes/pkg/kubelet/apis/cri/runtime/v1alpha2._RuntimeService_RunPodSandbox_Handler() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).processUnaryRPC() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).handleStream() kubelet: k8s.io/kubernetes/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1()

無(wú)響應(yīng)的 Terwayd

在進(jìn)一步解釋這個(gè)問(wèn)題之前，我們需要區(qū)分下 Terway 和 Terwayd。本質(zhì)上來(lái)說(shuō)，Terway 和 Terwayd 是客戶端服務(wù)器的關(guān)系，這跟 flannel 和 flanneld 之間的關(guān)系是一樣的。Terway 是按照 kubelet 的定義，實(shí)現(xiàn)了 cni 接口的插件。

而在上一節(jié)最后，我們看到的問(wèn)題，是 kubelet 調(diào)用 CNI terway 去配置 pod 網(wǎng)絡(luò)的時(shí)候，Terway 長(zhǎng)時(shí)間無(wú)響應(yīng)。正常情況下這個(gè)操作應(yīng)該是秒級(jí)的，非常快速。而出問(wèn)題的時(shí)候，Terway 沒有正常完成任務(wù)，因而我們?cè)诩汗?jié)點(diǎn)上看到大量 terway 進(jìn)程堆積。

同樣的，我們可以發(fā)送 SIGABRT 給這些 terway 插件進(jìn)程，來(lái)打印出進(jìn)程的調(diào)用棧。下邊是其中一個(gè) terway 的調(diào)用棧。這個(gè)線程在執(zhí)行 cmdDel 函數(shù)，其作用是刪除一個(gè) pod 網(wǎng)絡(luò)相關(guān)配置。

kubelet: net/rpc.(*Client).Call() kubelet: main.rpcCall()kubelet: main.cmdDel() kubelet: github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/cni/pkg/skel.(*dispatcher).checkVersionAndCall() kubelet: github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/cni/pkg/skel.(*dispatcher).pluginMain() kubelet: github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/cni/pkg/skel.PluginMainWithError() kubelet: github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/cni/pkg/skel.PluginMain()

以上線程通過(guò) rpc 調(diào)用 terwayd，來(lái)真正的移除 pod 網(wǎng)絡(luò)。所以我們需要進(jìn)一步排查 terwayd 的調(diào)用棧來(lái)進(jìn)一步定位此問(wèn)題。Terwayd 作為 Terway 的服務(wù)器端，其接受 Terway 的遠(yuǎn)程調(diào)用，并替 Terway 完成其 cmdAdd 或者 cmdDel 來(lái)創(chuàng)建或者移除 pod 網(wǎng)絡(luò)配置。

我們?cè)谏线叺慕貓D里可以看到，集群節(jié)點(diǎn)上有成千 Terway 進(jìn)程，他們都在等待 Terwayd，所以實(shí)際上 Terwayd 里，也有成千的線程在處理 Terway 的請(qǐng)求。

使用下邊的命令，可以在不重啟 Terwayd 的情況下，輸出調(diào)用棧。

curl --unix-socket /var/run/eni/eni.socket 'http:/debug/pprof/goroutine?debug=2'

因?yàn)?Terwayd 的調(diào)用棧非常復(fù)雜，而且?guī)缀跛械木€程都在等鎖，直接去分析鎖的等待持有關(guān)系比較復(fù)雜。這個(gè)時(shí)候我們可以使用“時(shí)間大法”，即假設(shè)最早進(jìn)入等待狀態(tài)的線程，大概率是持有鎖的線程。

經(jīng)過(guò)調(diào)用棧和代碼分析，我們發(fā)現(xiàn)下邊這個(gè)是等待時(shí)間最長(zhǎng)（1595 分鐘），且拿了鎖的線程。而這個(gè)鎖會(huì) block 所有創(chuàng)建或者銷毀 pod 網(wǎng)絡(luò)的線程。

goroutine 67570 [syscall, 1595 minutes, locked to thread]: syscall.Syscall6() github.com/AliyunContainerService/terway/vendor/golang.org/x/sys/unix.recvfrom() github.com/AliyunContainerService/terway/vendor/golang.org/x/sys/unix.Recvfrom() github.com/AliyunContainerService/terway/vendor/github.com/vishvananda/netlink/nl.(*NetlinkSocket).Receive() github.com/AliyunContainerService/terway/vendor/github.com/vishvananda/netlink/nl.(*NetlinkRequest).Execute() github.com/AliyunContainerService/terway/vendor/github.com/vishvananda/netlink.(*Handle).LinkSetNsFd() github.com/AliyunContainerService/terway/vendor/github.com/vishvananda/netlink.LinkSetNsFd() github.com/AliyunContainerService/terway/daemon.SetupVethPair()github.com/AliyunContainerService/terway/daemon.setupContainerVeth.func1() github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/plugins/pkg/ns.(*netNS).Do.func1() github.com/AliyunContainerService/terway/vendor/github.com/containernetworking/plugins/pkg/ns.(*netNS).Do.func2()

原因深入分析前一個(gè)線程的調(diào)用棧，我們可以確定三件事情。

• 第一，Terwayd 使用了 netlink 這個(gè)庫(kù)來(lái)管理節(jié)點(diǎn)上的虛擬網(wǎng)卡，IP 地址及路由等資源，且 netlink 實(shí)現(xiàn)了類似 iproute2 的功能；
• 第二，netlink 使用 socket 直接和內(nèi)核通信；
• 第三，以上線程等在 recvfrom 系統(tǒng)調(diào)用上。

這樣的情況下，我們需要去查看這個(gè)線程的內(nèi)核調(diào)用棧，才能進(jìn)一步確認(rèn)這個(gè)線程等待的原因。因?yàn)閺?goroutine 線程號(hào)比較不容易找到這個(gè)線程的系統(tǒng)線程 id，這里我們通過(guò)抓取系統(tǒng)的 core dump 來(lái)找出上邊線程的內(nèi)核調(diào)用棧。

在內(nèi)核調(diào)用棧中，搜索 recvfrom，定位到下邊這個(gè)線程。基本上從下邊的調(diào)用棧上，我們只能確定，此線程等在 recvfrom 函數(shù)上。

PID: 19246 TASK: ffff880951f70fd0 CPU: 16 COMMAND: "terwayd" #0 [ffff880826267a40] __schedule at ffffffff816a8f65 #1 [ffff880826267aa8] schedule at ffffffff816a94e9 #2 [ffff880826267ab8] schedule_timeout at ffffffff816a6ff9 #3 [ffff880826267b68] __skb_wait_for_more_packets at ffffffff81578f80 #4 [ffff880826267bd0] __skb_recv_datagram at ffffffff8157935f #5 [ffff880826267c38] skb_recv_datagram at ffffffff81579403 #6 [ffff880826267c58] netlink_recvmsg at ffffffff815bb312 #7 [ffff880826267ce8] sock_recvmsg at ffffffff8156a88f #8 [ffff880826267e58] SYSC_recvfrom at ffffffff8156aa08 #9 [ffff880826267f70] sys_recvfrom at ffffffff8156b2fe #10 [ffff880826267f80] tracesys at ffffffff816b5212 (via system_call)

這個(gè)問(wèn)題進(jìn)一步深入排查，是比較困難的，這顯然是一個(gè)內(nèi)核問(wèn)題，或者內(nèi)核相關(guān)的問(wèn)題。我們翻遍了整個(gè)內(nèi)核 core，檢查了所有的線程調(diào)用棧，看不到其它可能與這個(gè)問(wèn)題相關(guān)聯(lián)的線程。

修復(fù)

這個(gè)問(wèn)題的修復(fù)基于一個(gè)假設(shè)，就是 netlink 并不是 100% 可靠的。netlink 可以響應(yīng)很慢，甚至完全沒有響應(yīng)。所以我們可以給 netlink 操作增加超時(shí)，從而保證就算某一次 netlink 調(diào)用不能完成的情況下，terwayd 也不會(huì)被阻塞。

總結(jié)

在節(jié)點(diǎn)就緒狀態(tài)這種場(chǎng)景下，kubelet 實(shí)際上實(shí)現(xiàn)了節(jié)點(diǎn)的心跳機(jī)制。kubelet 會(huì)定期把節(jié)點(diǎn)相關(guān)的各種狀態(tài)，包括內(nèi)存、PID、磁盤，當(dāng)然也包括本文中關(guān)注的就緒狀態(tài)等，同步到集群管控。kubelet 在監(jiān)控或者管理集群節(jié)點(diǎn)的過(guò)程中，使用了各種插件來(lái)直接操作節(jié)點(diǎn)資源。這包括網(wǎng)絡(luò)、磁盤，甚至容器運(yùn)行時(shí)等插件，這些插件的狀況，會(huì)直接應(yīng)用 kubelet 甚至節(jié)點(diǎn)的狀態(tài)。

<關(guān)注公眾號(hào)，回復(fù)?排查?即可下載本書>

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的技術(shù)圈。”

總結(jié)

以上是生活随笔為你收集整理的电子书下载 | 超实用！阿里售后专家的 K8s 问题排查案例合集的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。