Skip to content

Commit e4233d8

Browse files
committed
[zh]Sync 2022-09-14-pod-has-network-condition.md
1 parent be2a8b6 commit e4233d8

File tree

1 file changed

+36
-19
lines changed

1 file changed

+36
-19
lines changed

content/zh-cn/blog/_posts/2022-09-14-pod-has-network-condition.md

Lines changed: 36 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -6,7 +6,7 @@ slug: pod-has-network-condition
66
---
77
<!--
88
layout: blog
9-
title: 'Kubernetes 1.25: PodHasNetwork condition for pods'
9+
title: 'Kubernetes 1.25: PodHasNetwork Condition for Pods'
1010
date: 2022-09-14
1111
slug: pod-has-network-condition
1212
-->
@@ -26,7 +26,7 @@ state of a pod from the perspective of pod sandbox creation and network
2626
configuration by a container runtime (typically in coordination with CNI
2727
plugins). The kubelet starts to pull container images and start individual
2828
containers (including init containers) after the status of the `PodHasNetwork`
29-
condition is set to `True`. Metrics collection services that report latency of
29+
condition is set to `"True"`. Metrics collection services that report latency of
3030
pod initialization from a cluster infrastructural perspective (i.e. agnostic of
3131
per container characteristics like image size or payload) can utilize the
3232
`PodHasNetwork` condition to accurately generate Service Level Indicators
@@ -37,7 +37,7 @@ repeatedly fail to come up.
3737
Kubernetes 1.25 引入了对 kubelet 所管理的新的 Pod 状况 `PodHasNetwork` 的 Alpha 支持,
3838
该状况位于 Pod 的 status 字段中 。对于工作节点,kubelet 将使用 `PodHasNetwork` 状况从容器运行时
3939
(通常与 CNI 插件协作)创建 Pod 沙箱和网络配置的角度准确地了解 Pod 的初始化状态。
40-
`PodHasNetwork` 状况的 status 设置为 `True` 后,kubelet 开始拉取容器镜像并启动独立的容器
40+
`PodHasNetwork` 状况的 status 设置为 `"True"` 后,kubelet 开始拉取容器镜像并启动独立的容器
4141
(包括 Init 容器)。从集群基础设施的角度报告 Pod 初始化延迟的指标采集服务
4242
(无需知道每个容器的镜像大小或有效负载等特征)就可以利用 `PodHasNetwork`
4343
状况来准确生成服务水平指标(Service Level Indicator,SLI)。
@@ -55,31 +55,32 @@ the status field of a pod depending on the presence of init containers in a pod.
5555

5656
<!--
5757
If a pod specifies init containers, the status of the `Initialized` condition in
58-
the pod status will not be set to `True` until all init containers for the pod
58+
the pod status will not be set to `"True"` until all init containers for the pod
5959
have succeeded. However, init containers, configured by users, may have errors
6060
(payload crashing, invalid image, etc) and the number of init containers
6161
configured in a pod may vary across different workloads. Therefore,
6262
cluster-wide, infrastructural SLIs around pod initialization cannot depend on
6363
the `Initialized` condition of pods.
6464
-->
65-
如果 Pod 指定了 Init 容器,则 Pod 状态中的 `Initialized` 状况的 status 将不会设置为 `True`
65+
如果 Pod 指定了 Init 容器,则 Pod 状态中的 `Initialized` 状况的 status 将不会设置为 `"True"`
6666
直到该 Pod 的所有 Init 容器都成功为止。但是,用户配置的 Init 容器可能会出现错误(有效负载崩溃、无效镜像等),
6767
并且 Pod 中配置的 Init 容器数量可能因工作负载不同而异。
6868
因此,关于 Pod 初始化的集群范围基础设施 SLI 不能依赖于 Pod 的 `Initialized` 状况。
6969

7070
<!--
7171
If a pod does not specify init containers, the status of the `Initialized`
72-
condition in the pod status is set to `True` very early in the lifecycle of the
73-
pod. This occurs before the kubelet initiates any pod runtime sandbox creation
74-
and network configuration steps. As a result, a pod without init containers will
75-
report the status of the `Initialized` condition as `True` even if the container
76-
runtime is not able to successfully initialize the pod sandbox environment.
72+
condition in the pod status is set to `"True"` very early in the lifecycle of
73+
the pod. This occurs before the kubelet initiates any pod runtime sandbox
74+
creation and network configuration steps. As a result, a pod without init
75+
containers will report the status of the `Initialized` condition as `"True"`
76+
even if the container runtime is not able to successfully initialize the pod
77+
sandbox environment.
7778
-->
7879
如果 Pod 未指定 Init 容器,则在 Pod 生命周期的早期,
79-
Pod 状态中的 `Initialized` 状况的 status 会被设置为 `True`
80+
Pod 状态中的 `Initialized` 状况的 status 会被设置为 `"True"`
8081
这一设置发生在 kubelet 开始创建 Pod 运行时沙箱及配置网络之前。
8182
因此,即使容器运行时未能成功初始化 Pod 沙箱环境,没有 Init 容器的
82-
Pod 也会将 `Initialized` 状况的 status 报告为 `True`
83+
Pod 也会将 `Initialized` 状况的 status 报告为 `"True"`
8384

