Shulou(Shulou.com)05/31 Report--

This article introduces the Init container in K8s, the content is very detailed, interested friends can use it for reference, I hope it can be helpful to you.

It is a dedicated container that runs before the application container starts and includes utilities and installation scripts that do not exist in the application image.

Pod can have multiple containers in which the application runs, but it may also have one or more Init containers that start before the application container.

Init containers are very similar to ordinary containers, except for the following two points:

They always run to completion.

Each must be completed successfully before the next startup.

If the Init container for Pod fails, Kubernetes restarts the Pod again and again until the Init container succeeds. However, if the restartPolicy value for Pod is Never, it will not restart.

To specify that the container is an Init container, you need to add an initContainers field to the PodSpec, in the form of an JSON array of objects of type v1.Container, and an array of containers of app. The status of the Init container is returned in the status.initContainerStatuses field in the format of an array of container states (similar to the status.containerStatuses field).

What's different from an ordinary container?

The Init container supports all the fields and features of the application container, including resource limits, data volumes, and security settings. However, the Init container handles resource requests and restrictions slightly differently, as described in the resources below. And the Init container does not support Readiness Probe because they must be run before the Pod is ready.

If multiple Init containers are specified for a Pod, those containers will run one at a time in sequence. Each Init container must run successfully before the next one can run. When all the Init containers are running, Kubernetes initializes the Pod and runs the application container as usual.

What can an Init container do?

Because Init containers have separate images from the application container, their startup-related code has the following advantages:

They can include and run utilities, and for security reasons, it is not recommended to include them in the application container image.

They can be installed using tools and customized code, but they cannot appear in the application image. For example, it is not necessary to FROM another image to create an image, just use a tool like sed, awk, python, or dig during installation.

Application images can separate the roles created and deployed, and there is no need to combine them to build a separate image.

They use Linux Namespace, so they have different file system views of the application container. Therefore, they can have access to the Secret, while the application container cannot.

They run before the application container starts, but the application container runs in parallel, so the Init container provides an easy way to block or delay the startup of the application container until a set of prerequisites are met.

So much for sharing the Init container in K8s. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.