Solution CKA Mock Exam 3 Optional

Before diving into the solutions for Mock Exam Three, it’s important to understand the exam environment. The Linux Foundation exam page under “Important Instructions for CKA and CKAD” outlines that the exam environment is preconfigured with several useful tools. These include an alias for kubectl (k) paired with bash auto-completion, along with preinstalled utilities such as JQ, TMUX, curl, wget, and man. These settings are designed to streamline your exam experience.

The image shows exam details and system requirements for Linux Foundation certification exams, including online proctoring, secure browser use, and technical specifications for candidates' computers.

Task 1: Create a Service Account, Cluster Role, and Pod

In this task, you will create a service account, a cluster role (with permissions to list persistent volumes), a cluster role binding, and finally, deploy a pod using the Redis image with the created service account.

Step 1.1: Create the Service Account

Create a service account named pvviewer and verify its creation:

kubectl create serviceaccount pvviewer
kubectl get serviceaccounts

The output should list the pvviewer service account, confirming its successful creation.

Step 1.2: Create the Cluster Role

Check the available options for creating a cluster role:

kubectl create clusterrole --help

Then, generate the cluster role pvviewer-role to allow listing persistent volumes:

kubectl create clusterrole pvviewer-role --verb=list --resource=persistentvolumes

Step 1.3: Bind the Role to the Service Account

Bind the newly created role to the pvviewer service account in the default namespace:

kubectl create clusterrolebinding pvviewer-role-binding --clusterrole=pvviewer-role --serviceaccount=default:pvviewer
kubectl describe clusterrolebinding pvviewer-role-binding

Ensure the binding output confirms that the pvviewer service account is correctly associated with the pvviewer-role.

Step 1.4: Create the Pod

Since the kubectl run command might not support the service account flag in all versions, start by generating a YAML manifest, update it to specify the service account, and then deploy the pod. Generate the YAML file:

kubectl run pvviewer --image=redis --dry-run=client -o yaml > pvviewer.yaml

Edit pvviewer.yaml to include the serviceAccountName field. The file should resemble:

apiVersion: v1
kind: Pod
metadata:
  name: pvviewer
  labels:
    run: pvviewer
spec:
  serviceAccountName: pvviewer
  containers:
  - name: pvviewer
    image: redis
  dnsPolicy: ClusterFirst
  restartPolicy: Always

Apply the configuration:

kubectl apply -f pvviewer.yaml
kubectl describe pod pvviewer

Verify that the pod is running with the correct service account.

The image shows a KodeKloud lab task involving Kubernetes, requiring the creation of a service account, cluster role, and pod with specific configurations.

Task 2: List Internal IPs of All Nodes

Your objective is to list the internal IP addresses of every node and save the output to /root/CKA/node_ips in the format shown below:

InternalIP of controlplane
InternalIP of node1

Step 2.1: Verify Node Details

List nodes with extended information:

kubectl get nodes -o wide

Step 2.2: Extract the Internal IP Addresses

Use JSONPath to extract the InternalIP addresses and write them to the file:

kubectl get nodes -o jsonpath='{range .items[*]}{.status.addresses[?(@.type=="InternalIP")].address}{"\n"}{end}' > /root/CKA/node_ips

Verify the output by displaying the file content:

cat /root/CKA/node_ips

Task 3: Create a Multi-Container Pod

You will deploy a pod named multi-pod containing two containers. The first container, “alpha”, will use the NGINX image, and the second container, “beta”, will use the busybox image to run the command sleep 4800. Both containers will have environment variables assigned.

Step 3.1: Generate and Edit the Pod Manifest

Generate the initial YAML manifest:

kubectl run multi-pod --image=nginx --dry-run=client -o yaml > multipod.yaml

Edit multipod.yaml to include a second container and the required environment variables:

apiVersion: v1
kind: Pod
metadata:
  name: multi-pod
  labels:
    run: multi-pod
spec:
  containers:
  - name: alpha
    image: nginx
    env:
    - name: name
      value: "alpha"
  - name: beta
    image: busybox
    command:
      - sleep
      - "4800"
    env:
    - name: name
      value: "beta"
  dnsPolicy: ClusterFirst
  restartPolicy: Always

Deploy the pod:

kubectl apply -f multipod.yaml
kubectl describe pod multi-pod

Ensure that both containers are correctly configured with their respective commands and environment variables.

Task 4: Create a Non-root Pod

Deploy a pod named non-root-pod using the redis:alpine image. This pod must run as a non-root user (user ID 1000) with the file system group set to 2000.

Step 4.1: Generate and Edit the YAML Manifest

Generate the YAML manifest:

kubectl run non-root-pod --image=redis:alpine --dry-run=client -o yaml > non-root-pod.yaml

Edit the manifest to add a security context at the pod level:

apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
  labels:
    run: non-root-pod
spec:
  securityContext:
    runAsUser: 1000
    fsGroup: 2000
  containers:
  - name: non-root-pod
    image: redis:alpine
  dnsPolicy: ClusterFirst
  restartPolicy: Always

Apply the configuration and verify the security context:

kubectl apply -f non-root-pod.yaml
kubectl get pod non-root-pod -o yaml | grep -i securityContext -A 5

Task 5: Create a Network Policy for Service Ingress

A predeployed pod (np-test-1) and a service (np-test-service) are experiencing connection issues on port 80. To resolve this, you need to create a network policy named ingress-to-nptest that permits ingress traffic on TCP port 80.

Step 5.1: Verify Existing Resources

Confirm that the pod and service exist:

kubectl get pods
kubectl get service np-test-service

Step 5.2: Test Connectivity

Launch a temporary pod with curl to test connectivity:

kubectl run curl-test --rm -it --image=alpine -- sh
# Inside the container, install curl and test:
apk add --no-cache curl && curl np-test-service

Step 5.3: Create the Network Policy

Create a file named network-policy.yaml with the following content. Ensure the pod selector label matches that of np-test-1:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-to-nptest
  namespace: default
spec:
  podSelector:
    matchLabels:
      run: np-test-1
  policyTypes:
  - Ingress
  ingress:
  - ports:
    - protocol: TCP
      port: 80

Apply the network policy:

kubectl apply -f network-policy.yaml
kubectl get networkpolicy

Test connectivity again using the curl test pod.

Task 6: Use Taints and Tolerations for Pod Scheduling

Part 6.1: Taint a Node and Create a Dev Pod

Firstly, taint the worker node (node01) with the key env_type, value production, and effect NoSchedule so that workloads without the appropriate toleration cannot be scheduled on it:

kubectl taint nodes node01 env_type=production:NoSchedule
kubectl describe node node01 | grep Taints

Next, create a pod named dev-redis using the Redis Alpine image without specifying any toleration:

kubectl run dev-redis --image=redis:alpine
kubectl get pods -o wide

Verify that the dev-redis pod is not scheduled on node01 due to the applied taint.

Part 6.2: Create a Production Pod with a Toleration

Now create a pod named prod-redis that tolerates the taint and can be scheduled on node01. Generate the manifest:

kubectl run prod-redis --image=redis:alpine --dry-run=client -o yaml > prod-redis.yaml

Edit prod-redis.yaml to add the toleration:

apiVersion: v1
kind: Pod
metadata:
  name: prod-redis
  labels:
    run: prod-redis
spec:
  tolerations:
  - key: "env_type"
    operator: "Equal"
    value: "production"
    effect: "NoSchedule"
  containers:
  - name: prod-redis
    image: redis:alpine
  dnsPolicy: ClusterFirst
  restartPolicy: Always

Apply the configuration:

kubectl apply -f prod-redis.yaml
kubectl get pods -o wide

The prod-redis pod should now be scheduled on node01 since it tolerates the taint.

The image shows a KodeKloud mock exam interface with instructions to taint a Kubernetes node and create pods with specific tolerations.

Task 7: Create a Pod in the HR Namespace with Specific Labels

Deploy a pod named hr-pod in a new namespace hr using the Redis Alpine image. The pod should include the labels environment=production and tier=front-end.

Step 7.1: Create the Namespace

Create the hr namespace:

kubectl create namespace hr

Step 7.2: Deploy the Pod with Labels

Deploy the pod in the hr namespace with the required labels:

kubectl run hr-pod -n hr --image=redis:alpine --labels="environment=production,tier=front-end"

Verify the pod and its labels:

kubectl get pods -n hr --show-labels

Task 8: Fix the Kubeconfig File (super.kubeconfig)

A misconfigured kubeconfig file named super.kubeconfig is located in /root/CKA/. When using it via the command below, you may encounter connection errors:

kubectl get nodes --kubeconfig /root/CKA/super.kubeconfig

The error might look similar to:

The connection to the server controlplane:9999 was refused - did you specify the right host or port?

Step 8.1: Edit the Kubeconfig File

Open the file for editing:

vi /root/CKA/super.kubeconfig

Locate the server: field. It may appear as:

server: https://controlplane:9999

Update it to use the correct port (typically 6443):

server: https://controlplane:6443

Save the file and re-test the connection:

kubectl get nodes --kubeconfig /root/CKA/super.kubeconfig

This change should resolve the connection errors by directing kubectl to the correct API server port.

Task 9: Scale an NGINX Deployment and Fix the Kube-Controller-Manager

A deployment named nginx-deploy was created with a single replica. Your goal is to scale it to three replicas.

Step 9.1: Scale the Deployment

Scale the deployment using the following commands:

kubectl get deployments
kubectl scale deployment nginx-deploy --replicas=3
kubectl get deployments

If the deployment does not scale as expected, it might be due to issues with the kube-controller-manager (for example, an ImagePullBackOff state).

Step 9.2: Troubleshoot the Controller Manager

First, inspect the status of critical components:

kubectl get pods -n kube-system

If the kube-controller-manager pod is in an ImagePullBackOff state, review its static pod manifest:

vi /etc/kubernetes/manifests/kube-controller-manager.yaml

Look for any typographical errors (for example, confusing the digit “1” with the letter “l” in command parameters or image names). Fix any discovered mistakes. After saving, the kube-controller-manager should restart and function normally. Verify that all deployment replicas are now correctly scaled once the control plane stabilizes.

The image shows a Kubernetes configuration file for a kube-controller-manager pod, alongside a task to scale an nginx deployment to three replicas.

This concludes the lesson on the solutions for Mock Exam Three.

​Task 1: Create a Service Account, Cluster Role, and Pod

​Step 1.1: Create the Service Account

​Step 1.2: Create the Cluster Role

​Step 1.3: Bind the Role to the Service Account

​Step 1.4: Create the Pod

​Task 2: List Internal IPs of All Nodes

​Step 2.1: Verify Node Details

​Step 2.2: Extract the Internal IP Addresses

​Task 3: Create a Multi-Container Pod

​Step 3.1: Generate and Edit the Pod Manifest

​Task 4: Create a Non-root Pod

​Step 4.1: Generate and Edit the YAML Manifest

​Task 5: Create a Network Policy for Service Ingress

​Step 5.1: Verify Existing Resources

​Step 5.2: Test Connectivity

​Step 5.3: Create the Network Policy

​Task 6: Use Taints and Tolerations for Pod Scheduling

​Part 6.1: Taint a Node and Create a Dev Pod

​Part 6.2: Create a Production Pod with a Toleration

​Task 7: Create a Pod in the HR Namespace with Specific Labels

​Step 7.1: Create the Namespace

​Step 7.2: Deploy the Pod with Labels

​Task 8: Fix the Kubeconfig File (super.kubeconfig)

​Step 8.1: Edit the Kubeconfig File

​Task 9: Scale an NGINX Deployment and Fix the Kube-Controller-Manager

​Step 9.1: Scale the Deployment

​Step 9.2: Troubleshoot the Controller Manager

Watch Video

Task 1: Create a Service Account, Cluster Role, and Pod

Step 1.1: Create the Service Account

Step 1.2: Create the Cluster Role

Step 1.3: Bind the Role to the Service Account

Step 1.4: Create the Pod

Task 2: List Internal IPs of All Nodes

Step 2.1: Verify Node Details

Step 2.2: Extract the Internal IP Addresses

Task 3: Create a Multi-Container Pod

Step 3.1: Generate and Edit the Pod Manifest

Task 4: Create a Non-root Pod

Step 4.1: Generate and Edit the YAML Manifest

Task 5: Create a Network Policy for Service Ingress

Step 5.1: Verify Existing Resources

Step 5.2: Test Connectivity

Step 5.3: Create the Network Policy

Task 6: Use Taints and Tolerations for Pod Scheduling

Part 6.1: Taint a Node and Create a Dev Pod

Part 6.2: Create a Production Pod with a Toleration

Task 7: Create a Pod in the HR Namespace with Specific Labels

Step 7.1: Create the Namespace

Step 7.2: Deploy the Pod with Labels

Task 8: Fix the Kubeconfig File (super.kubeconfig)

Step 8.1: Edit the Kubeconfig File

Task 9: Scale an NGINX Deployment and Fix the Kube-Controller-Manager

Step 9.1: Scale the Deployment

Step 9.2: Troubleshoot the Controller Manager