CKA Linux Foundation Exam Lab Questions

kubect1 get pods -o wide

kubectl delete po “nginx-dev”

kubectl delete po “nginx-prod”

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

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:

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

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