CKA Certified Kubernetes Administrator (CKA) Program Questions and Answers

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

solution

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

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

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

F:\Work\Data Entry Work\Data Entry\20200827\CKA\3 E.JPG

A screen shot of a computer AI-generated content may be incorrect.

solution

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

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

F:\Work\Data Entry Work\Data Entry\20200827\CKA\20 E.JPG

Solution:

vi pvc.yaml

storageclass pvc

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: pv-volume

spec:

accessModes:

- ReadWriteOnce

volumeMode: Filesystem

resources:

requests:

storage: 10Mi

storageClassName: csi-hostpath-sc

# vi pod-pvc.yaml

apiVersion: v1

kind: Pod

metadata:

name: web-server

spec:

containers:

- name: web-server

image: nginx

volumeMounts:

- mountPath: "/usr/share/nginx/html"

name: my-volume

volumes:

- name: my-volume

persistentVolumeClaim:

claimName: pv-volume

# craete

kubectl create -f pod-pvc.yaml

#edit

kubectl edit pvc pv-volume --record

kubect1 get pods--sort-by=.metadata.creationTimestamp

Task Summary

You are managing a WordPress Deployment in namespace relative-fawn.

Deployment has 3 replicas.

Pods are not starting due to high resource requests.

Your job:✅ Adjust CPU and memory requests so that all 3 pods evenly split the node’s capacity.

Step-by-Step Solution

1️⃣ SSH into the correct host

bash

CopyEdit

ssh cka000058

???? Skipping this will result in a zero score.

2️⃣ Check node resource capacity

You need to know the node’s CPU and memory resources.

bash

CopyEdit

kubectl describe node | grep -A5 "Capacity"

Example output:

yaml

CopyEdit

Capacity:

cpu: 3

memory: 3Gi

Let’s assume the node has:

3 CPUs

3Gi memory

So for 3 pods, divide evenly:

CPU request per pod: 1

Memory request per pod: 1Gi

⚠️ In the actual exam, check real values and divide accordingly. If the node has 4 CPUs and 8Gi, you'd allocate ~1.33 CPUs and ~2.66Gi RAM per pod (rounded reasonably).

3️⃣ Edit the Deployment

Edit the WordPress deployment in the relative-fawn namespace:

kubectl edit deployment wordpress -n relative-fawn

Look for the resources section under spec.template.spec.containers like this:

resources:

requests:

cpu: "1"

memory: "1Gi"

If the section doesn’t exist, add it manually.

Save and exit the editor (:wq if using vi).

4️⃣ Confirm changes

Wait a few seconds, then check:

kubectl get pods -n relative-fawn

Ensure all 3 pods are in Running state.

You can also describe a pod to confirm resource requests are set:

kubectl describe pod -n relative-fawn | grep -A5 "Containers"

ssh cka000058

kubectl describe node | grep -A5 "Capacity"

kubectl edit deployment wordpress -n relative-fawn

# Set CPU: 1, Memory: 1Gi (or according to node capacity)

kubectl get pods -n relative-fawn

kubectl run nginx --image=nginx --restart=Never --labels=env=test --namespace=engineering --dry-run -o yaml > nginx-pod.yaml

kubectl run nginx --image=nginx --restart=Never --labels=env=test --namespace=engineering --dry-run -o yaml | kubectl create -n engineering -f –

YAML File:

apiVersion: v1

kind: Pod

metadata:

name: nginx

namespace: engineering

labels:

env: test

spec:

containers:

- name: nginx

image: nginx

imagePullPolicy: IfNotPresent

restartPolicy: Never

kubectl create -f nginx-pod.yaml

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']}"

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

Task Overview

You're restoring a MariaDB deployment in the mariadb namespace with persistent data.

✅ Tasks:

SSH into cka000047

Create a PVC named mariadb:

Namespace: mariadb

Access mode: ReadWriteOnce

Storage: 250Mi

Use the existing retained PV (there’s only one)

Edit ~/mariadb-deployment.yaml to use the PVC

Apply the deployment

Verify MariaDB is running and stable

Step-by-Step Solution

1️⃣ SSH into the correct host

ssh cka000047

⚠️ Required — skipping = zero score

2️⃣ Inspect the existing PersistentVolume

kubectl get pv

✅ Identify the only existing PV, e.g.:

NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS

mariadb-pv 250Mi RWO Retain Available manual

Ensure the status is Available, and it is not already bound to a claim.

3️⃣ Create the PVC to bind the retained PV

Create a file mariadb-pvc.yaml:

cat < mariadb-pvc.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: mariadb

namespace: mariadb

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 250Mi

volumeName: mariadb-pv # Match the PV name exactly

EOF

Apply the PVC:

kubectl apply -f mariadb-pvc.yaml

✅ This binds the PVC to the retained PV.

4️⃣ Edit the MariaDB Deployment YAML

Open the file:

nano ~/mariadb-deployment.yaml

Look under the spec.template.spec.containers.volumeMounts and spec.template.spec.volumes sections and update them like so:

Add this under the container:

yaml

CopyEdit

volumeMounts:

- name: mariadb-storage

mountPath: /var/lib/mysql

And under the pod spec:

volumes:

- name: mariadb-storage

persistentVolumeClaim:

claimName: mariadb

✅ These lines mount the PVC at the MariaDB data directory.

5️⃣ Apply the updated Deployment

kubectl apply -f ~/mariadb-deployment.yaml

6️⃣ Verify the Deployment is running and stable

kubectl get pods -n mariadb

kubectl describe pod -n mariadb

✅ Ensure the pod is in Running state and volume is mounted.

???? Final Command Summary

ssh cka000047

kubectl get pv # Find the retained PV

# Create PVC

cat < mariadb-pvc.yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: mariadb

namespace: mariadb

spec:

accessModes:

- ReadWriteOnce

resources:

requests:

storage: 250Mi

volumeName: mariadb-pv

EOF

kubectl apply -f mariadb-pvc.yaml

# Edit Deployment

nano ~/mariadb-deployment.yaml

# Add volumeMount and volume to use the PVC as described

kubectl apply -f ~/mariadb-deployment.yaml

kubectl get pods -n mariadb

kubectl run nginx --image=nginx --restart=Never --env=var1=value1

# then

kubectl exec -it nginx -- env

# or

kubectl exec -it nginx -- sh -c 'echo $var1'

# or

kubectl describe po nginx | grep value1

Kubectl logs frontend | grep -i “started” > /opt/error-logs

Task Summary

SSH into node: cka000059

Cluster was migrated to a new machine

It uses an external etcd server

Identify and fix misconfigured components

Bring the cluster back to a healthy state

Step-by-Step Solution

Step 1: SSH into the correct host

ssh cka000059

Step 2: Check the cluster status

Run:

kubectl get nodes

If it fails, the kubelet or kube-apiserver is likely broken.

Check kubelet status:

sudo systemctl status kubelet

Also, check pod statuses in the control plane:

sudo crictl ps -a | grep kube

or:

docker ps -a | grep kube

Look especially for failures in kube-apiserver or kube-controller-manager.

Step 3: Inspect the kube-apiserver manifest

Since this is a kubeadm-based cluster, manifests are in:

ls /etc/kubernetes/manifests

Open kube-apiserver.yaml:

bash

CopyEdit

sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml

Look for the --etcd-servers= flag. If the external etcd endpoint has changed (likely, due to migration), this needs to be fixed.

Example of incorrect configuration:

--etcd-servers=https://192.168.1.100:2379

If the IP has changed, update it to the correct IP or hostname of the external etcd server.

Also ensure the correct client certificate and key paths are still valid:

--etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt

--etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt

--etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key

If the files are missing or the path is wrong due to migration, correct those as well.

Step 4: Save and exit, and let static pod restart

Static pod changes will be picked up automatically by the kubelet (watch for /etc/kubernetes/manifests changes).

Check again:

docker ps | grep kube-apiserver

# or

crictl ps | grep kube-apiserver

Step 5: Confirm API is healthy

