|
| 1 | +--- |
| 2 | +title: 从轮询切换为基于 CRI 事件的更新来获取容器状态 |
| 3 | +min-kubernetes-server-version: 1.26 |
| 4 | +content_type: task |
| 5 | +weight: 90 |
| 6 | +--- |
| 7 | +<!-- |
| 8 | +title: Switching from Polling to CRI Event-based Updates to Container Status |
| 9 | +min-kubernetes-server-version: 1.26 |
| 10 | +content_type: task |
| 11 | +weight: 90 |
| 12 | +--> |
| 13 | + |
| 14 | +{{< feature-state for_k8s_version="v1.27" state="beta" >}} |
| 15 | + |
| 16 | +<!-- overview --> |
| 17 | + |
| 18 | +<!-- |
| 19 | +This page shows how to migrate nodes to use event based updates for container status. The event-based |
| 20 | +implementation reduces node resource consumption by the kubelet, compared to the legacy approach |
| 21 | +that relies on polling. |
| 22 | +You may know this feature as _evented Pod lifecycle event generator (PLEG)_. That's the name used |
| 23 | +internally within the Kubernetes project for a key implementation detail. |
| 24 | +
|
| 25 | +The polling based approach is referred to as _generic PLEG_. |
| 26 | +--> |
| 27 | +本页展示了如何迁移节点以使用基于事件的更新来获取容器状态。 |
| 28 | +与依赖轮询的传统方法相比,基于事件的实现可以减少 kubelet 对节点资源的消耗。 |
| 29 | +你可以将这个特性称为**事件驱动的 Pod 生命周期事件生成器 (PLEG)**。 |
| 30 | +这是在 Kubernetes 项目内部针对关键实现细节所用的名称。 |
| 31 | + |
| 32 | +基于轮询的方法称为**通用 PLEG**。 |
| 33 | + |
| 34 | +## {{% heading "prerequisites" %}} |
| 35 | + |
| 36 | +<!-- |
| 37 | +* You need to run a version of Kubernetes that provides this feature. |
| 38 | + Kubernetes v1.27 includes beta support for event-based container |
| 39 | + status updates. The feature is beta but is _disabled_ by default |
| 40 | + because it requires support from the container runtime. |
| 41 | +* {{< version-check >}} |
| 42 | + If you are running a different version of Kubernetes, check the documentation for that release. |
| 43 | +--> |
| 44 | +* 你需要运行提供此特性的 Kubernetes 版本。 |
| 45 | + Kubernetes 1.27 提供了对基于事件更新容器状态的 Beta 支持。 |
| 46 | + 此特性处于 Beta 阶段,默认被**禁用**。 |
| 47 | +* {{< version-check >}} |
| 48 | + 如果你正在运行不同版本的 Kubernetes,请查阅对应版本的文档。 |
| 49 | +<!-- |
| 50 | +* The container runtime in use must support container lifecycle events. |
| 51 | + The kubelet automatically switches back to the legacy generic PLEG |
| 52 | + mechanism if the container runtime does not announce support for |
| 53 | + container lifecycle events, even if you have this feature gate enabled. |
| 54 | +--> |
| 55 | +* 所使用的容器运行时必须支持容器生命周期事件。 |
| 56 | + 如果容器运行时未声明对容器生命周期事件的支持,即使你已启用了此特性门控, |
| 57 | + kubelet 也会自动切换回传统的通用 PLEG。 |
| 58 | + |
| 59 | +<!-- steps --> |
| 60 | + |
| 61 | +<!-- |
| 62 | +## Why switch to Evented PLEG? |
| 63 | +
|
| 64 | +* The _Generic PLEG_ incurs non-negligible overhead due to frequent polling of container statuses. |
| 65 | +* This overhead is exacerbated by kubelet's parallelized polling of container states, thus limiting |
| 66 | + its scalability and causing poor performance and reliability problems. |
| 67 | +* The goal of _Evented PLEG_ is to reduce unnecessary work during inactivity |
| 68 | + by replacing periodic polling. |
| 69 | +--> |
| 70 | +## 为什么要切换到事件驱动的 PLEG? {#why-switch-to-evented-pleg} |
| 71 | + |
| 72 | +* **通用 PLEG** 由于频繁轮询容器状态而产生了不可忽略的开销。 |
| 73 | +* 这种开销会被 kubelet 的并行轮询容器状态的机制加剧, |
| 74 | + 限制了可扩缩性,还会导致性能和可靠性问题。 |
| 75 | +* **事件驱动的 PLEG** 的目标是通过替换定期轮询来减少闲置时的非必要任务。 |
| 76 | + |
| 77 | +<!-- |
| 78 | +## Switching to Evented PLEG |
| 79 | +
|
| 80 | +1. Start the kubelet with the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) |
| 81 | + `EventedPLEG` enabled. You can manage the kubelet feature gates editing the kubelet |
| 82 | + [config file](/docs/tasks/administer-cluster/kubelet-config-file/) and restarting the kubelet service. |
| 83 | + You need to do this on each node where you are using this feature. |
| 84 | +--> |
| 85 | +## 切换为事件驱动的 PLEG {#switching-to-evented-pleg} |
| 86 | + |
| 87 | +1. 启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) |
| 88 | + `EventedPLEG` 后启动 kubelet。 |
| 89 | + 你可以通过编辑 kubelet [配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)并重启 |
| 90 | + kubelet 服务来管理 kubelet 特性门控。 |
| 91 | + 你需要在使用此特性的所有节点上执行此操作。 |
| 92 | + |
| 93 | +<!-- |
| 94 | +2. Make sure the node is [drained](/docs/tasks/administer-cluster/safely-drain-node/) before proceeding. |
| 95 | +
|
| 96 | +3. Start the container runtime with the container event generation enabled. |
| 97 | +--> |
| 98 | +2. 确保节点被[腾空](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)后再继续。 |
| 99 | + |
| 100 | +3. 启用容器事件生成后启动容器运行时。 |
| 101 | + |
| 102 | + {{< tabs name="tab_with_code" >}} |
| 103 | + |
| 104 | + {{% tab name="containerd" %}} |
| 105 | + <!-- |
| 106 | + Version 1.7+ |
| 107 | + --> |
| 108 | + 版本 1.7+ |
| 109 | + |
| 110 | + {{% /tab %}} |
| 111 | + |
| 112 | + {{% tab name="CRI-O" %}} |
| 113 | + <!-- |
| 114 | + Version 1.26+ |
| 115 | + |
| 116 | + Check if the CRI-O is already configured to emit CRI events by verifying the configuration, |
| 117 | + --> |
| 118 | + 版本 1.26+ |
| 119 | + |
| 120 | + 通过验证配置,检查 CRI-O 是否已配置为发送 CRI 事件: |
| 121 | + |
| 122 | + ```shell |
| 123 | + crio config | grep enable_pod_events |
| 124 | + ``` |
| 125 | + |
| 126 | + <!-- |
| 127 | + If it is enabled, the output should be similar to the following: |
| 128 | + --> |
| 129 | + 如果已启用,输出应类似于: |
| 130 | + |
| 131 | + ```none |
| 132 | + enable_pod_events = true |
| 133 | + ``` |
| 134 | + |
| 135 | + <!-- |
| 136 | + To enable it, start the CRI-O daemon with the flag `--enable-pod-events=true` or |
| 137 | + use a dropin config with the following lines: |
| 138 | + --> |
| 139 | + 要启用它,可使用 `--enable-pod-events=true` 标志或添加以下配置来启动 CRI-O 守护进程: |
| 140 | + |
| 141 | + ```toml |
| 142 | + [crio.runtime] |
| 143 | + enable_pod_events: true |
| 144 | + ``` |
| 145 | + |
| 146 | + {{% /tab %}} |
| 147 | + {{< /tabs >}} |
| 148 | + |
| 149 | + {{< version-check >}} |
| 150 | + |
| 151 | +<!-- |
| 152 | +4. Verify that the kubelet is using event-based container stage change monitoring. |
| 153 | + To check, look for the term `EventedPLEG` in the kubelet logs. |
| 154 | +
|
| 155 | + The output should be similar to this: |
| 156 | +--> |
| 157 | +4. 确认 kubelet 正使用基于事件的容器阶段变更监控。 |
| 158 | + 要检查这一点,可在 kubelet 日志中查找 `EventedPLEG` 词条。 |
| 159 | + |
| 160 | + 输出类似于: |
| 161 | + |
| 162 | + ```console |
| 163 | + I0314 11:10:13.909915 1105457 feature_gate.go:249] feature gates: &{map[EventedPLEG:true]} |
| 164 | + ``` |
| 165 | + |
| 166 | + <!-- |
| 167 | + If you have set `--v` to 4 and above, you might see more entries that indicate |
| 168 | + that the kubelet is using event-based container state monitoring. |
| 169 | + --> |
| 170 | + 如果你将 `--v` 设置为 4 及更高值,你可能会看到更多条目表明 |
| 171 | + kubelet 正在使用基于事件的容器状态监控。 |
| 172 | + |
| 173 | + ```console |
| 174 | + I0314 11:12:42.009542 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=3b2c6172-b112-447a-ba96-94e7022912dc |
| 175 | + I0314 11:12:44.623326 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40 |
| 176 | + I0314 11:12:44.714564 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40 |
| 177 | + ``` |
| 178 | + |
| 179 | +## {{% heading "whatsnext" %}} |
| 180 | + |
| 181 | +<!-- |
| 182 | +* Learn more about the design in the Kubernetes Enhancement Proposal (KEP): |
| 183 | + [kubelet Evented PLEG for Better Performance](https://github.com/kubernetes/enhancements/blob/5b258a990adabc2ffdc9d84581ea6ed696f7ce6c/keps/sig-node/3386-kubelet-evented-pleg/README.md). |
| 184 | +--> |
| 185 | +* 进一步了解 Kubernetes 增强提案 (KEP): |
| 186 | + [kubelet Evented PLEG for Better Performance](https://github.com/kubernetes/enhancements/blob/5b258a990adabc2ffdc9d84581ea6ed696f7ce6c/keps/sig-node/3386-kubelet-evented-pleg/README.md) |
| 187 | + 中的设计理念。 |
0 commit comments