Linux Foundation Certified Kubernetes Administrator (CKA)

Step 1: Create the YAML manifest

Create a file named hpa.yaml with the following configuration:

YAML

apiVersion: autoscaling/v2

kind: HorizontalPodAutoscaler

metadata:

  name: apache-server

  namespace: autoscale

spec:

  scaleTargetRef:

    apiVersion: apps/v1

    kind: Deployment

    name: apache-server

  minReplicas: 1

  maxReplicas: 4

  metrics:

  - type: Resource

    resource:

      name: cpu

      target:

        type: Utilization

       averageUtilization: 50

  behavior:

    scaleDown:

     stabilizationWindowSeconds: 30

Step 2: Apply the manifest

Run the following command to apply the configuration to your cluster:

Bash

kubectl apply -f hpa.yaml

Step 3: Verify the HPA

Ensure the HPA was created successfully and is targeting the correct deployment:

Bash

kubectl get hpa apache-server -n autoscale

You should see the target metrics, the min/max pod limits (1 to 4), and the current replicas. It may take a minute or two for the HPA to gather the initial metrics and display the current CPU utilization.

Connecting to the Host

First, ensure you are on the correct node for this task as shown in your screenshot:

Bash

ssh cka000024

Creating the Ingress Resource

You can complete this task by creating a declarative YAML file. This is the safest way to ensure all path types and backend services are configured accurately.

Step 1: Create the YAML manifest

Create a file named ingress.yaml with the following configuration:

YAML

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

  name: echo

  namespace: sound-repeater

spec:

  rules:

  - host: example.org

    http:

      paths:

      - path: /echo

        pathType: Prefix

        backend:

          service:

            name: echoserver-service

            port:

              number: 8080

Step 2: Apply the manifest

Run the following command to apply the configuration to the cluster:

Bash

kubectl apply -f ingress.yaml

(Optional Quick Method): Alternatively, you can create this imperatively in a single line, though the YAML approach above is highly recommended to avoid syntax errors during the exam:

Bash

kubectl create ingress echo -n sound-repeater --rule="example.org/echo*=echoserver-service:8080"

Validation

Once the Ingress is created, it might take a few moments for the Ingress Controller to satisfy the request. Use the command provided in your instructions to verify that it is routing correctly and returning a 200 HTTP code:

Bash

Task 1: Install and Configure cri-dockerd

You need to install the provided Debian package and ensure its service is running and enabled on boot.

1. Install the package using dpkg: (Note: The prompt contains slight typos like cri-dockert and -/. It is assumed the file is in the home directory ~. Use the ls command to verify the exact filename if this command cannot find it).

Bash

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

2. Enable and start the service: Enable the service so it starts automatically on boot, and start it immediately for the current session.

Bash

systemctl enable cri-docker

systemctl start cri-docker

You can verify it is running with:

Bash

systemctl status cri-docker

Task 2: Configure System Parameters (sysctl)

To ensure these parameters persist after a reboot and are applied immediately, you must write them to a configuration file in the /etc/sysctl.d/ directory and then reload the sysctl settings.

1. Ensure required modules are loaded (Prerequisite for bridge parameters): The br_netfilter module is usually required before you can set net.bridge.bridge-nf-call-iptables. Run this to ensure it's loaded:

Bash

modprobe br_netfilter

echo "br_netfilter" > /etc/modules-load.d/br_netfilter.conf

2. Create the configuration file: Write the requested parameters into a new file. (Note: I have corrected the typo ip_forwar to the valid kernel parameter ip_forward).

Bash

cat <<EOF > /etc/sysctl.d/99-kubernetes.conf

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

net.ipv6.conf.all.forwarding = 1

net.ipv4.ip_forward = 1

net.netfilter.nf_conntrack_max = 131072

EOF

3. Apply the parameters to the running system: Reload the configuration so the system applies these parameters immediately without needing a restart.

Bash

sysctl --system

You can verify that the settings were applied correctly by checking them individually, for example:

Bash

sysctl net.ipv4.ip_forward

