CKAD Exam Dumps : Certified Kubernetes Application Developer (CKAD) Program

ssh ckad00025

You need to expose the existing app “web-app” externally at:

Host: external.sterling-bengal.local

Path: / (and anything starting with /) → route to web-app

In CKAD labs, this is almost always done with an Ingress pointing to the Service web-app.

1) Find where web-app Service lives (namespace + port)

kubectl get svc -A | grep -w web-app

You’ll get something like:

web-app ClusterIP ... /TCP

Set the namespace:

NS=

Check the service port(s):

kubectl -n $NS get svc web-app -o yaml

Note the service port number (commonly 80).

Also verify it has endpoints (so it actually routes to pods):

kubectl -n $NS get endpoints web-app -o wide

If endpoints are empty, the Service selector doesn’t match pods — tell me and I’ll give the exact fix. But usually it’s fine.

2) Create the Ingress to route / to web-app

Create a manifest (use the service port you saw; I’ll assume 80 below):

cat <<'EOF' > web-app-ingress.yaml

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

name: web-app-ingress

spec:

rules:

- host: external.sterling-bengal.local

http:

paths:

- path: /

pathType: Prefix

backend:

service:

name: web-app

port:

number: 80

EOF

Apply it:

kubectl -n $NS apply -f web-app-ingress.yaml

Verify:

kubectl -n $NS get ingress web-app-ingress

kubectl -n $NS describe ingress web-app-ingress

If your Service port is not 80, change number: 80 to the correct value and re-apply.

3) Test external reachability (as instructed)

Run exactly:

curl -i

If curl still fails (quick checks)

A) Is there an ingress controller running?

kubectl get pods -A | egrep -i 'ingress|nginx'

kubectl get svc -A | egrep -i 'ingress|nginx'

B) Does Ingress show an address?

kubectl -n $NS get ingress web-app-ingress -o wide

C) Do we have endpoints?

kubectl -n $NS get endpoints web-app -o wide

0) SSH to the correct host

ssh ckad00044

(Optional sanity)

kubectl config current-context

kubectl get ns | grep rapid-goat

1) Inspect the Deployment and current container name

kubectl -n rapid-goat get deploy busybox

kubectl -n rapid-goat get deploy busybox -o jsonpath='{.spec.template.spec.containers[*].name}{"\n"}'

kubectl -n rapid-goat get deploy busybox -o jsonpath='{.spec.template.spec.containers[*].image}{"\n"}'

Note the current container name (likely something like busybox). We need to rename it to musl.

2) Edit the Deployment (best for renaming container)

Renaming a container is easiest with edit:

kubectl -n rapid-goat edit deploy busybox

In the editor, find:

spec:

template:

spec:

containers:

- name:

image:

Change it to:

- name: musl

image: busybox:musl

Save and exit.

3) Ensure the rollout happens and completes

kubectl -n rapid-goat rollout status deploy busybox

4) Verify the new Pod template is correct

Check the Deployment template:

kubectl -n rapid-goat get deploy busybox -o jsonpath='{.spec.template.spec.containers[0].name}{"\n"}{.spec.template.spec.containers[0].image}{"\n"}'

Check running Pods and the image actually used:

kubectl -n rapid-goat get pods -o wide

POD=$(kubectl -n rapid-goat get pods -l app=busybox -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true)

If you don’t have that label selector, just pick a pod name from kubectl get pods and:

kubectl -n rapid-goat describe pod | sed -n '/Containers:/,/Conditions:/p'

Goal: fix nosql Deployment in haddock so the container stops OOM’ing by setting:

memory request = 128Mi

memory limit = half of the namespace’s maximum memory constraint

You must do this on the correct host.

0) Connect to the correct host

ssh ckad00032

1) Confirm the failing Deployment / Pods

kubectl -n haddock get deploy nosql

kubectl -n haddock get pods -l app=nosql 2>/dev/null || kubectl -n haddock get pods

If pods are crashing, check why (you’ll likely see OOMKilled):

kubectl -n haddock describe pod

2) Find the maximum memory constraint set for the haddock namespace

In CKAD labs, this is commonly enforced by a LimitRange (max memory per container). Sometimes it can also be a ResourceQuota.

2A) Check LimitRange (most likely)

kubectl -n haddock get limitrange

kubectl -n haddock get limitrange -o yaml

Extract the max memory value quickly:

MAX_MEM=$(kubectl -n haddock get limitrange -o jsonpath='{.items[0].spec.limits[0].max.memory}')

echo "Namespace max memory constraint: $MAX_MEM"

2B) If no LimitRange exists, check ResourceQuota

kubectl -n haddock get resourcequota

kubectl -n haddock describe resourcequota

If quota is used, you’re looking for something like limits.memory (but the question wording “maximum memory constraint” usually points to LimitRange max.memory).

3) Compute “half of the max memory constraint”

Run this small snippet to compute HALF in Mi (handles Mi and Gi):

HALF_MEM=$(python3 - <<'PY'

import os, re

q = os.environ.get("MAX_MEM","").strip()

m = re.fullmatch(r"(\d+)(Mi|Gi)", q)

if not m:

raise SystemExit(f"Cannot parse MAX_MEM='{q}'. Expected like 512Mi or 1Gi.")

val = int(m.group(1))

unit = m.group(2)

# convert to Mi

mi = val if unit == "Mi" else val * 1024

half_mi = mi // 2

print(f"{half_mi}Mi")

PY

)

echo "Half of max: $HALF_MEM"

Example: if MAX_MEM=512Mi → HALF_MEM=256Mi

Example: if MAX_MEM=1Gi → HALF_MEM=512Mi

4) Update the nosql Deployment (DO NOT delete it)

First, get the container name (Deployment may have a custom container name):

kubectl -n haddock get deploy nosql -o jsonpath='{.spec.template.spec.containers[*].name}{"\n"}'

Now set resources (this updates the Deployment in-place):

kubectl -n haddock set resources deploy nosql \

--requests=memory=128Mi \

--limits=memory=$HALF_MEM

5) Ensure the update rolls out successfully

kubectl -n haddock rollout status deploy nosql

6) Verify the pod has the right requests/limits

kubectl -n haddock get deploy nosql -o jsonpath='{.spec.template.spec.containers[0].resources}{"\n"}'

kubectl -n haddock get pods

Pick the new pod and confirm:

kubectl -n haddock describe pod | sed -n '/Requests:/,/Limits:/p'

You should see:

Requests: memory 128Mi

Limits: memory

If rollout fails (common cause)

If you accidentally set a limit above the namespace max, pods won’t start. Check events:

kubectl -n haddock describe deploy nosql

kubectl -n haddock get events --sort-by=.lastTimestamp | tail -n 20