CKA Self-Study

Module 4

Broad Skills offers a wide range of open source technology consulting services

CONTACT US

CKA Self-Study Mod 4

In this module of the Broad Skills online CKA prep course we will be covering the cluster architecture, installation, and configuration topics identified by the CNCF CKA Exam Curriculum. If you are not already familiar with the curriculum, take a moment to familiarize yourself, as you will be required to know each of the topics in order to pass the test.

cka self study modules

Understanding Kubernetes Storage Objects

Volumes are the primary way to configure storage for apps running under Kubernetes. Volumes are declared at the pod level, then mounted at the container level, as shown below:

apiVersion: v1

kind: Pod

metadata:

  name: cka-volumes

spec:

  restartPolicy: OnFailure

  containers:

  - name: cka-volume

  image: alpine

  command:

  - top

  volumeMounts:

  - name: applogs

  mountPath: /logs

  volumes:

  - name: applogs

  hostPath:

  path: /tmp/app/logs


Most volume lifespans are tied to the pods they are configured for, and usually expire when the pod is removed. To decouple storage from pod lifecycles, Kubernetes has PersistentVolume objects. PersistentVolumes are resources within the cluster that provide storage that persists outside of pod lifespans.

$ kubectl get pv


NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE

app-log-pv 1Gi RWO,ROX Retain Bound default/app-log-pvc 89m

fivegigpv 5Gi RWO Retain Available 78m


$ 

Pods may use PersistentVolumes (PVs) directly, but another way to use PVs are through PersistentVolumeClaims (PVCs). PVCs are abstract requests for storage that claim persistent volumes. If a PVC finds an existing PV that fulfills its requests (access mode and capacity), then that PV is bound to the PVC. PVCs can also describe PVs as templates that dynamically provision PVs from the desired specifications.

$ kubectl get pvc


NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE

app-log-pvc Bound app-log-pv 1Gi RWO,ROX 85m


$

StorageClasses allow PVCs to dynamically provision PVs. Each StorageClass object uses a plugin specific to a storage provider’s backend to create a new PV. The example below shows a basic gp2 StorageClass for AWS:

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: mod4-aws-storageclass

provisioner: kubernetes.io/aws-ebs

parameters:

  type: gp2

Persistent Volumes

A persistent volume is a storage object provisioned from the cluster’s infrastructure that is managed by the Kubernetes cluster. Persistent volumes allow storage to remain beyond an individual pod’s lifespan. Persistent volumes describe details of a storage implementation for the cluster, including:

  • Access modes for the volume
  • The total capacity of the volume
  • What happens to the data after the volume is unclaimed
  • The type of storage
  • An optional, custom storage class identifier


The following example shows a statically provisioned persistent volume. This volume is bound to the host’s filesystem at /tmp/pvc and claims 50 gigabytes of storage.

apiVersion: v1

kind: PersistentVolume

metadata:

  name: fivegigpv

spec:

  capacity:

  storage: 5Gi

  accessModes:

  - ReadWriteOnce

  persistentVolumeReclaimPolicy: Retain

  hostPath:

  path: /tmp/pvc

PersistentVolumes exist as resources in the cluster that any pod can claim using a standard volume mount or through a PersistentVolumeClaim.

Volume Access Modes

Persistent Volumes use the accesModes array to ensure that the resulting volume mounts in a way supported by the resource provider’s filesystem.

There are three access modes supported by Kubernetes:

  • ReadWriteOnce (RWO) – A single node may mount the volume with read-write permissions
  • ReadOnlyMany (ROX) – Many nodes may mount the volume with read-only permissions
  • ReadWriteMany (RWX) – Many nodes may mount the volume with read-write permissions

Below is an example of a PersistentVolume that allows ReadWriteOnce and ReadOnlyMany access modes

apiVersion: v1

kind: PersistentVolume

metadata:

  name: app-pv

spec:

  capacity:

  storage: 50Gi

  accessModes:

  - ReadWriteOnce

  - ReadOnlyMany

  persistentVolumeReclaimPolicy: Retain

  hostPath:

  path: "/app/logs"

Persistent Volume Claims

