Container Communication Inside a Kubernetes Pod: Shared Volumes and IPC

Kubernetes provides Pods as a virtualization environment that can host one or more containers, and container‑to‑container communication inside a Pod is a key aspect of its networking model. Four networking models are mentioned: container‑to‑container, Pod‑to‑Pod, Pod‑to‑Service, and external‑to‑internal communication.

The article focuses on two primary methods for enabling communication between containers in the same Pod: shared volumes and inter‑process communication (IPC).

1. Shared Volume Communication

Using a shared emptyDir volume allows containers to exchange data via a common filesystem. The example defines a Pod named mc1 with an emptyDir volume called html . One container runs nginx and serves files from /usr/share/nginx/html , while a second container runs debian and appends the current date to /html/index.html every second.

apiVersion: v1
kind: Pod
metadata:  
 name: mc1
spec:  
volumes:  
- name: html    
  emptyDir: {}  
containers:  
- name: 1st    
  image: nginx    
  volumeMounts:    
  - name: html      
    mountPath: /usr/share/nginx/html  
- name: 2nd    
  image: debian    
  volumeMounts:    
  - name: html      
    mountPath: /html    
  command: ["/bin/sh", "-c"]    
  args:      
  - while true;        
    date >> /html/index.html;          
    sleep 1;        
    done

To verify the communication, the article shows kubectl exec commands that read the index.html file from both containers.

$ kubectl exec mc1 -c 1st -- /bin/cat /usr/share/nginx/html/index.html 
... 
$ kubectl exec mc1 -c 2nd -- /bin/cat /html/index.html 
...

2. Inter‑Process Communication (IPC)

Containers in a Pod share the same IPC namespace, allowing them to use standard IPC mechanisms such as SystemV semaphores or POSIX shared memory. The example defines a Pod named mc2 with two containers: a producer that writes messages to a Linux message queue and a consumer that reads from the same queue until a special “done” message is received. The Pod’s restartPolicy is set to Never so the Pod terminates after both containers finish.

apiVersion: v1
kind: Pod
metadata:  
 name: mc2
spec:  
  containers:  
  - name: producer   
    image: allingeek/ch6_ipc  
    command: ["./ipc", "-producer"]  
  - name: consumer   
    image: allingeek/ch6_ipc   
    command: ["./ipc", "-consumer"]  
restartPolicy: Never

Pod creation and status can be observed with:

$ kubectl get pods --show-all -w
NAME      READY  STATUS          RESTARTS  AGE
mc2       0/2    Pending         0        0s
mc2       0/2    ContainerCreating 0      0s
mc2       0/2    Completed       0        29

Logs from each container confirm that the consumer received all messages, including the termination signal:

$ kubectl logs mc2 -c producer
...
Produced: f4Produced: 1d
Produced: 9eProduced: 27
$ kubectl logs mc2 -c consumer
...
Consumed: f4
Consumed: 1d
Consumed: 9e
Consumed: 27
Consumed: done

Conclusion

Pods often host multiple containers to support side‑car patterns such as data extractors, pushers, or proxies. Shared volumes provide a simple way for containers to exchange files, though data is lost if the Pod is deleted. IPC offers an alternative for direct message passing. Understanding these mechanisms prepares readers for more advanced Kubernetes networking models like Pod‑to‑Pod and Pod‑to‑Service communication.