nerdexam
Linux_Foundation

CKA · Question #4

Perform the following tasks: Add an init container to hungry-bear (which has been defined in spec file /opt/KUCC00108/pod-spec-KUCC00108.yaml) The init container should create an empty file named…

The task requires modifying a Kubernetes Pod YAML definition to include an init container that creates a specific file in a shared volume, and then applying this updated configuration to create the pod.

Submitted by obi.ng· May 4, 2026Workloads and Scheduling

Question

Perform the following tasks: Add an init container to hungry-bear (which has been defined in spec file /opt/KUCC00108/pod-spec-KUCC00108.yaml) The init container should create an empty file named /workdir/calm.txt If /workdir/calm.txt is not detected, the pod should exit Once the spec file has been updated with the init container definition, the pod should be created

Exhibit

CKA question #4 exhibit

Explanation

The task requires modifying a Kubernetes Pod YAML definition to include an init container that creates a specific file in a shared volume, and then applying this updated configuration to create the pod.

Approach. The correct approach involves a sequence of steps to modify the specified pod definition and then deploy it:

  1. Access the Pod Specification File: Since the user is root, they can directly edit the file. Open the YAML file using a text editor like vi or nano: vi /opt/KUCC00108/pod-spec-KUCC00108.yaml

  2. Add Volume Definition: Ensure a shared volume is defined within the spec section of the Pod, which both the init container and the main container can mount. An emptyDir volume is suitable for this temporary shared storage.

    spec:
      volumes:
        - name: workdir-volume
          emptyDir: {}
      # ... existing initContainers (if any) and containers
    
  3. Add Init Container Definition: Insert the initContainers section at the same level as containers within the spec section. The init container should:

    • Have a name (e.g., prepare-workdir).
    • Use a minimal image like busybox to perform the file creation.
    • Execute a command to touch /workdir/calm.txt.
    • mount the shared workdir-volume at /workdir.
    spec:
      # ... volumes section
      initContainers:
        - name: prepare-workdir
          image: busybox
          command: ["sh", "-c", "touch /workdir/calm.txt"]
          volumeMounts:
            - name: workdir-volume
              mountPath: /workdir
      # ... containers section
    
  4. Mount Volume in Main Container: Ensure the primary container(s) of the pod also mount the same workdir-volume at /workdir. This is crucial for the main application to 'detect' the calm.txt file.

    spec:
      # ... initContainers section
      containers:
        - name: hungry-bear # Or whatever the main container is named
          image: <your-image>
          volumeMounts:
            - name: workdir-volume
              mountPath: /workdir
          # ... other container properties
    
  5. Save the File: Save the changes to the YAML file (e.g., press Esc, then :wq in vi).

  6. Create the Pod: Use kubectl (or its alias k) to create the pod from the modified YAML file. Since the question says 'create the pod', k create is appropriate. If the pod might already exist and need an update, k apply would be more robust. k create -f /opt/KUCC00108/pod-spec-KUCC00108.yaml If create fails because the pod already exists, delete it first (k delete -f ...) then create, or use k apply -f ....

Common mistakes.

  • common_mistake. Common mistakes include:
  1. Forgetting Shared Volume: Not defining a shared volume and corresponding volumeMounts for both the init container and the main container. Without a shared volume, the file created by the init container would be lost once the init container completes, and the main container would not be able to 'detect' it.
  2. Incorrect YAML Syntax/Indentation: YAML is sensitive to indentation. Incorrect spacing can lead to parsing errors when applying the manifest.
  3. Wrong Image/Command for Init Container: Using an image that doesn't contain the sh shell or touch command, or specifying an incorrect command to create the file.
  4. Incorrect Placement of initContainers: Placing the initContainers section incorrectly in the YAML hierarchy (it must be under spec, at the same level as containers).
  5. Not Creating the Pod: Modifying the file but forgetting to apply the changes to the Kubernetes cluster using kubectl create or kubectl apply.
  6. Attempting to Create File in Main Container: While technically possible, creating the file in the main container's entrypoint or pre-start hook would not meet the implicit requirement that 'If /workdir/calm.txt is not detected, the pod should exit' (i.e., the main containers shouldn't even start if the file isn't present). Init containers are designed for such prerequisites.

Concept tested. The core technical concepts tested are Kubernetes Init Containers, their lifecycle and purpose (executing setup tasks before main containers), the use of shared volumes between init containers and main containers, Kubernetes Pod YAML manifest structure, and basic kubectl command-line operations for resource management.

Reference. https://kubernetes.io/docs/concepts/workloads/pods/init-containers/

Topics

#Init Containers#Pods#Workload Definition#Container Lifecycle

Community Discussion

No community discussion yet for this question.

Full CKA Practice