This is a classic resource calculation and manipulation scenario often seen in CKA simulations. The trick here is finding the exact node capacity, doing the math to leave a safe buffer, and correctly applying the YAML to both regular and init containers without touching the limits.

Here is your step-by-step guide to solving this task.

Step 1: Calculate the Resource Requests

Before editing the deployment, you need to know how much resource capacity your worker node actually has.

1. Identify the worker node:

Bash

kubectl get nodes

2. Check the node's Allocatable resources:

Bash

kubectl describe node <worker-node-name> | grep -i allocatable -A 5

You will see output similar to this:

Allocatable: cpu: 2 memory: 4000Mi

3. Do the math (with overhead): To divide evenly across 3 pods and leave overhead for stability, do not use 100% of the allocatable space. Leave roughly 10-20% unallocated.

• Example CPU: If Allocatable is 2 (2000m), a safe total target is 1500m. Divided by 3 pods = 500m per pod.
• Example Memory: If Allocatable is 4000Mi, a safe total target is 3000Mi. Divided by 3 pods = 1000Mi per pod.

(Note: Adjust the math above based on the actual numbers you see in your exam terminal!)

Step 2: Scale Down the Deployment

As the prompt hints, scaling to 0 prevents the ReplicaSet from trying to schedule Pods with incomplete or failing resource requests while you are saving your edits.

Bash

kubectl scale deployment wordpress -n relative-fawn --replicas=0

Step 3: Edit the Deployment

Now, edit the deployment directly in your terminal.

Bash

kubectl edit deployment wordpress -n relative-fawn

Scroll down to the spec.template.spec section. You need to locate the initContainers array (if one exists) and the containers array. Add the exact same resources.requests block to both, while leaving any existing limits completely untouched.

Your YAML should look similar to this:

YAML

      initContainers:

      - name: some-init-container

        image: busybox

        resources:

          requests:

            cpu: 500m      # Calculated from Step 1

            memory: 1000Mi # Calculated from Step 1

          # DO NOT add or modify 'limits'

      containers:

      - name: wordpress

        image: wordpress:latest

        resources:

          requests:

            cpu: 500m      # Must match initContainers exactly

            memory: 1000Mi # Must match initContainers exactly

          # DO NOT add or modify 'limits'

Save and exit the editor (:wq in Vim).

Step 4: Scale Up and Verify

Scale the deployment back up to 3 replicas to apply the new pods.

Bash

kubectl scale deployment wordpress -n relative-fawn --replicas=3

Finally, verify that all 3 pods are spinning up successfully and transitioning to the Running state.

Bash

kubectl get pods -n relative-fawn -w

Troubleshooting Tip: If the pods get stuck in Pending, it means your resource requests are too high and the node cannot accommodate all 3. Simply kubectl edit the deployment again, lower the CPU/Memory requests slightly to increase the overhead buffer, and save. Kubernetes will automatically recreate the pods with the new lower requests.

Connecting to the Host

As always, first ensure you are on the correct node for this specific task:

Bash

ssh cka000037

Task Execution: Adding the Sidecar Container

To integrate the legacy application with Kubernetes logging, you need to set up an emptyDir volume to share the /var/log directory between the existing app container and a new sidecar container.

The safest way to do this during the exam is to output the deployment to a YAML file, edit it, and apply it.

Step 1: Export the current Deployment

Extract the existing deployment configuration into a file so you can safely edit it:

Bash

kubectl get deployment synergy-leverager -o yaml > synergy-deploy.yaml

Step 2: Edit the YAML manifest

Open the file using your preferred text editor (e.g., vim synergy-deploy.yaml). You need to make three specific additions to the spec.template.spec section:

1. Add an emptyDir volume.
2. Mount that volume to the existing container at /var/log.
3. Add the new sidecar container with its specific image, command, and the same volume mount.

Modify your YAML so it looks similar to the following (pay close attention to the comments):

YAML

apiVersion: apps/v1

kind: Deployment

metadata:

  name: synergy-leverager

spec:

  # ... [keep existing spec configuration] ...

  template:

    spec:

      volumes:                           # 1. ADD this volumes block

      - name: shared-logs

        emptyDir: {}

      containers:

      - name: existing-app-container     # (Leave existing name/image as is)

        # ... [keep all existing container settings] ...

        volumeMounts:                    # 2. ADD volume mount to existing container

        - name: shared-logs

          mountPath: /var/log

      - name: sidecar                    # 3. ADD the new sidecar container

        image: busybox:stable

        command: ["/bin/sh", "-c", "tail -n+1 -f /var/log/synergy-leverager.log"]

        volumeMounts:

        - name: shared-logs

          mountPath: /var/log

Note: Remove any status fields or unnecessary metadata if you exported the live object, though kubectl apply usually handles them gracefully.

Step 3: Apply the updated Deployment

Save your changes and apply the updated YAML file back to the cluster:

Bash

kubectl apply -f synergy-deploy.yaml

Validation

Once applied, verify that the deployment has updated and the pods are running with 2/2 containers ready:

Bash

kubectl get pods -l app=synergy-leverager # Adjust label if necessary, or just use `kubectl get pods`

You should see a pod transition to Running with 2/2 in the READY column.

To definitively test that the sidecar is working and streaming the logs to standard output, use the kubectl logs command targeting the sidecar container specifically:

Bash

kubectl logs <synergy-leverager-pod-name> -c sidecar

Connecting to the Host

First, ensure you are on the correct node for this task:

Bash

ssh cka000054

Choosing the Right CNI

The critical requirement here is Network Policy enforcement.

• Flannel is a great, lightweight networking fabric, but it does not natively support Kubernetes Network Policies.
• Calico supports both pod-to-pod routing and robust Network Policy enforcement.

Therefore, you must select Calico to pass this task.

Installing Calico

Step 1: Apply the Operator Manifest

Apply the exact manifest URL provided in your instructions for Calico:

Bash

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/tigera-operator.yaml

Step 2: Apply the Custom Resources (Important Note)

When installing Calico via the Tigera Operator, the operator itself doesn't install the CNI components (like calico-node) until an Installation Custom Resource (CR) is created.

Often in these exams, if they only provide the operator link, applying it might be enough if the exam environment automatically provisions the CR in the background. However, if your nodes are still NotReady after a few minutes, you will need to apply the standard Calico custom resources file for that version to finish the setup:

Bash

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.28.2/manifests/custom-resources.yaml

Verification

To ensure the CNI is installed and functioning, check the status of your nodes and the Calico pods.

1. Check Node Status: The nodes should transition from NotReady to Ready once the CNI is successfully running.

Bash

kubectl get nodes

2. Check Calico Pods: Verify that the Tigera operator and Calico system pods are spinning up successfully.

Bash

kubectl get pods -n tigera-operator

kubectl get pods -n calico-system

Connecting to the Host

First, ensure you are on the correct node for this task, as specified in your screenshot:

Bash

ssh cka000046

Task 1: Create the StorageClass

You need to create a StorageClass with a specific provisioner and volume binding mode. The best approach is to write this declaratively in a YAML file.

Step 1: Create the YAML manifest

Create a file named sc.yaml and add the following configuration:

YAML

apiVersion: storage.k8s.io/v1

kind: StorageClass

metadata:

  name: local-path

provisioner: rancher.io/local-path

volumeBindingMode: WaitForFirstConsumer

Step 2: Apply the manifest

Run the following command to create the StorageClass:

Bash

kubectl apply -f sc.yaml

Task 2: Set as Default StorageClass

To make local-path the default StorageClass for the cluster, you need to add a specific annotation to its metadata. You can do this quickly using the kubectl patch command.

Step 1: Patch the StorageClass

Run this command to apply the default annotation:

Bash

kubectl patch storageclass local-path -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Validation

Always verify your work to ensure the changes were applied correctly during the exam.

List the StorageClasses in the cluster:

Bash

kubectl get storageclass

Look at the output. You should see local-path (default) in the list, and the VOLUMEBINDINGMODE column should explicitly state WaitForFirstConsumer. Note that the warnings explicitly state not to touch existing Deployments or PVCs, so your task is complete right here.

Connecting to the Host

To begin, make sure you are logged into the correct node as per the exam instructions:

Bash

ssh cka000049

Task 1: Identify the Highest Existing Priority

First, you need to find the highest user-defined PriorityClass value currently existing in the cluster so you can subtract 1 from it.

1. List all PriorityClasses and their values:

Bash

kubectl get priorityclass

2. Analyze the output:

• Ignore system-level priority classes (like system-cluster-critical with values typically over 2,000,000,000).
• Look for custom user-defined classes. For example, if you see an existing class named medium-priority with a value of 1000, your target value will be 999.

Task 2: Create the New PriorityClass

Once you have your calculated value (Highest User Value - 1), create a YAML file for the new PriorityClass.

1. Create priority.yaml: (Replace <CALCULATED_VALUE> with the exact number you determined in Step 1).

YAML

apiVersion: scheduling.k8s.io/v1

kind: PriorityClass

metadata:

  name: high-priority

value: <CALCULATED_VALUE>

globalDefault: false

description: "High priority class for user workloads"

2. Apply the manifest:

Bash

kubectl apply -f priority.yaml

Task 3: Patch the Deployment

Now you must configure the busybox-logger deployment to use this new PriorityClass. Since the instructions explicitly ask you to "Patch" the deployment, using kubectl patch is the fastest and most accurate method.

1. Run the patch command:

Bash

kubectl patch deployment busybox-logger -n priority --patch '{"spec": {"template": {"spec": {"priorityClassName": "high-priority"}}}}'

(Note: If you prefer to do this manually, you can run kubectl edit deployment busybox-logger -n priority and add priorityClassName: high-priority under spec.template.spec).

Task 4: Verify the Rollout

The instructions state you must ensure the deployment rolls out successfully and note that other pods may be evicted.

1. Watch the rollout status:

Bash

kubectl rollout status deployment busybox-logger -n priority

2. Verify the Pods: Check the state of the pods in the namespace. You should see the new busybox-logger pods coming up successfully. Because this is a high-priority deployment, Kubernetes will preempt (evict) lower-priority pods from other deployments if the node lacks sufficient resources.

Bash

kubectl get pods -n priority

Connecting to the Host

First, ensure you are on the correct node for this task, as specified in your screenshot:

Bash

ssh cka000060

Task 1: Add the Argo CD Helm Repository

You need to add the official Argo CD Helm repository and update your local Helm cache.

1. Add the repository:

Bash

helm repo add argo https://argoproj.github.io/argo-helm

2. Update the repositories:

Bash

helm repo update

Task 2: Generate the Helm Template

Next, generate the template for version 7.7.3 and save it to a file. (Note: The screenshot OCR shows -largo-helm.yaml, which is a common visual rendering error for the home directory path ~/argo-helm.yaml. I will use ~/argo-helm.yaml here).

1. Generate the template and output it to the file: To configure the chart to not install CRDs, we pass the --set crds.install=false flag (and/or the standard Helm --skip-crds flag) to explicitly ensure they are excluded from the configuration.

Bash

helm template argocd argo/argo-cd \

  --version 7.7.3 \

  --namespace argocd \

  --set crds.install=false \

  > ~/argo-helm.yaml

Task 3: Install Argo CD

Finally, use Helm to install Argo CD into the cluster using the exact same version, release name (argocd), namespace, and CRD configuration.

1. Create the namespace (if it doesn't already exist):

Bash

kubectl create namespace argocd

2. Install the Helm chart:

Bash

helm install argocd argo/argo-cd \

  --version 7.7.3 \

  --namespace argocd \

  --set crds.install=false \

  --skip-crds

Validation

You can verify that the installation was successful and the pods are spinning up in the argocd namespace:

Bash

kubectl get pods -n argocd

All Argo CD components should begin transitioning to the Running state. Since the instructions state you do not need to configure access to the UI, your task is complete.