A PersistentVolumeClaim is a request for storage and is an abstraction of persistent volumes. PersistentVolumeClaims bind to PersistentVolumes on a number of factors like label selectors, storage class name, storage capacity, and access mode. PersistentVolumeClaims will bind to existing PersistentVolumes in the cluster that fulfill their requirements or dynamically create PersistentVolumes using an existing StorageClass.

Below is an example of a PersistentVolumeClaim that binds to the PersistentVolume example shown above:

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

  name: app-pvc

spec:

  accessModes:

  - ReadWriteOnce

  resources:

  requests:

  storage: 50Gi

The PersistentVolumeClaim must find a PersistentVolume with up to 50 gigabytes of storage and the ReadWriteOnce access mode in its manifest.

Configure Applications with Persistent Storage

The volumes array under a pod manifest and volumeMounts array in a container manifest configure how applications running under Kubernetes use persistent storage.


Entries under the volumes array in a pod manifest declare what storage plugins or objects a pod has available for its containers to use as storage. Certain volume types, PersistentVolumes, PersistentVolumeClaims, ConfigMaps and Secrets are all valid entries under the volumes array. Each volume entry is given a name.


Containers under pods use the volumeMounts array to mount any volumes made available by the pod. The container references the volume by the name configured on the pod level.

The example below shows a pod configured to expose a host directory and the PersistentVolumeClaim example above for its containers to use:

apiVersion: v1

kind: Pod

metadata:

  name: cka-volumes

spec:

  restartPolicy: OnFailure

  containers:

  - name: cka-volumes

  image: alpine

  command:

  - top

  volumeMounts:

  - name: app-logs

  mountPath: /logs

  - name: app-certs

  mountPath: /certs

  volumes:

  - name: app-logs

  persistentVolumeClaim:

  claimName: app-log-pvc

  - name: app-certs

  hostPath:

  path: /etc/ssl/certs

This example uses a PersistentVolumeClaim to store application log data and also mounts a hostPath to use certificates of its host.

practice drill

Create a pod that runs centos/httpd and stores its log directory at /var/log/httpd under /tmp/httpd/ on the host.

  • Practice Drill: Answer

    First, create a pod spec imperatively using kubectl run:


    $ kubectl run --restart Never --image centos/httpd --dry-run=client -o yaml mod4drillpod  > mod4drillpod.yaml


    $ 


    Then, add a hostPath entry under the volumes array of the pod spec:


    apiVersion: v1

    kind: Pod

    metadata:

      labels:

        run: mod4drillpod

      name: mod4drillpod

    spec:

      containers:

      - image: centos/httpd

        name: mod4drillpod

      volumes:

      - name: apache-logs

        hostPath:

          path: /tmp/httpd/


    Now add a volumeMounts array to the container spec that mounts the hostPath volume to /var/log/httpd:


    apiVersion: v1

    kind: Pod

    metadata:

      labels:

        run: mod4drillpod

      name: mod4drillpod

    spec:

      containers:

      - image: centos/httpd

        name: mod4drillpod

        volumeMounts:

        - name: apache-logs

          mountPath: /var/log/httpd

      volumes:

      - name: apache-logs

        hostPath:

          path: /tmp/httpd/


    Now create the pod:


    $ kubectl apply -f mod4drillpod.yaml

    pod/mod4drillpod created


    $


    And use ls to confirm that the volume mounted successfully:


    $ ls -l /tmp/httpd/


    total 4

    -rw-r--r-- 1 root root   0 Feb 27 10:44 access_log

    -rw-r--r-- 1 root root 767 Feb 27 10:44 error_log


    $


Courses

150+

Learners

50k+

Trainers

46

 Promotion Rate

90%

  • How We Are Responding to Covid-19

    In these trying times, Broad Skills remains fully operational. We are committed to the success of our clients and keeping the global economy moving. All of our courses and consulting services are available virtually and we stand ready to support the needs of our clients globally through distance learning and video conferencing.


    We will be bolstering our open enrollment calendar of courses to meet customer demand, however, for the health and safety of our clients and staff, existing open enrollment engagements will be moved to virtual delivery until conditions make in-person offerings suitable again.


We are experts in technology – providing a comprehensive suite of training services that

not only challenge your mind but also give you job required skills that put you in pole position to contribute largely success and growth of your organisation.

Stephen Brown

Instructor, BroadSkills

Share by: