Pass the Linux Foundation Kubernetes Administrator CKA Questions and answers with CertsForce

solution

Persistent Volume

A persistent volume is a piece of storage in a Kubernetes cluster. PersistentVolumes are a cluster-level resource like nodes, which don’t belong to any namespace. It is provisioned by the administrator and has a particular file size. This way, a developer deploying their app on Kubernetes need not know the underlying infrastructure. When the developer needs a certain amount of persistent storage for their application, the system administrator configures the cluster so that they consume the PersistentVolume provisioned in an easy way.

Creating Persistent Volume

kind: PersistentVolume

apiVersion: v1

metadata:

name:app-data

spec:

capacity: # defines the capacity of PV we are creating

storage: 2Gi #the amount of storage we are tying to claim

accessModes: # defines the rights of the volume we are creating

- ReadWriteMany

hostPath:

path: "/srv/app-data" # path to which we are creating the volume

Challenge

Create a Persistent Volume named app-data, with access mode ReadWriteMany, storage classname shared, 2Gi of storage capacity and the host path /srv/app-data.

2. Save the file and create the persistent volume.

Image for post

3. View the persistent volume.

Our persistent volume status is available meaning it is available and it has not been mounted yet. This status will change when we mount the persistentVolume to a persistentVolumeClaim.

PersistentVolumeClaim

In a real ecosystem, a system admin will create the PersistentVolume then a developer will create a PersistentVolumeClaim which will be referenced in a pod. A PersistentVolumeClaim is created by specifying the minimum size and the access mode they require from the persistentVolume.

Challenge

Create a Persistent Volume Claim that requests the Persistent Volume we had created above. The claim should request 2Gi. Ensure that the Persistent Volume Claim has the same storageClassName as the persistentVolume you had previously created.

kind: PersistentVolume

apiVersion: v1

metadata:

name:app-data

spec:

accessModes:

- ReadWriteMany

resources:

requests:

storage: 2Gi

storageClassName: shared

2. Save and create the pvc

njerry191@cloudshell:~ (extreme-clone-2654111)$ kubect1 create -f app-data.yaml

persistentvolumeclaim/app-data created

3. View the pvc

Image for post

4. Let’s see what has changed in the pv we had initially created.

Image for post

Our status has now changed from available to bound.

5. Create a new pod named myapp with image nginx that will be used to Mount the Persistent Volume Claim with the path /var/app/config.

Mounting a Claim

apiVersion: v1

kind: Pod

metadata:

creationTimestamp: null

name: app-data

spec:

volumes:

- name:congigpvc

persistenVolumeClaim:

claimName: app-data

containers:

- image: nginx

name: app

volumeMounts:

- mountPath: "/srv/app-data "

name: configpvc

Task Summary

You need to:

SSH into the correct node: cka000055

Use kubectl to list all cert-manager CRDs, and save that list to ~/resources.yaml

Do not use any output format flags like -o yaml

Extract the documentation for the spec.subject field of the Certificate custom resource and save it to ~/subject.yaml

Step-by-Step Instructions

Step 1: SSH into the node

ssh cka000055

Step 2: List cert-manager CRDs and save to a file

First, identify all cert-manager CRDs:

kubectl get crds | grep cert-manager

Then extract them without specifying an output format:

kubectl get crds | grep cert-manager | awk '{print $1}' | xargs kubectl get crd > ~/resources.yaml

This saves the default kubectl get output to the required file without formatting flags.

Step 3: Get documentation for spec.subject in the Certificate CRD

Run the following command:

kubectl explain certificate.spec.subject > ~/subject.yaml

This extracts the field documentation and saves it to the specified file.

If you're not sure of the resource, verify it exists:

kubectl get crd certificates.cert-manager.io

Final Command Summary

ssh cka000055

kubectl get crds | grep cert-manager | awk '{print $1}' | xargs kubectl get crd > ~/resources.yaml

kubectl explain certificate.spec.subject > ~/subject.yaml

solution

F:\Work\Data Entry Work\Data Entry\20200827\CKA\10 B.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\10 C.JPG

solution

F:\Work\Data Entry Work\Data Entry\20200827\CKA\11 B.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\11 C.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\11 D.JPG

Task Summary

SSH into the correct node: cka000049

Find the highest existing user-defined PriorityClass

Create a new PriorityClass high-priority with a value one less

Patch Deployment busybox-logger (in namespace priority) to use this new PriorityClass

Step-by-Step Solution

1️⃣ SSH into the correct node

bash

CopyEdit

ssh cka000049

⚠️ Skipping this = zero score

2️⃣ Find the highest existing user-defined PriorityClass

Run:

bash

CopyEdit

kubectl get priorityclasses.scheduling.k8s.io

Example output:

vbnet

CopyEdit

NAME VALUE GLOBALDEFAULT AGE

default-low 1000 false 10d

mid-tier 2000 false 7d

critical-pods 1000000 true 30d

Exclude system-defined classes like system-* and the default global one (e.g., critical-pods).

Let's assume the highest user-defined value is 2000.

So your new class should be:

Value = 1999

3️⃣ Create the high-priority PriorityClass

Create a file called high-priority.yaml:

cat < high-priority.yaml

apiVersion: scheduling.k8s.io/v1

kind: PriorityClass

metadata:

name: high-priority

value: 1999

globalDefault: false

description: "High priority class for user workloads"

EOF

Apply it:

kubectl apply -f high-priority.yaml

4️⃣ Patch the busybox-logger deployment

Now patch the existing Deployment in the priority namespace:

kubectl patch deployment busybox-logger -n priority \

--type='merge' \

-p '{"spec": {"template": {"spec": {"priorityClassName": "high-priority"}}}}'

5️⃣ Verify your work

Confirm the patch was applied:

kubectl get deployment busybox-logger -n priority -o jsonpath='{.spec.template.spec.priorityClassName}'

✅ You should see:

high-priority

Also, confirm the class exists:

kubectl get priorityclass high-priority

Final Command Summary

ssh cka000049

kubectl get priorityclass

# Create the new PriorityClass

cat < high-priority.yaml

apiVersion: scheduling.k8s.io/v1

kind: PriorityClass

metadata:

name: high-priority

value: 1999

globalDefault: false

description: "High priority class for user workloads"

EOF

kubectl apply -f high-priority.yaml

# Patch the deployment

kubectl patch deployment busybox-logger -n priority \

--type='merge' \

-p '{"spec": {"template": {"spec": {"priorityClassName": "high-priority"}}}}'

# Verify

kubectl get deployment busybox-logger -n priority -o jsonpath='{.spec.template.spec.priorityClassName}'

kubectl get priorityclass high-priority

kubectl get pods -o=jsonpath="{.items[*]['metadata.name'

, 'metadata.namespace']}"

kubectl get po -o=custom-columns="POD_NAME:.metadata.name,

POD_STATUS:.status.containerStatuses[].state"

solution

F:\Work\Data Entry Work\Data Entry\20200827\CKA\13 B.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\13 C.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\13 D.JPG

solution

F:\Work\Data Entry Work\Data Entry\20200827\CKA\7 B.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\7 C.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\7 D.JPG

solution

F:\Work\Data Entry Work\Data Entry\20200827\CKA\4 B.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\4 C.JPG

F:\Work\Data Entry Work\Data Entry\20200827\CKA\4 D.JPG