You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This page shows how to migrate notes to use event based updates for container status. The event-based
12
13
implementation reduces node resource consumption by the kubelet, compared to the legacy approach
13
14
that relies on polling.
14
15
You may know this feature as _evented Pod lifecycle event generator (PLEG)_. That's the name used
15
16
internally within the Kubernetes project for a key implementation detail.
16
17
17
-
18
18
## {{% heading "prerequisites" %}}
19
19
20
20
* You need to run a version of Kubernetes that provides this feature.
21
-
Kubernetes {{< skew currentVersion >}} includes beta support for event-based container
22
-
status updates. The feature is beta and is disabled by default.
23
-
{{< version-check >}}
24
-
If you are running a different version of Kubernetes, check the documentation for that release.
25
-
21
+
Kubernetes {{< skew currentVersion >}} includes beta support for event-based container
22
+
status updates. The feature is beta and is disabled by default.
23
+
{{< version-check >}}
24
+
If you are running a different version of Kubernetes, check the documentation for that release.
26
25
27
26
<!-- steps -->
28
27
29
28
## Why switch to Evented PLEG?
30
29
31
30
* The current `Generic PLEG` incurs non-negligible overhead due to frequent polling of container statuses.
32
-
* This overhead is exacerbated by Kubelet's parallelism, limiting its scalability and causing poor performance and reliability problems.
31
+
* This overhead is exacerbated by Kubelet's parallelism, limiting its scalability
32
+
and causing poor performance and reliability problems.
33
33
* The goal of `Evented PLEG` is to reduce unnecessary work during inactivity by replacing periodic polling.
34
34
35
35
## Switching to Evented PLEG
36
36
37
+
1. Start the Kubelet with the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/)
38
+
`EventedPLEG` enabled. In Kubelet feature gates can be enabled by editing
39
+
[config file](/docs/tasks/administer-cluster/kubelet-config-file/) and restarting the Kubelet service.
37
40
38
-
1. Start the Kubelet with the [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/)`EventedPLEG` enabled. In Kubelet feature gates can be enabled by editing [config file](https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/)and restarting the Kubelet service.
41
+
2. Please make sure the node is [drained](/docs/tasks/administer-cluster/safely-drain-node/)before proceeding.
39
42
40
-
2. Please make sure the node is [drained](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/) before proceeding.
43
+
3. Start the `CRI Runtime` with the `Evented PLEG` support.
41
44
42
-
3. Start the `CRI Runtime` with the `Evented PLEG` support.
43
-
{{< tabs name="tab_with_code" >}}
44
-
{{< tab name="Containerd" codelang="bash" >}}
45
-
Version 1.7+
46
-
{{< /tab >}}
47
-
{{< tab name="CRI-O" codelang="bash" >}}
48
-
Version 1.26+
49
-
50
-
Check if the CRI-O is already configured to emit `CRI Events` by verifying the configuration,
51
-
```
52
-
$ crio config | grep enable_pod_events
53
-
```
54
-
If its enabled it should show,
55
-
```
56
-
# enable_pod_events = true
57
-
```
45
+
{{< tabs name="tab_with_code" >}}
58
46
59
-
To enable it, start the cri-o daemon with the flag `--enable-pod-events=true` or using a drop in config like,
60
-
61
-
[crio.runtime]
62
-
enable_pod_events: true
63
-
47
+
{{% tab name="containerd" %}}
48
+
Version 1.7+
49
+
{{% /tab %}}
64
50
65
-
{{< /tab >}}
66
-
{{< /tabs >}}
51
+
{{% tab name="CRI-O" %}}
52
+
Version 1.26+
67
53
54
+
Check if the CRI-O is already configured to emit `CRI Events` by verifying the configuration:
68
55
69
-
{{< version-check >}}
56
+
```shell
57
+
crio config | grep enable_pod_events
58
+
```
70
59
71
-
4. Verify that `Evented PLEG` is in use by looking for the term `EventedPLEG` in the kubelet logs
If you have set LOG_LEVEL to 4 and above, you might see more entries that indicate `Evented PLEG` is in use by the kubelet.
79
-
80
-
```
81
-
I0314 11:12:42.009542 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=3b2c6172-b112-447a-ba96-94e7022912dc
82
-
I0314 11:12:44.623326 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40
83
-
I0314 11:12:44.714564 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40
84
-
```
66
+
To enable it, start the cri-o daemon with the flag `--enable-pod-events=true` or using a drop in config like:
85
67
86
-
## {{% heading "whatsnext" %}}
68
+
```
69
+
[crio.runtime]
70
+
enable_pod_events: true
71
+
```
72
+
73
+
{{% /tab %}}
74
+
{{< /tabs >}}
87
75
88
-
* Learn more about [KEP 3386](https://github.com/kubernetes/enhancements/blob/5b258a990adabc2ffdc9d84581ea6ed696f7ce6c/keps/sig-node/3386-kubelet-evented-pleg/README.md).
76
+
{{< version-check >}}
89
77
78
+
4. Verify that `Evented PLEG` is in use by looking for the term `EventedPLEG` in the kubelet logs.
0 commit comments