Kubernetes 1.25 引入了對 kubelet 所管理的Pod Status?下的?condition?中?PodHasNetwork?的 Alpha 支持。對于工作節點，kubelet 將使用?PodHasNetwork condition?從容器運行時 （通常與 CNI 插件協作）創建 Pod 沙箱和網絡配置的角度準確地了解 Pod 的初始化狀態。在?PodHasNetwork condition?的 status 設置為?True?后，kubelet 開始拉取容器鏡像并啟動獨立的容器 （包括 Init 容器）。從集群基礎設施的角度報告 Pod 初始化延遲的指標采集服務 （無需知道每個容器的鏡像大小或有效負載等特征）就可以利用?PodHasNetwork condition?來準確生成服務水平指標（Service Level Indicator，SLI）。某些管理底層 Pod 的 Operator 或控制器可以利用?PodHasNetwork?狀況來優化 Pod 反復出現失敗時要執行的操作。

與 Intialized 有何不同？

根據 Pod 中是否存在 Init 容器，kubelet 會設置在 Pod 的 status 字段中報告的?Initialized condition?的狀態。

如果 Pod 指定了 Init 容器，則 Pod 狀態中的?Initialized condition?的 status 將不會設置為?True， 直到該 Pod 的所有 Init 容器都成功為止。但是，用戶配置的 Init 容器可能會出現錯誤（有效負載崩潰、無效鏡像等）， 并且 Pod 中配置的 Init 容器數量可能因工作負載不同而異。因此，關于 Pod 初始化的集群范圍基礎設施 SLI 不能依賴于 Pod 的?Initialized condition。

如果 Pod 未指定 Init 容器，則在 Pod 生命周期的早期， Pod 狀態中的?Initialized condition?的 status 會被設置為?True。這一設置發生在 kubelet 開始創建 Pod 運行時沙箱及配置網絡之前。因此，即使容器運行時未能成功初始化 Pod 沙箱環境，沒有 Init 容器的 Pod 也會將?Initialized?狀況的 status 報告為?True。

相對于上述任何一種情況，PodHasNetwork condition?會在 Pod 運行時沙箱被初始化并配置了網絡時能夠提供更準確的數據， 這樣 kubelet 可以繼續在 Pod 中啟動用戶配置的容器（包括 Init 容器）。

請注意，node agent可以通過監視指定附加網絡配置（例如?k8s.v1.cni.cncf.io/networks）的 Pod 注解變化， 來動態地為 Pod 重新配置網絡接口。Pod 沙箱被 Kubelet 初始化（結合容器運行時）之后 Pod 網絡配置的動態更新不反映在?PodHasNetwork condition?中。

試用 Pod 的?PodHasNetwork

為了讓 kubelet 在 Pod 的 status 字段中報告?PodHasNetwork condition?，需在 kubelet 上啟用?PodHasNetworkCondition?特性門。

對于一個運行時沙箱已經成功創建并配置了網絡的pod,?kubelet將報告status設置為True的PodHasNetwork condition：


對于尚未創建運行時沙箱（也未配置網絡）的 Pod，kubelet 將報告?status?設置為?False?的?PodHasNetwork condition：


下一步

Kubernetes 團隊根據反饋和采用情況，計劃在 1.26 或 1.27 中將?PodHasNetwork condition?提升到 Beta 階段。

作者：Deep Debroy (Apple)
出處：https://kubernetes.io/blog/2022/09/14/pod-has-network-condition/