{"id":550,"date":"2025-06-03T07:40:00","date_gmt":"2025-06-03T07:40:00","guid":{"rendered":"https:\/\/blog.ngocha.biz\/?p=550"},"modified":"2025-06-03T07:40:00","modified_gmt":"2025-06-03T07:40:00","slug":"kubernetes-init-containers","status":"publish","type":"post","link":"https:\/\/blog.ngocha.biz\/?p=550","title":{"rendered":"Understanding Kubernetes Init Containers: A Complete Guide"},"content":{"rendered":"

In this blog post, we will dive deep into Kubernetes Init Containers<\/strong>. We’ll explore what they are, how they work, and what benefits they bring to containerized applications.<\/p>\n

This is a complete guide to Init Container.<\/p>\n

In the world of container orchestration, Kubernetes<\/a> has emerged as a solution for managing and scaling containerized applications. It provides a robust framework for automating containers’ deployment, scaling, and management across a cluster of nodes. One of the best features of Kubernetes is Init Containers.<\/strong><\/p>\n

Let’s get started<\/p>\n

What is an Init Container?<\/h2>\n

Kubernetes pods<\/a> can have more than one container. These containers in a pod work together to achieve a common goal.<\/p>\n

Init Containers are containers that start and run to completion<\/strong> before starting the main containers in the pod. It acts as a preparatory step, allowing us to perform initialization tasks, configure prerequisites, or configure dependencies required by the application in the main containers.<\/p>\n

\"Kubernetes<\/figure>\n

Let’s understand this with an example.<\/p>\n

Let’s say we have an application that needs a secret to connect to an API. You can’t hardcode this secret into the application or use Kubernetes secrets due to compliance reasons. In this case, you can use an init container<\/strong> to fetch the secret from a secret management service like Vault or AWS Secrets Manager and write it to a location in the pod where the application container can access it.<\/p>\n

\"init<\/figure>\n

This way when the application pod starts, it will have access to the secret to connect to the API.<\/p>\n

To put it simply, init containers can ensure your applications are always properly configured and initialized<\/strong> before they are started.<\/p>\n

How Init Containers Work?<\/h2>\n

Before we deep dive into init containers, let\u2019s understand how they work.<\/p>\n

    \n
  1. kubelet<\/code> runs the init containers in the order they appear in the Pod’s spec ensuring that each container completes its task before starting the next. Meaning only one init container runs at a time, this is also known as the startup order.<\/li>\n
  2. Init Containers run before the main application containers start.<\/li>\n
  3. If the Pod is restarted, all its init containers will run again.<\/li>\n
  4. In the pods lifecycle<\/a>, init containers run to completion in the pending phase.<\/li>\n
  5. Although init containers share the same container specification, they do not support the lifecycle, livenessProbe, readinessProbe, and startupProbe fields. (except for the native sidecar alpha feature)<\/li>\n<\/ol>\n

    Here is the animated image that shows how init containers work.<\/p>\n

    \"workflow
    Click to view in HD<\/span><\/figcaption><\/figure>\n

    Init Container Use Cases<\/h2>\n

    The actual use case of an init container may vary depending on the specific needs of your application. Here are some common use cases:<\/p>\n

      \n
    1. Load and Configure Dependencies<\/strong>:: Init containers can load and configure dependencies needed by the main application container before it starts running.<\/li>\n
    2. Create Database Schema<\/strong>: You can use the init container to create a database schema.<\/li>\n
    3. Warm Up Cache<\/strong>: You can warm up a cache using the init container. For example, preloading some frequently used data into the Redis cache.<\/li>\n
    4. Network Configuration<\/strong>: Init containers can handle tasks such as establishing network configuration or establishing connections to external services.<\/li>\n
    5. Git Clone<\/strong>: Init containers can clone Git repositories or write files into attached pod volumes.<\/li>\n
    6. Security Checks<\/strong>: Init containers can perform security checks, such as vulnerability scanning or TLS certificate verification, before starting the main application container.<\/li>\n
    7. Access to Secrets<\/strong>: Init containers have access to Secrets that application containers cannot, such as retrieving secrets from a vault<\/a>.<\/li>\n
    8. Environment Setup<\/strong>:: Init containers can handle tasks such as creating directories, applying permissions, or running custom scripts to set up the environment for the main application.<\/li>\n
    9. Wait for Services<\/strong>:: Init containers can wait for a service to start before the main application starts.<\/li>\n<\/ol>\n

      Init Container Practical Example<\/h2>\n

      Init containers are defined in the spec.initContainers<\/code> field of a Pod\u2019s manifest. This is similar to a regular spec.containers<\/code> definition. We can define as many containers under initContainers<\/code> section.<\/p>\n

      Let’s look at a practical example. Here is our user case. We need a Nginx web server pod that shows the Pod IP on the index page.<\/p>\n

      Here is how we can utilize init containers to deploy the pod displaying its IP address.<\/p>\n

        \n
      1. One init container named write-ip<\/strong> gets the pod IP using the MY_POD_IP<\/strong> env variable populated from the Pod’s own status. and writes to an ip.txt<\/strong> file inside the \/web-content volume attached to the pod.<\/li>\n
      2. The second init container named create-html<\/strong> reads the pod IP from \/web-content\/ip.tx<\/strong>t file that contains the pod IP created by the first init container and writes it to \/web-content\/index.html file.<\/li>\n
      3. Now, the main nginx container (web-container) mounts the default \/usr\/share\/nginx\/html <\/strong>to \/web-content volume where we have the index.html<\/strong> file.<\/li>\n<\/ol>\n

        Here is the full Pod YAML file for our use case. Save it as init-container.yaml<\/code><\/strong><\/p>\n

        apiVersion: v1\nkind: Pod\nmetadata:\n  name: web-server-pod\nspec:\n  initContainers:\n  - name: write-ip\n    image: busybox\n    command: [\"sh\", \"-c\", \"echo $MY_POD_IP > \/web-content\/ip.txt; echo 'Wrote the Pod IP to ip.txt'\"]\n    env:\n    - name: MY_POD_IP\n      valueFrom:\n        fieldRef:\n          fieldPath: status.podIP\n    volumeMounts:\n    - name: web-content\n      mountPath: \/web-content\n  - name: create-html\n    image: busybox\n    command: [\"sh\", \"-c\", \"echo 'Hello, World! Your Pod IP is: ' > \/web-content\/index.html; cat \/web-content\/ip.txt >> \/web-content\/index.html; echo 'Created index.html with the Pod IP'\"]\n    volumeMounts:\n    - name: web-content\n      mountPath: \/web-content\n  containers:\n  - name: web-container\n    image: nginx\n    volumeMounts:\n    - name: web-content\n      mountPath: \/usr\/share\/nginx\/html\n  volumes:\n  - name: web-content\n    emptyDir: {}<\/code><\/pre>\n
        Let’s deploy this pod.<\/p>\n
        kubectl apply -f init-container.yaml<\/code><\/pre>\n
        Now if you get the pod status, you will see 1\/1 container running<\/p>\n
        $ kubectl get pods\n\nNAME             READY   STATUS    RESTARTS   AGE\nweb-server-pod   1\/1     Running   0          22s<\/code><\/pre>\n
        We had three containers in the pod but only one is in running state. This is because as we discussed before init contianers run to completion. In this case two init contianers created the nginx index HTML page and exited with non-zero exit codes and then the main nginx contianer started running with the custom html page.<\/p>\n
        Even though the init containers are not running, we can check the completed container logs. We have added a simple echo command to both the init containers. Let’s check the init container logs and see if it has executed successfully.<\/p>\n
        As you can see both init containers have executed successfully and shows the echoed message in the logs.<\/p>\n
        $ kubectl logs web-server-pod -c write-ip   \nWrote the Pod IP to ip.txt\n\n$ kubectl logs web-server-pod -c create-html\nCreated index.html with the Pod IP<\/code><\/pre>\n
        Now, to verify if the Nginx pod is using the custom HTML, lets access the Nginx pod using port forwarding<\/p>\n
        kubectl port-forward pod\/web-server-pod 8080:80<\/code><\/pre>\n
        Now, if you try to access the Nginx app on localhost:8080 from your workstation, you can see the Nginx index page displaying a message with the Pod IP address as shown in the image below.<\/p>\n
        \"\"<\/figure>\n
        Adding CPU\/Memory Resources<\/h2>\n
        Init containers require CPU and memory resources to run to complete the specific tasks. The limits and requests can be set up based on the criticality of the tasks.<\/p>\n
        If there are several init containers the highest values set<\/strong> for any init container is called the effective init request\/limit<\/strong>. Meaning, that if you have an init container without a CPU\/Memory limit set, it can use the maximum of the effective init request\/limit<\/strong>.<\/p>\n
        We can specify CPU and memory resource limits and requests for Init Containers using Kubernetes resource specifications like below:<\/p>\n
        spec:\n  initContainers:\n    - name: init-container\n      image: init-container-image\n      resources:\n        requests:\n          cpu: 50m\n          memory: 64Mi\n        limits:\n          cpu: 100m\n          memory: 128Mi<\/code><\/pre>\n
        Monitoring and adjusting resource limits based on the actual usage patterns of Init Containers is a good practice to optimize the cluster’s resource allocation. However, we have to ensure that the sum of resources requested by Init Containers and main containers<\/strong> does not exceed the available resources on cluster nodes.<\/p>\n
        Adding Volumes<\/h3>\n
        Volumes in Init Containers play a crucial role in performing data setup, initialization, and preparation tasks before the main application containers start running. We can mount volumes in Init containers in the same way.<\/p>\n
        For example, sometimes application may require access to a dataset or files that we don’t want to bundle within the container image due to size constraints. In this case, an Init Container can be used to fetch and load these datasets into a shared volume and further, this volume can be used by the main container. Below is the example YAML file:<\/p>\n
        apiVersion: v1\nkind: Pod\nmetadata:\n  name: volume-example-pod\nspec:\n  initContainers:\n    - name: download-dataset\n      image: busybox\n      command: [\"wget\", \"-O\", \"\/data\/dataset.zip\", \"https:\/\/example.com\/dataset.zip\"]\n      volumeMounts:\n        - name: data-volume\n          mountPath: \/data\n    - name: unzip-dataset\n      image: busybox\n      command: [\"unzip\", \"\/data\/dataset.zip\", \"-d\", \"\/data\"]\n      volumeMounts:\n        - name: data-volume\n          mountPath: \/data\n  containers:\n    - name: main-app\n      image: main-app-image\n      volumeMounts:\n        - name: data-volume\n          mountPath: \/app-data\n  volumes:\n    - name: data-volume\n      emptyDir: {}<\/code><\/pre>\n
        Native Sidecars Using Init Containers<\/h2>\n
        \n
        \ud83d\udca1<\/div>\n
        In Kubernetes 1.28, native sidecar support was introduced using init containers with a new restartPolicy<\/code> field set to Always<\/code>.<\/p>\n
        As of Kubernetes 1.33, native sidecars are now a stable feature.<\/p><\/div>\n<\/div>\n
        Native Sidecar functionality relies on the concept of the “persistent init container<\/strong>,” where the initialization process starts with an init container and leverages the restartPolicy<\/code> to empower the capabilities of the sidecar container. <\/p>\n
        It starts before the main containers and keeps running for the entire duration of the Pod’s lifecycle<\/a>.<\/p>\n
        So to make an init container a sidecar, we need to add the \"restartPolicy: Always\"<\/code> attribute to its spec. It’s an optional field, if the restartPolicy<\/code> is not there the container will act as a regular init container.<\/p>\n
        Now let’s look at a practical example with a use case.<\/p>\n
        Let’s assume the following scenario<\/p>\n
          \n
        1. An nginx web server pod with an nginx main container that writes logs to \/var\/log\/nginx<\/strong> volume mount.<\/li>\n
        2. We need a native sidecar fluentd<\/strong> logging agent container that reads all the nginx logs from \/var\/log\/nginx.<\/li>\n<\/ol>\n
          Here is the Pod YAML for the above use case. The nginx-logs<\/code><\/strong> volume mount is common for the logging-agent sidecar container and nginx main container. The restartPolicy: Always<\/strong> is added to the logging-agent init container to make it behave like a sidecar container.<\/p>\n
          apiVersion: v1\nkind: Pod\nmetadata:\n  name: webserver-pod\nspec:\n  initContainers:\n  - name: logging-agent\n    image: fluentd:latest\n    restartPolicy: Always\n    volumeMounts:\n    - name: nginx-logs\n      mountPath: \/var\/log\/nginx\n  containers:\n  - name: nginx\n    image: nginx:1.14.2\n    ports:\n    - containerPort: 80\n    volumeMounts:\n    - name: nginx-logs\n      mountPath: \/var\/log\/nginx\n  volumes:\n  - name: nginx-logs\n    emptyDir: {}\n<\/code><\/pre>\n
          To test it, save it as sidecar.yaml<\/strong> and deploy it using kubectl.<\/p>\n
          kubectl apply -f sidecar.yaml<\/code><\/pre>\n
          Now if you check the pod status, you can use 2\/2 contianers are in running status. One is the native sidecar init container and the other one is the main Nginx container.<\/p>\n
          \"\"<\/figure>\n
          Overall, the native sidecar containers have the following key properties:<\/p>\n
            \n
          1. Dedicated lifecycle:<\/strong> Native Sidecar containers have a dedicated lifecycle which is independent of the lifecycle of the main containers in the Pod<\/li>\n
          2. It doesn’t block the Pod’s termination as non-native sidecars do.<\/li>\n
          3. Lifecycle Handlers and Probes<\/strong>: We can add PostStart and PreStop lifecycle handlers and probes (startup, readiness, liveness) to ensure sidecar readiness & pod readiness.<\/li>\n<\/ol>\n
            Comprehensive Init Container YAML<\/h2>\n
            Let’s see what an Init Container object YAML file looks like if we add all the supported parameters. To get information on all the supported fields you can use the following kubectl command.<\/p>\n
            kubectl explain pod.spec.initContainers<\/code><\/pre>\n
            Below is the comprehensive Init Container YAML.<\/p>\n
            spec:\n  initContainers:\n  - name: init-container\n    image: busybox:latest\n    command:\n    - \"sh\"\n    - \"-c\"\n    - \"echo Initializing... && sleep 5\"\n    imagePullPolicy: IfNotPresent\n    env:\n    - name: INIT_ENV_VAR\n      value: \"init-value\"\n    resources:\n      limits:\n        memory: \"128Mi\"\n        cpu: \"500m\"\n      requests:\n        memory: \"64Mi\"\n        cpu: \"250m\"\n    volumeMounts:\n    - name: init-container-volume\n      mountPath: \/init-data\n    ports:\n    - containerPort: 80\n    securityContext:\n      runAsUser: 1000\n      runAsGroup: 1000\n      capabilities:\n        add: [\"NET_ADMIN\"]\n    readinessProbe:\n      httpGet:\n        path: \/\n        port: 80\n      initialDelaySeconds: 5\n      periodSeconds: 10\n    livenessProbe:\n      httpGet:\n        path: \/\n        port: 80\n      initialDelaySeconds: 15\n      periodSeconds: 20\n    startupProbe:\n      httpGet:\n        path: \/\n        port: 80\n      initialDelaySeconds: 5\n      periodSeconds: 5\n    lifecycle:\n       postStart:\n         exec:\n           command: [\"\/bin\/sh\", \"-c\", \"echo 'PostStart'\"]\n       preStop:\n         exec:\n           command: [\"\/bin\/sh\", \"-c\", \"echo 'PreStop'\"]\n    restartPolicy: Always\n  volumes:\n  - name: init-container-volume\n    emptyDir: {}<\/code><\/pre>\n
            There are also other fields like workingDir, volumeDevices, resizePolicy<\/strong> related to init container volumes.<\/p>\n
            Init Container Functions<\/h2>\n
            The following are some of the key functions of the Init container<\/p>\n
              \n
            1. The Init containers will complete all the dependent tasks before starting the main container.<\/li>\n
            2. The temporary volume created by the Init container to store the configuration can be used as the persistent storage for the main container, even if the Init container task is completed. <\/li>\n
            3. For databases, the Init container can fetch and store all the schemas and tables, so that the database container can directly access them when it starts.<\/li>\n
            4. Init containers can ensure the external service availability before the main application starts to communicate with them. <\/li>\n<\/ol>\n
              Init Container Best Practices<\/h2>\n
              Below are some of the best practices to follow:<\/p>\n
                \n
              1. Ensure init containers are designed to do specific tasks quickly without using too many resources.<\/li>\n
              2. If you have multiple initialization tasks, use separate init containers for each task. This helps manage and troubleshoot them individually.<\/li>\n
              3. Init containers can fail, so plan for that. Implement retries, back-off strategies, and clear error messages to diagnose and resolve issues effectively.<\/li>\n
              4. Take advantage of the pre-run and post-run hooks provided by Kubernetes to run custom scripts or commands during specific phases of a container’s lifecycle.<\/li>\n
              5. Protect sensitive information used during initialization and avoid disclosure.<\/li>\n
              6. Make sure the init containers have enough resources allocated. A lack of resources can cause initialization tasks to fail or be delayed.<\/li>\n<\/ol>\n
                Init Container vs Sidecar Container<\/h2>\n
                  \n
                1. Init Container performs tasks that need to be completed before the main container can start while the Sidecar Container provides supplementary functionality to the main container.<\/li>\n
                2. Init Container doesn’t share the same network and storage resources as the main container while Sidecar Container shares the same.<\/li>\n
                3. Init Container executes sequentially and completes before the main container starts. On the other hand, the Sidecar Container starts, runs, and terminates alongside the main container.<\/li>\n
                4. The Init Container ensures that the main container starts with the necessary prerequisites while the Sidecar Container directly affects the behavior and functionality of the main container.<\/li>\n
                5. Init Containers can be used to set up the environment for the main application such as downloading configuration files or initializing shared volumes. Sidecar Containers can be used for tasks such as logging data to external systems, collecting metrics, or handling security-related functions.<\/li>\n<\/ol>\n
                  Init Containers FAQs<\/h2>\n
                  Let\u2019s look at some frequently asked questions based on Init Containers.<\/p>\n
                  What’s the difference between Init Containers and Regular Containers?<\/h4>\n
                  The main distinction between Init Containers and Regular Containers is their purpose and lifecycle. Init Containers focus on initialization tasks and ensuring readiness, while Regular Containers handle the core application logic and functionality.<\/p>\n
                  Can I have multiple init containers in a pod?<\/h4>\n
                  Yes, you can have multiple init containers in a pod. They execute sequentially, with each init container completing before the next one starts.<\/p>\n
                  What’s the difference between Init Containers and Sidecar Containers?<\/h4>\n
                  Init Containers focus on the initialization task of preparing the environment for the main container, while Sidecar Containers provide additional features and services that work with the main container to enhance its functionality throughout its lifetime.<\/p>\n
                  Conclusion<\/h2>\n
                  In this tutorial, we learned about init containers and their usage in Kubernetes Cluster nodes. We discussed the features and benefits. Further, we talked about its working and used cases.<\/p>\n
                  Also, the init container is an important topic for CKA certification<\/a>.<\/p>\n
                  If you are learning Kubernetes check out the Kubernetes learning roadmap<\/a> to deepen your Kubernetes knowledge.<\/p>\n
                  \n
                  Ngu\u1ed3n:<\/strong> Understanding Kubernetes Init Containers: A Complete Guide \u2014 DevOpsCube<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"
                  Source: https:\/\/devopscube.com\/kubernetes-init-containers\/<\/p>\n","protected":false},"author":1,"featured_media":551,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-550","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/550","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=550"}],"version-history":[{"count":0,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/posts\/550\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=\/wp\/v2\/media\/551"}],"wp:attachment":[{"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=550"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=550"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ngocha.biz\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=550"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}