節點上的Pod由Master管理。每個節點都必須運行kubelet、kube-proxy服務，而這些服務由Node Controller管理，當節點啟動后會自動向Master注冊自己，這樣Master能夠識別到該節點。Node Controller在節點出現故障時會進行相應處理。

<i id='zn3sb'></i>

kubelet

kubelet是主要的“節點代理”，它會監視分配給該節點的Pods，并確保這些Pods按照Kubernetes API中描述的那樣運行。kubelet不直接跟Master通信，而是通過kube-apiserver這個接口，并且每個節點上都會運行一個kubelet服務進程。

kube-proxy

kube-proxy負責為Pod網絡提供服務。它維護節點上的一些網絡規則，這些網絡規則允許網絡會話到達Pod。kube-proxy使用iptables管理這些網絡規則。在Kubernetes 1.2中，引入了一個新的代理模式，該模式使用用戶空間代理進行流量轉發，而不是iptables規則。這一模式仍在開發中，并可能在未來的版本中替代iptables模式。

容器運行時

要運行容器，Kubernetes使用一個容器運行時。Kubernetes本身并不直接包含任何容器運行時；相反，它設計成了一個可插拔的接口，可以支持多種容器運行時，例如Docker、rkt、containerd、CRI-O等。

節點狀態

節點有三種狀態：Ready、SchedulingDisabled和Unknown。如果節點處于Ready狀態，kubelet能夠正常工作，并且節點能夠接收新的Pods。如果節點處于SchedulingDisabled狀態，kubelet正常工作，但是Master不會將新的Pods調度到該節點上。如果節點處于Unknown狀態，則kubelet沒有正常報告節點的狀態，此時Master會自動停止將新的Pods調度到該節點上。

節點組件間的交互

節點上的kubelet通過與kube-apiserver交互來管理Pods和其容器。具體來說，kubelet會定期從kube-apiserver獲取節點的期望狀態（即運行在節點上的Pods的期望狀態），然后確保節點的實際狀態與期望狀態一致。如果實際狀態與期望狀態不一致，kubelet會嘗試修復它。

kube-proxy則負責實現Kubernetes服務（Service）的概念。它會監聽kube-apiserver中Service和Endpoint對象的變化，并據此更新節點上的網絡規則，確保客戶端能夠正確地訪問到Pods提供的服務。

容器運行時則負責實際運行容器。當kubelet決定需要創建或刪除一個容器時，它會通過容器運行時的接口來執行相應的操作。

這些組件之間的交互使得Kubernetes能夠在分布式環境中高效地管理和調度容器化應用。