Linux Foundation CKAD Exam Dumps

ssh ckad00043

You have two deliverables here:

Figure out what RBAC permissions the scraper Deployment needs (the logs will usually show ''Forbidden'' with the missing verb/resource).

Create a ServiceAccount named scraper in namespace cute-panda (and in practice, you then bind the needed permissions to it and use it in the Deployment so it actually works).

Below is the exact CKAD-style workflow.

1) Find the missing RBAC permissions (use logs + events)

1.1 Identify the pods for the Deployment

kubectl -n cute-panda get deploy scraper

kubectl -n cute-panda get pods -l app=scraper 2>/dev/null || kubectl -n cute-panda get pods

Pick one pod name and check logs:

kubectl -n cute-panda logs deploy/scraper --tail=100

If the pod is crashlooping and logs are short:

POD=$(kubectl -n cute-panda get pods -o jsonpath='{.items[0].metadata.name}')

kubectl -n cute-panda logs '$POD' --previous --tail=200

1.2 Look specifically for ''Forbidden'' lines

Most apps print errors like:

... is forbidden: User 'system:serviceaccount:cute-panda:default' cannot list resource 'pods' in API group '' in the namespace 'cute-panda'

or cannot get resource 'configmaps'...

or cannot watch ...

If you don't see it in logs, check events:

kubectl -n cute-panda get events --sort-by=.lastTimestamp | tail -n 30

1.3 Extract verb/resource/apiGroup from the error

From a typical Kubernetes RBAC ''forbidden'' message, capture:

verb: get/list/watch/create/update/patch/delete

resource: pods, configmaps, secrets, deployments, etc.

apiGroup: '' (core), apps, batch, etc.

namespace: cute-panda (this is a namespaced permission if it's a Role)

You may have multiple ''cannot ...'' lines you need to allow all of them.

2) Create the ServiceAccount scraper (required by the task)

kubectl -n cute-panda create serviceaccount scraper

kubectl -n cute-panda get sa scraper

3) Create the RBAC objects to grant the needed permissions

The task says ''A Deployment needs specific RBAC permissions'' --- in CKAD, that usually means: Role + RoleBinding (namespaced) bound to your new ServiceAccount.

3.1 Create a Role (template you fill from the log output)

Create scraper-role.yaml:

cat <<'EOF' > scraper-role.yaml

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

name: scraper-role

namespace: cute-panda

rules:

# EXAMPLE ONLY: replace these rules with what your logs show

- apiGroups: ['']

resources: ['pods']

verbs: ['get','list','watch']

EOF

Apply it:

kubectl apply -f scraper-role.yaml

3.2 Bind the Role to the ServiceAccount

kubectl -n cute-panda create rolebinding scraper-rb \

--role=scraper-role \

--serviceaccount=cute-panda:scraper

Verify:

kubectl -n cute-panda get role scraper-role

kubectl -n cute-panda get rolebinding scraper-rb -o yaml

4) Update the Deployment to use the new ServiceAccount (so it actually works)

Check current SA (likely default):

kubectl -n cute-panda get deploy scraper -o jsonpath='{.spec.template.spec.serviceAccountName}{'\n'}'

Patch it to use scraper:

kubectl -n cute-panda patch deploy scraper -p '{'spec':{'template':{'spec':{'serviceAccountName':'scraper'}}}}'

Rollout:

kubectl -n cute-panda rollout status deploy scraper

Re-check logs to confirm RBAC errors are gone:

kubectl -n cute-panda logs deploy/scraper --tail=100

To find the broken pod and store its name and namespace to /opt/KDOB00401/broken.txt, you can use the kubectl get pods command and filter the output by the status of the pod.

kubectl get pods --field-selector=status.phase=Failed -o jsonpath='{.items[*].metadata.namespace}/{.items[*].metadata.name}' > /opt/KDOB00401/broken.txt

This command will list all pods with a status of Failed and output their names and namespaces in the format <namespace>/. The output is then written to the /opt/KDOB00401/broken.txt file.

To store the associated error events to a file /opt/KDOB00401/error.txt, you can use the kubectl describe command to retrieve detailed information about the pod, and the grep command to filter the output for error events.

