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
:
$ kubectl describe pod nginx1
Name: nginx1
Namespace: default
...
Conditions:
Type Status
PodHasNetwork True
Initialized True
Ready True
ContainersReady True
PodScheduled True
对于尚未创建运行时沙箱(也未配置网络)的 Pod,kubelet 将报告 status
设置为 False
的 PodHasNetwork condition
:
$ kubectl describe pod nginx2
Name: nginx2
Namespace: default
...
Conditions:
Type Status
PodHasNetwork False
Initialized True
Ready False
ContainersReady False
PodScheduled True
下一步
Kubernetes 团队根据反馈和采用情况,计划在 1.26 或 1.27 中将 PodHasNetwork condition
提升到 Beta 阶段。