Initializers are dynamic runtime elements of the Kubernetes workflow that enable the modification of the resources before their actual creation. In other words, initializers allow developers to interfere with and make any changes to the resources,
such as deployments or pods, and include custom modification logic for the Kubernetes resource life cycle.

Some possible use cases of initializers are as follows:

• Injecting a sidecar container
• Injecting a volume with certificates
• Preventing the creation of some resources that violate custom limitations

Initializers are dynamic controllers, and they are defined or removed during runtime with InitializerConfiguration resources. InitializerConfiguration combines a set of resources and initializers so that when a matching resource is created, the API server adds the corresponding initializer to the resource definition.
The list of initializers are maintained in the metadata.initializers.pending field. On the other hand, initializers are always watching for the new resources so that they can implement their custom logic on the objects. When Initializer X is in the first slot, namely metadata.initializers.pending[0] , Initializer X gets the resource and modifiers. Then, it removes itself, Initializer X, from the metadata.initializers.pending list so that the next initializer will work. When all of the initializers complete their operations, and the list is empty, the resource is released and continues the creation life cycle.

Initializers are easy to develop, and they are an extremely flexible way of extending the admission control mechanism. However, the uptime of the initializers is critical since they will block the API server. In addition, initializers are not generally available and are still in development.