kubectl describe pods --namespace | grep -i error -B5 -A5 > /opt/KDOB00401/error.txt

Replace and with the name and namespace of the broken pod you found in the previous step.

This command will output detailed information about the pod, including error events. The grep command filters the output for lines containing 'error' and also prints 5 lines before and after the match.

To fix the issue, you need to analyze the error events and find the root cause of the issue.

It could be that the application inside the pod is not running, the container image is not available, the pod has not enough resources, or the liveness probe configuration is incorrect.

Once you have identified the cause, you can take appropriate action, such as restarting the application, updating the container image, increasing the resources, or modifying the liveness probe configuration.

After fixing the issue, you can use the kubectl get pods command to check the status of the pod and ensure

Solution:

ssh ckad00023

You need two outcomes in moose:

At most 10 Pods total (across both Deployments).

About 20% of chipmunk-service traffic goes to canary-chipmunk-deployment.

In Kubernetes Services, traffic distribution is (roughly) proportional to the number of ready endpoints behind the Service. So the standard canary trick is:

total endpoints = 10

canary endpoints = 2

current endpoints = 8

That gives ~20% to canary.

1) Inspect what exists

kubectl -n moose get deploy

kubectl -n moose get svc chipmunk-service -o wide

kubectl -n moose describe svc chipmunk-service

Get the Service selector (important):

kubectl -n moose get svc chipmunk-service -o jsonpath='{.spec.selector}{'\n'}'

Check current replicas:

kubectl -n moose get deploy current-chipmunk-deployment -o jsonpath='{.spec.replicas}{'\n'}'

kubectl -n moose get deploy canary-chipmunk-deployment -o jsonpath='{.spec.replicas}{'\n'}'

List pods + labels (to confirm both Deployments' pods match the Service selector):

kubectl -n moose get pods --show-labels

2) Ensure both Deployments are behind the Service

This is the key: the pods from BOTH deployments must match the Service selector.

If the Service selector is something like app=chipmunk, then both Deployments' pod templates must include app: chipmunk.

If one Deployment doesn't match, patch its pod template labels to match the selector.

2A) Example: selector is app=chipmunk

(Only do this if you see the Service selector contains app=chipmunk and one of the deployments is missing it.)

kubectl -n moose patch deploy current-chipmunk-deployment \

-p '{'spec':{'template':{'metadata':{'labels':{'app':'chipmunk'}}}}}'

kubectl -n moose patch deploy canary-chipmunk-deployment \

-p '{'spec':{'template':{'metadata':{'labels':{'app':'chipmunk'}}}}}'

Wait for rollouts if patches triggered new ReplicaSets:

kubectl -n moose rollout status deploy current-chipmunk-deployment

kubectl -n moose rollout status deploy canary-chipmunk-deployment

Verify endpoints now include pods from both deployments:

kubectl -n moose get endpoints chipmunk-service -o wide

3) Set replicas to enforce ''max 10 pods'' and ''20% canary''

Set:

current = 8

canary = 2

Total = 10.

kubectl -n moose scale deploy current-chipmunk-deployment --replicas=8

kubectl -n moose scale deploy canary-chipmunk-deployment --replicas=2

Wait until ready:

kubectl -n moose rollout status deploy current-chipmunk-deployment

kubectl -n moose rollout status deploy canary-chipmunk-deployment

Confirm total pods is 10 (or less) and all are Running/Ready:

kubectl -n moose get pods

kubectl -n moose get pods | tail -n +2 | wc -l

Confirm endpoints count matches 10:

kubectl -n moose get endpoints chipmunk-service -o jsonpath='{.subsets[*].addresses[*].ip}' | wc -w

4) Test load balancing via NodePort 30000

Run several times:

for i in $(seq 1 30); do curl -s http://localhost:30000/; echo; done

You should see canary responses appear roughly ~20% of the time (not exact every run).

If you want a clearer signal, check which pods are endpoints and ensure 2 belong to canary and 8 to current:

kubectl -n moose get pods -l app=chipmunk -o wide

kubectl -n moose get endpoints chipmunk-service -o wide

Solution: