[zh] Add zh text to pods/pod-lifecycle.md and related feature gate
windsonsea
parent
0118584b8f
commit
b91ae5f2a5
|
|
@ -381,7 +381,6 @@ Kubernetes 通过在 Pod `spec` 中定义的 [`restartPolicy`](#restart-policy)
|
|||
(e.g., 10 minutes), Kubernetes resets the backoff delay, treating any new crash
|
||||
as the first one.
|
||||
-->
|
||||
|
||||
1. **最初的崩溃**：Kubernetes 尝试根据 Pod 的 `restartPolicy` 立即重新启动。
|
||||
1. **反复的崩溃**：在最初的崩溃之后，Kubernetes 对于后续重新启动的容器采用指数级回退延迟机制，
|
||||
如 [`restartPolicy`](#restart-policy) 中所述。
|
||||
|
|
@ -510,6 +509,71 @@ kubelet 就会重置该容器的重启延迟计时器。
|
|||
[Sidecar 容器和 Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/sidecar-containers/#sidecar-containers-and-pod-lifecycle)中解释了
|
||||
`init containers` 在指定 `restartpolicy` 字段时的行为。
|
||||
|
||||
<!--
|
||||
### Configurable container restart delay
|
||||
-->
|
||||
### 可配置的容器重启延迟 {#configurable-container-restart-delay}
|
||||
|
||||
{{< feature-state feature_gate_name="KubeletCrashLoopBackOffMax" >}}
|
||||
|
||||
<!--
|
||||
With the alpha feature gate `KubeletCrashLoopBackOffMax` enabled, you can
|
||||
reconfigure the maximum delay between container start retries from the default
|
||||
of 300s (5 minutes). This configuration is set per node using kubelet
|
||||
configuration. In your [kubelet configuration](/docs/tasks/administer-cluster/kubelet-config-file/),
|
||||
under `crashLoopBackOff` set the `maxContainerRestartPeriod` field between
|
||||
`"1s"` and `"300s"`. As described above in [Container restart
|
||||
policy](#restart-policy), delays on that node will still start at 10s and
|
||||
increase exponentially by 2x each restart, but will now be capped at your
|
||||
configured maximum. If the `maxContainerRestartPeriod` you configure is less
|
||||
than the default initial value of 10s, the initial delay will instead be set to
|
||||
the configured maximum.
|
||||
-->
|
||||
启用 Alpha 特性门控 `KubeletCrashLoopBackOffMax` 后，
|
||||
你可以重新配置容器启动重试之间的最大延迟，默认值为 300 秒（5 分钟）。
|
||||
此配置是针对每个节点使用 kubelet 配置进行设置的。
|
||||
在你的 [kubelet 配置](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)中，
|
||||
在 `crashLoopBackOff` 下设置 `maxContainerRestartPeriod` 字段，取值范围在 `"1s"` 到 `"300s"` 之间。
|
||||
如上文[容器重启策略](#restart-policy)所述，该节点上的延迟仍将从 10 秒开始，并在每次重启后以指数方式增加
|
||||
2 倍，但现在其上限将被限制为你所配置的最大值。如果你配置的 `maxContainerRestartPeriod` 小于默认初始值 10 秒，
|
||||
则初始延迟将被设置为配置的最大值。
|
||||
|
||||
<!--
|
||||
See the following kubelet configuration examples:
|
||||
|
||||
```yaml
|
||||
# container restart delays will start at 10s, increasing
|
||||
# 2x each time they are restarted, to a maximum of 100s
|
||||
kind: KubeletConfiguration
|
||||
crashLoopBackOff:
|
||||
maxContainerRestartPeriod: "100s"
|
||||
```
|
||||
-->
|
||||
参见以下 kubelet 配置示例：
|
||||
|
||||
```yaml
|
||||
# 容器重启延迟将从 10 秒开始，每次重启增加 2 倍
|
||||
# 最高达到 100 秒
|
||||
kind: KubeletConfiguration
|
||||
crashLoopBackOff:
|
||||
maxContainerRestartPeriod: "100s"
|
||||
```
|
||||
|
||||
<!--
|
||||
```yaml
|
||||
# delays between container restarts will always be 2s
|
||||
kind: KubeletConfiguration
|
||||
crashLoopBackOff:
|
||||
maxContainerRestartPeriod: "2s"
|
||||
```
|
||||
-->
|
||||
```yaml
|
||||
# 容器重启之间的延迟将始终为 2 秒
|
||||
kind: KubeletConfiguration
|
||||
crashLoopBackOff:
|
||||
maxContainerRestartPeriod: "2s"
|
||||
```
|
||||
|
||||
<!--
|
||||
## Pod conditions
|
||||
|
||||
|
|
@ -1311,8 +1375,7 @@ Additionally, PodGC cleans up any Pods which satisfy any of the following condit
|
|||
1. are orphan Pods - bound to a node which no longer exists,
|
||||
1. are unscheduled terminating Pods,
|
||||
1. are terminating Pods, bound to a non-ready node tainted with
|
||||
[`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service),
|
||||
when the `NodeOutOfServiceVolumeDetach` feature gate is enabled.
|
||||
[`node.kubernetes.io/out-of-service`](/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service).
|
||||
|
||||
Along with cleaning up the Pods, PodGC will also mark them as failed if they are in a non-terminal
|
||||
phase. Also, PodGC adds a Pod disruption condition when cleaning up an orphan Pod.
|
||||
|
|
@ -1323,8 +1386,8 @@ for more details.
|
|||
|
||||
1. 孤儿 Pod - 绑定到不再存在的节点，
|
||||
2. 计划外终止的 Pod
|
||||
3. 终止过程中的 Pod，当启用 `NodeOutOfServiceVolumeDetach` 特性门控时，
|
||||
绑定到有 [`node.kubernetes.io/out-of-service`](/zh-cn/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service)
|
||||
3. 终止过程中的 Pod，绑定到有
|
||||
[`node.kubernetes.io/out-of-service`](/zh-cn/docs/reference/labels-annotations-taints/#node-kubernetes-io-out-of-service)
|
||||
污点的未就绪节点。
|
||||
|
||||
在清理 Pod 的同时，如果它们处于非终止状态阶段，PodGC 也会将它们标记为失败。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,18 @@
|
|||
---
|
||||
title: KubeletCrashLoopBackOffMax
|
||||
content_type: feature_gate
|
||||
_build:
|
||||
list: never
|
||||
render: false
|
||||
|
||||
stages:
|
||||
- stage: alpha
|
||||
defaultValue: false
|
||||
fromVersion: "1.32"
|
||||
---
|
||||
|
||||
<!--
|
||||
Enables support for configurable per-node backoff maximums for restarting
|
||||
containers in the CrashLoopBackOff state.
|
||||
-->
|
||||
启用对可逐节点配置的、在重启 CrashLoopBackOff 状态的容器时回退最大值的支持。
|
||||
Loading…
Reference in New Issue