Kubernetes Volumes

The FROM statement starts out by creating a layer from the ubuntu:22.04 image.

The LABEL command only modifies the image’s metadata, and doesn’t produce a new layer.

The COPY command adds some files from your Docker client’s current directory.

The first RUN command builds your application using the make command, and writes the result to a new layer.

Finally, the CMD instruction specifies what command to run within the container, which only modifies the image’s metadata, which doesn’t produce an image layer.

Volumes are stored in a part of the host filesystem which is managed by Docker (/var/lib/docker/volumes/ on Linux). Non-Docker processes should not modify this part of the filesystem. Volumes are the best way to persist data in Docker.

Bind mounts may be stored anywhere on the host system. They may even be important system files or directories. Non-Docker processes on the Docker host or a Docker container can modify them at any time.

tmpfs mounts are stored in the host system’s memory only, and are never written to the host system’s filesystem.

A ConfigMap has data and binaryData fields that accept key-value pairs as their values.

When a ConfigMap currently consumed in a volume is updated, projected keys are eventually updated as well.

A ConfigMap can be created either using kubectl create configmap or a ConfigMap generator in kustomization.yaml.

$ kubectl create cm game-config --from-file configure-pod-container/configmap/
configmap/game-config created
$ kubectl get cm game-config -oyaml
apiVersion: v1
data:
  game.properties: |-
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice
kind: ConfigMap
metadata:
  creationTimestamp: "2025-02-26T06:27:24Z"
  name: game-config
  namespace: default
  resourceVersion: "373961"
  uid: fe6e6cf4-2d05-4152-af8f-b2563514d851

$ kubectl create cm game-config-2 \
    --from-env-file configure-pod-container/configmap/game.properties \
    --from-env-file configure-pod-container/configmap/ui.properties
configmap/game-config-2 created
$ kubectl get cm game-config-2 -oyaml
apiVersion: v1
data:
  allow.textmode: "true"
  color.bad: yellow
  color.good: purple
  enemies: aliens
  enemies.cheat: "true"
  enemies.cheat.level: noGoodRotten
  how.nice.to.look: fairlyNice
  lives: "3"
  secret.code.allowed: "true"
  secret.code.lives: "30"
  secret.code.passphrase: UUDDLRLRBABAS
kind: ConfigMap
metadata:
  creationTimestamp: "2025-02-26T06:29:05Z"
  name: game-config-2
  namespace: default
  resourceVersion: "374137"
  uid: a6094626-907f-412a-a2d1-5b3fdda225aa

$ kubectl create configmap special-config \
    --from-literal SPECIAL_LEVEL=very \
    --from-literal SPECIAL_TYPE=charm
configmap/special-config created
$ kubectl get cm special-config -oyaml
apiVersion: v1
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm
kind: ConfigMap
metadata:
  creationTimestamp: "2025-02-26T06:36:29Z"
  name: special-config
  namespace: default
  resourceVersion: "374899"
  uid: 4d194d31-5fe3-4255-8ee9-e951943d92db

Kubernetes offers built-in types for common scenarios, varying in validation and imposed constraints.

kubectl create secret generic empty-secret
kubectl get secret empty-secret

kubectl create secret docker-registry secret-tiger-docker \
  --docker-email=tiger@acme.example \
  --docker-username=tiger \
  --docker-password=pass1234 \
  --docker-server=my-registry.example:5000

kubectl create secret tls my-tls-secret \
  --cert=path/to/cert/file \
  --key=path/to/key/file

apiVersion: v1
kind: Pod
metadata:
  name: foo
  namespace: awesomeapps
spec:
  containers:
    - name: foo
      image: janedoe/awesomeapp:v1
  imagePullSecrets:
    - name: myregistrykey

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: dev.test
spec:
  rules:
  - host: dev.test
    http:
      paths:
      - backend:
          service:
            name: echoserver
            port:
              number: 80
        path: /
        pathType: ImplementationSpecific
  tls:
  - hosts:
    - '*.dev.test'
    secretName: dev.test

through a reference to a PersistentVolumeClaim

with a generic ephemeral volume

with a CSI ephemeral volume if the driver supports that

driver: A string value that specifies the name of the volume driver to use.

volumeHandle: A string value that uniquely identifies the volume.

readOnly: An optional boolean value indicating whether the volume is to be "ControllerPublished" (attached) as read only. Default is false.

fsType: If the PV’s VolumeMode is Filesystem then this field may be used to specify the filesystem that should be used to mount the volume.

volumeAttributes: A map of string to string that specifies static properties of a volume.

controllerPublishSecretRef: A reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI ControllerPublishVolume and ControllerUnpublishVolume calls.

nodeExpandSecretRef: A reference to the secret containing sensitive information to pass to the CSI driver to complete the CSI NodeExpandVolume call.

nodePublishSecretRef: A reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodePublishVolume call.

nodeStageSecretRef: A reference to the secret object containing sensitive information to pass to the CSI driver to complete the CSI NodeStageVolume call.

It is a resource in the cluster just like a node is a cluster resource, that captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system.

PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV.

Pods consume node resources and PVCs consume PV resources. Pods can request specific levels of resources (CPU and Memory).

Claims can request specific size and access modes (e.g., ReadWriteOnce, ReadOnlyMany, ReadWriteMany, or ReadWriteOncePod).

While PersistentVolumeClaims allow a user to consume abstract storage resources, it is common that users need PersistentVolumes with varying properties, such as performance, for different problems.

Each StorageClass contains the fields provisioner, parameters, and reclaimPolicy, which are used when a PersistentVolume belonging to the class needs to be dynamically provisioned to satisfy a PersistentVolumeClaim (PVC).

The name of a StorageClass object is significant, and is how users can request a particular class. Administrators set the name and other parameters of a class when first creating StorageClass objects.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer