3. CKA Storage

The storage in cka is mainly about the way how to store the data, as the container is used for execution, which means it not include the data storage part, therefore we need the storage for no mater share data or persistent data or any related stuffs as well as the structures to connect with the real disk.
First here are two concepts:

• Volume: dir/filesys in Pod, where container can get data from.
• Physical Store: where the data stored in the real word.

How to make this connection between volume and physical storage is the key point. In k8s we can either connect the volume with the local storage, or with external storage.

3.1 Volume Types and related Concepts

Before we talk about the workflow, here we need to give some basic concepts related to the storage, so that we can understand better for the workflow.

3.1.1 Volume Types

here we separate it into two categories,

1. Ephemeral volumes
2. Persistent volumes

"Ephemeral volume types have a lifetime of a pod, but persistent volumes exist beyond the lifetime of a pod."

3.1.1.1 Ephemeral volume

These volumes are typically tied to a single Pod or a node’s lifecycle.
Here we list several commonly used types:

1. emptyDir
   • Data: will lost when the Pod is deleted.
   • eg. temporary cache for web applications
2. hostPath
   • Data: will lost when Pods are rescheduled to a different node.
   • eg. log files

which means the data remains on the host node after the Pod is deleted, but if the Pod is rescheduled to a different node, the data won’t be accessible unless it’s tied to the same node.

# emptyDir
apiVersion: v1
kind: Pod
...
spec:
...
  volumes:
  - name: cache
    emptyDir: {}

# hostPath
apiVersion: v1
kind: Pod
...
spec:
  containers:
...
  volumes:
  - name: log
    hostPath:
      path: /path/to/the/log
      type: File

some types like configMap or secret, we will talk later in Config & Security. Other volume types can be checked here.

3.1.1.2 Persistent Volumes (PV)

1. local
   • local disk - high performance, low-latency
   • node specific
     • MUST have nodeAffinity field
   • don’t support shared access, general (RWO)
     • multiple Pods CAN'T writing to the same volume across nodes
   • eg. a database on a specific node.
2. nfs
   • external nfs server - slower
   • high availability
   • shared file access, ReadWriteMany (RWX)
     • multiple Pods CAN read/write the same data:
   • eg. shared configuration data across Pods.

# local
apiVersion: v1
kind: PersistentVolume
...
spec:
  capacity:            # match with PVC storage field
    storage: 100Gi
  accessModes:         # match with PVC accessModes field
    - ReadWriteOnce
  storageClassName: "local-storage"
  local:
    path: /STORE/PATH
  nodeAffinity:        # local MUST set nodeAffinity, as it's node specific
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node01

# nfs
apiVersion: v1
kind: PersistentVolume
...
spec:
  capacity:            # match with PVC storage field
    storage: 10Gi
  accessModes:         # match with PVC accessModes field
    - ReadWriteMany
  nfs:
    path: /SHARED/PATH
    server: HOST_IP

Note: here when using nfs, make sure nfs server has been installed on your computer. For Debian-based system (eg. ubuntu) install nfs-common; and for Redhat-based system (eg. CentOS) install nfs-utils.

3.1.1.3 hostPaht vs. local

Here hostPath and local seems kinda similar, but actually not.

1. Similarities:
   • Storage Location:
     • store data on the local disk of a specific node in the cluster.
   • No Cross-Node Sharing
2. Difference:
   • Management:
     • only local managed by k8s
   • Scheduling:
     • as pv, k8s automatically handles node affinity

more info can check PV doc.

3.1.2 PVC

Persistent Volume Claims (PVC), simply speaking is a connection between pvs and volumes. In the document, there is an interesting analogy between pvs and Pod.

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

In this aspect, we can take pvs as kinda consuming request for storage resource (PV). Similarly, for Pod, we can also treat it as consuming request for calculation resources.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-pvc
spec:
  accessModes:                      # match with PV accessModes
    - ReadWriteOnce
  storageClassName: local-storage   # sc
  resources:
    requests:
      storage: 50Gi                 # match with PV

more info refer to PVC.

3.1.3 StorageClass

StorageClass (sc), we can consider it as a "Factory Class", which dynamically provisioned PVs. Some points to remember:

1. if not specified, sc is default sc.
2. sc used for provision pv, according to pvc, via storageClassName field.(see above)
3. some items:
   • provisioner: "Production machine"
   • volumeBindingMode: when should we binding
     • when setting to WaitForFirstConsumer, until the consumer applied, this binding will be finished.
   • reclaimPolicy: how to recycle
   • allowVolumeExpansion: enlarge the volume (not shrink)
4. scenario: eg. many storage objects, and make it hard to manage, then use sc will be more easy.

3.1.3.1 How PV/PVC tie with sc

# pv
apiVersion: v1
kind: PersistentVolume
...
spec:
  ...
  storageClassName: <sc_name>
  ...

# pvc
apiVersion: v1
kind: PersistentVolumeClaim
...
spec:
  ...
  storageClassName: <sc_name>
  ...

3.2 PV/PVC Workflow

3.2.1 yaml

# PV
apiVersion: v1
kind: PersistentVolume
...
spec:
  capacity:                        # match with PVC storage field
    storage: 10Gi
  accessModes:                     # match with PVC accessModes field
    - ReadWriteMany
  nfs:
    path: /SHARED/PATH
    server: HOST_IP

---
# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: local-pvc
spec:
  accessModes:                     # match with PV accessModes
    - ReadWriteOnce
  storageClassName: <string>       # sc name
  resources:
    requests:
      storage: 10Gi                # match with PV

---
# Pod
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  volumes:
  - name: <string>             # meet with voumeMounts name below
    VOL_TYPE
  containers:
  - name:
    image:
      volumeMounts:
        - name: <string>       # keep same as above name
          mountPath: <string>      # mount dir
      ...

3.2.1 how PV/PVC works

• outdie the pod, create the PVC/PV, PV and PVC will binding according to 2 factors:
  1. capacity:
     • capacity(PV) >= storage(PVC)
  2. access right:
     • ReadWriteOnce (RWO)
     • ReadWriteMany (RWX)
     • ReadOnlyMany (ROX)
• inside the Pod, will create the Volume objects, and container mounts the volume.
• after all preparation, Pod can use the PV for storage.

"Pods access storage by using the claim as a volume. Claims must exist in the same namespace as the Pod using the claim."

more details can refer to the document claims as volume.

3.4 CKA

3.4.1 Domains for storage in CKA exam

In official site, we can see these 4 parts for storage:

1. Understand storage classes, persistent volumes
2. Understand volume mode, access modes and reclaim policies for volumes
3. Understand persistent volume claims primitive
4. Know how to configure applications with persistent storage

It takes up 10% of cka exam.

for config, we will put it at Config & Secret.

3.4.2 Necessary Points

And let's break it down and extract some points:

• Volume, volume types
• Persistent View (PV)
• Persistent View Claim (PVC)
• Storage Class (sc)