Once kube-apiserver is up, try:

kubectl get componentstatuses

kubectl get nodes

If these commands work and return valid statuses, the control plane is functional again.

Step 6: Check controller-manager and scheduler (optional)

If still broken, check the other static pods in /etc/kubernetes/manifests/ and correct paths if necessary.

Also verify that /etc/kubernetes/kubelet.conf and /etc/kubernetes/admin.conf are present and valid.

Command Summary

ssh cka000059

# Check system and kubelet

sudo systemctl status kubelet

docker ps -a | grep kube # or crictl ps -a | grep kube

# Check manifests

ls /etc/kubernetes/manifests

sudo nano /etc/kubernetes/manifests/kube-apiserver.yaml

# Fix --etcd-servers and certificate paths if needed

# Watch pods restart and confirm:

kubectl get nodes

kubectl get componentstatuses

kubect1 get pods -o=jsonpath='{range

items[*]}{.metadata.name}{"\t"}{.status.podIP}{"\n"}{end}'

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

Solution:

vi ingress.yaml

#

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: ping

namespace: ing-internal

spec:

rules:

- http:

paths:

- path: /hi

pathType: Prefix

backend:

service:

name: hi

port:

number: 5678

#

kubectl create -f ingress.yaml

// create a pod

kubectl run nginx --image=nginx --restart=Never --port=80

// List the pod with different verbosity

kubectl get po nginx --v=7

kubectl get po nginx --v=8

kubectl get po nginx --v=9

Task Summary

You are given a host to prepare for Kubernetes:

Use dpkg to install cri-dockerd

Enable and start the cri-docker service

Set net.bridge.bridge-nf-call-iptables to 1 via sysctl

Step-by-Step Instructions

1️⃣ SSH into the correct node

bash

CopyEdit

ssh cka000051

⚠️ Required — failure to connect to the correct host = zero score.

2️⃣ Install cri-dockerd

You are told the .deb file is already located at:

bash

CopyEdit

~/cri-dockerd_0.3.9.3-0.ubuntu-jammy_amd64.deb

Install it with dpkg:

bash

CopyEdit

sudo dpkg -i ~/cri-dockerd_0.3.9.3-0.ubuntu-jammy_amd64.deb

???? If any dependencies are missing (e.g., golang or containerd), you might need:

bash

CopyEdit

sudo apt-get install -f -y

But usually, the exam system provides a pre-validated .deb environment.

3️⃣ Enable and start cri-docker service

Start and enable both services:

bash

CopyEdit

sudo systemctl enable cri-docker.service

sudo systemctl enable --now cri-docker.socket

sudo systemctl start cri-docker.service

Check status (optional but smart):

bash

CopyEdit

sudo systemctl status cri-docker.service

You should see it active (running).

4️⃣ Configure the sysctl parameter

Set net.bridge.bridge-nf-call-iptables=1 immediately and persistently.

Step A: Apply immediately:

sudo sysctl net.bridge.bridge-nf-call-iptables=1

Step B: Persist it in /etc/sysctl.d:

Create or modify a file:

echo "net.bridge.bridge-nf-call-iptables = 1" | sudo tee /etc/sysctl.d/k8s.conf

Reload sysctl:

sudo sysctl --system

Verify:

sysctl net.bridge.bridge-nf-call-iptables

Should return:

net.bridge.bridge-nf-call-iptables = 1

✅ Now the system is ready for kubeadm with Docker (via cri-dockerd)!

ssh cka000051

sudo dpkg -i ~/cri-dockerd_0.3.9.3-0.ubuntu-jammy_amd64.deb

sudo systemctl enable cri-docker.service

sudo systemctl enable --now cri-docker.socket

sudo systemctl start cri-docker.service

sudo sysctl net.bridge.bridge-nf-call-iptables=1

echo "net.bridge.bridge-nf-call-iptables = 1" | sudo tee /etc/sysctl.d/k8s.conf

sudo sysctl --system

kubect1 get pods -o wide

kubectl delete po “nginx-dev”

kubectl delete po “nginx-prod”