Switching From Polling to CRI Event-based Updates to Container Status

This page shows how to migrate notes to use event based updates for container status. The event-based implementation reduces node resource consumption by the kubelet, compared to the legacy approach that relies on polling. You may know this feature as evented Pod lifecycle event generator (PLEG). That’s the name used internally within the Kubernetes project for a key implementation detail.

• You need to run a version of Kubernetes that provides this feature. Kubernetes 1.27 includes beta support for event-based container status updates. The feature is beta and is disabled by default. Your Kubernetes server must be at or later than version 1.26. To check the version, enter kubectl version. If you are running a different version of Kubernetes, check the documentation for that release.

• The current Generic PLEG incurs non-negligible overhead due to frequent polling of container statuses.
• This overhead is exacerbated by Kubelet’s parallelism, limiting its scalability and causing poor performance and reliability problems.

1. Start the Kubelet with the EventedPLEG enabled. In Kubelet feature gates can be enabled by editing config file and restarting the Kubelet service.

3. Start the CRI Runtime with the support.

   • CRI-O

         Version 1.26+
         Check if the CRI-O is already configured to emit `CRI Events` by verifying the configuration,

```

Your Kubernetes server must be at or later than version 1.26. To check the version, enter .

1. The output is similar to this:

   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.

   I0314 11:12:42.009542 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=3b2c6172-b112-447a-ba96-94e7022912dc
   I0314 11:12:44.623326 1110177 evented.go:238] "Evented PLEG: Generated pod status from the received event" podUID=b3fba5ea-a8c5-4b76-8f43-481e17e8ec40
   

• Learn more about KEP 3386.