Sidecar container pattern in Kubernetes - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Purpose of Sidecar Containers in Kubernetes

What is the main purpose of using a sidecar container in a Kubernetes pod?

A To add auxiliary features like logging or proxying alongside the main container

B To replace the main container when it crashes

C To run a completely unrelated application in the same pod

D To increase the CPU resources available to the main container

💡 Hint

Think about how sidecar containers help the main container without replacing it.

Sidecar containers run alongside the main container to provide supporting features such as logging, monitoring, or proxying, enhancing the main container's functionality without replacing it.

💻 Command Output

intermediate

Output of Pod with Sidecar Containers

Given a pod with two containers: app and sidecar. The sidecar container writes logs to a shared volume. What will be the output of kubectl logs pod-name -c sidecar?

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: pod-name
spec:
  containers:
  - name: app
    image: busybox
    command: ['sh', '-c', 'echo Hello from app > /shared/log.txt; sleep 3600']
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  - name: sidecar
    image: busybox
    command: ['sh', '-c', 'tail -f /shared/log.txt']
    volumeMounts:
    - name: shared-data
      mountPath: /shared
  volumes:
  - name: shared-data
    emptyDir: {}

A Error: file /shared/log.txt not found

B No output, because the sidecar container does not write logs

C Hello from sidecar

D Hello from app

💡 Hint

Check which container writes to the shared file and which reads it.

The app container writes 'Hello from app' to the shared file. The sidecar container tails this file, so its logs show 'Hello from app'.

❓ Configuration

advanced

Correct Volume Sharing for Sidecar Pattern

Which container volume configuration correctly enables a sidecar container to share logs with the main container?

Kubernetes

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: main
    image: nginx
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
  - name: sidecar
    image: busybox
    volumeMounts:
    - name: log-volume
      mountPath: /var/log/nginx
  volumes:

A

volumes:
- name: log-volume
  emptyDir: {}

B

volumes:
- name: log-volume
  hostPath:
    path: /var/log/nginx
    type: Directory

C

volumes:
- name: log-volume
  persistentVolumeClaim:
    claimName: nginx-logs-pvc

D

volumes:
- name: log-volume
  configMap:
    name: nginx-logs-config

💡 Hint

Think about a temporary shared space inside the pod for logs.

emptyDir creates a temporary directory shared between containers in the pod, perfect for sharing logs between main and sidecar containers.

❓ Troubleshoot

advanced

Sidecar Container Crash Loop Issue

A sidecar container in a pod keeps restarting with the error: tail: cannot open '/shared/log.txt' for reading: No such file or directory. What is the most likely cause?

A The shared volume is not mounted in the sidecar container

B The sidecar container does not have permission to read the file

C The main container has not created the log file before the sidecar tries to read it

D The pod does not have enough CPU resources

💡 Hint

Consider the order in which containers start and access shared files.

The sidecar tries to read a file that the main container has not yet created, causing the error. The file must exist before tail can read it.

🔀 Workflow

expert

Sidecar Container Deployment Strategy

You want to deploy a sidecar container that automatically updates its configuration without restarting the main container. Which approach best supports this workflow?

A Store configuration inside the main container image

B Mount a ConfigMap as a volume in the sidecar container and watch for changes

C Use environment variables in the main container for configuration

D Restart the entire pod whenever the configuration changes

💡 Hint

Think about how Kubernetes ConfigMaps can be updated dynamically.

Mounting a ConfigMap as a volume allows the sidecar container to detect changes in configuration files without restarting the main container, enabling dynamic updates.