8485
<!--
8586
Relative to either situation above, the `PodHasNetwork` condition surfaces more
@@ -91,14 +92,30 @@ containers (including init containers) in the pod.
9192
这样 kubelet 可以继续在 Pod 中启动用户配置的容器(包括 Init 容器)。
9293

9394
<!--
94-
Note that a node agent may dynamically re-configure network interface(s) for a
95-
pod by watching changes in pod annotations that specify additional networking
95+
### Special Cases
96+
97+
If a pod specifies `hostNetwork` as `"True"`, the `PodHasNetwork` condition is
98+
set to `"True"` based on successful creation of the pod sandbox while the
99+
network configuration state of the pod sandbox is ignored. This is because the
100+
CRI implementation typically skips any pod sandbox network configuration when
101+
`hostNetwork` is set to `"True"` for a pod.
102+
-->
103+
### 特殊场景
104+
105+
如果一个 Pod 指定 `hostNetwork``"True"`
106+
系统会根据 Pod 沙箱创建操作是否成功来决定要不要将 `PodHasNetwork` 状况设置为 `"True"`
107+
设置此状况时会忽略 Pod 沙箱的网络配置状态。这是因为 Pod 的 `hostNetwork` 被设置为
108+
`"True"` 时 CRI 实现通常会跳过所有 Pod 沙箱网络配置。
109+
110+
<!--
111+
A node agent may dynamically re-configure network interface(s) for a pod by
112+
watching changes in pod annotations that specify additional networking
96113
configuration (e.g. `k8s.v1.cni.cncf.io/networks`). Dynamic updates of pod
97114
networking configuration after the pod sandbox is initialized by Kubelet (in
98115
coordination with a container runtime) are not reflected by the `PodHasNetwork`
99116
condition.
100117
-->
101-
请注意,节点代理可以通过监视指定附加网络配置(例如 `k8s.v1.cni.cncf.io/networks`)的 Pod 注解变化,
118+
节点代理可以通过监视指定附加网络配置(例如 `k8s.v1.cni.cncf.io/networks`)的 Pod 注解变化,
102119
来动态地为 Pod 重新配置网络接口。Pod 沙箱被 Kubelet 初始化(结合容器运行时)之后
103120
Pod 网络配置的动态更新不反映在 `PodHasNetwork` 状况中。
104121

@@ -110,14 +127,14 @@ field of a pod, please enable the `PodHasNetworkCondition` feature gate on the
110127
kubelet.
111128
112129
For a pod whose runtime sandbox has been successfully created and has networking
113-
configured, the kubelet will report the `PodHasNetwork` condition with status set to `True`:
130+
configured, the kubelet will report the `PodHasNetwork` condition with status set to `"True"`:
114131
-->
115132
### 试用 Pod 的 `PodHasNetwork` 状况
116133

117134
为了让 kubelet 在 Pod 的 status 字段中报告 `PodHasNetwork` 状况,需在 kubelet 上启用
118135
`PodHasNetworkCondition` 特性门控。
119136

120-
对于已成功创建运行时沙箱并已配置网络的 Pod,在 status 设置为 `True` 后,
137+
对于已成功创建运行时沙箱并已配置网络的 Pod,在 status 设置为 `"True"` 后,
121138
kubelet 将报告 `PodHasNetwork` 状况:
122139

123140
```
@@ -137,9 +154,9 @@ Conditions:
137154
<!--
138155
For a pod whose runtime sandbox has not been created yet (and networking not
139156
configured either), the kubelet will report the `PodHasNetwork` condition with
140-
status set to `False`:
157+
status set to `"False"`:
141158
-->
142-
对于尚未创建运行时沙箱(也未配置网络)的 Pod,在 status 设置为 `False` 后,
159+
对于尚未创建运行时沙箱(也未配置网络)的 Pod,在 status 设置为 `"False"` 后,
143160
kubelet 将报告 `PodHasNetwork` 状况:
144161

145162
```

0 commit comments

Comments
 (0)