Kubernetes, with its robust architecture, is designed to manage containerized applications efficiently across a cluster of machines. While transitioning from Docker's straightforward composition capabilities, many developers confront the challenge of simulating features they have previously enjoyed, such as Docker Compose's --volumes-from. This option allows for the sharing of volumes between containers seamlessly. In Kubernetes, this requires a bit of manual configuration, though the platform provides powerful tools for achieving similar results. This article delves into how one can mimic Docker's --volumes-from functionality in Kubernetes, complete with technical explanations and examples.

Understanding Docker's --volumes-from

In a Docker setup, the --volumes-from option is a straightforward way to allow a new container to mount volumes from another container. This is often used when you want multiple containers to share data or configuration without explicitly defining volume paths for each.

For instance, in Docker you might use:

docker run --name container1 -v /shared-volume busybox
docker run --name container2 --volumes-from container1 busybox

Here, container2 automatically mounts the same volume as container1.

Mimicking --volumes-from in Kubernetes

Kubernetes handles volumes differently through its PersistentVolume (PV), PersistentVolumeClaim (PVC), and ConfigMap abstractions. These concepts allow for the sharing of storage across containers within a pod or across multiple pods.

Explanation and Example

1. Defining a Persistent Volume (PV): The PV is a resource in the cluster that represents a piece of storage. It can be backed by a physical disk, NFS, or a cloud provider's managed storage.

1   apiVersion: v1
2   kind: PersistentVolume
3   metadata:
4     name: shared-pv
5   spec:
6     capacity:
7       storage: 1Gi
8     accessModes:
9       - ReadWriteOnce
10     hostPath:
11       path: /data/shared

1. Claiming the Persistent Volume through a Persistent Volume Claim (PVC): PVC is a request for storage by a user. It is similar to a pod.

1   apiVersion: v1
2   kind: PersistentVolumeClaim
3   metadata:
4     name: shared-pvc
5   spec:
6     accessModes:
7       - ReadWriteOnce
8     resources:
9       requests:
10         storage: 1Gi

1. Configuring Pods to Use the PVC: Multiple pods can mount the same PVC, effectively sharing the data between the containers in those pods.

1   apiVersion: v1
2   kind: Pod
3   metadata:
4     name: pod1
5   spec:
6     containers:
7     - name: container1
8       image: busybox
9       volumeMounts:
10       - mountPath: "/data"
11         name: shared-storage
12     volumes:
13     - name: shared-storage
14       persistentVolumeClaim:
15         claimName: shared-pvc

1   apiVersion: v1
2   kind: Pod
3   metadata:
4     name: pod2
5   spec:
6     containers:
7     - name: container2
8       image: busybox
9       volumeMounts:
10       - mountPath: "/data"
11         name: shared-storage
12     volumes:
13     - name: shared-storage
14       persistentVolumeClaim:
15         claimName: shared-pvc

Summary Table

Additional Details

• Access Modes: The access modes for PV and PVC dictate how storage is accessed by the pods. The "ReadWriteOnce" mode allows the volume to be mounted as read-write by a single node. Other modes like "ReadOnlyMany" or "ReadWriteMany" can allow different sharing configurations.
• Flexibility with ConfigMap: Besides just sharing data volumes, one can also leverage ConfigMap and Secret for distributing configuration data and sensitive information between containers in a similar way.
• Storage Classes: Kubernetes supports StorageClass to provide dynamic provisioning of storage. This means you don’t have to manually create PVs as they will be allocated dynamically based on the specification in the StorageClass.

In conclusion, while Kubernetes does not have a direct equivalent of Docker's --volumes-from feature, with the effective use of its storage abstractions like PV, PVC, and ConfigMaps, you can achieve a similar functionality. This mimics the sharing of volumes between containers, fostering a more integrated and orchestrated container-based development environment.