You are asked to prepare a Canary deployment for testing a new application release. A Service named krill-Service in the goshark namespace points to 5 pod created by the Deployment named current-krill-deployment 1) Create an identical Deployment named canary-krill-deployment, in the same namespace. 2) Modify the Deployment so that: -A maximum number of 10 pods run in the goshawk namespace. -40% of the krill-service's traffic goes to the canary-krill-deployment pod(s)

Linux_Foundation

CKAD · Question #25

You are asked to prepare a Canary deployment for testing a new application release. A Service named krill-Service in the goshark namespace points to 5 pod created by the Deployment named…

This question tests your ability to implement a Kubernetes Canary deployment strategy by cloning an existing Deployment, then controlling traffic distribution between stable and canary versions by manipulating replica counts - since a Kubernetes Service load-balances evenly…

Submitted by krish.m· May 4, 2026Application Deployment

Question

You are asked to prepare a Canary deployment for testing a new application release. A Service named krill-Service in the goshark namespace points to 5 pod created by the Deployment named current-krill-deployment
Create an identical Deployment named canary-krill-deployment, in the same namespace.
Modify the Deployment so that:
-A maximum number of 10 pods run in the goshawk namespace.
-40% of the krill-service's traffic goes to the canary-krill-deployment pod(s)

Explanation

Approach. The correct approach relies on a key insight: a Kubernetes Service routes traffic to pods purely by label selector, distributing requests evenly across ALL matching pods regardless of which Deployment created them. To achieve 40% canary traffic with a maximum of 10 total pods, you set canary-krill-deployment to 4 replicas and current-krill-deployment to 6 replicas (4/10 = 40%, 6/10 = 60%). The step-by-step process is: (1) Export the existing deployment - kubectl get deployment current-krill-deployment -n goshawk -o yaml > canary.yaml - then edit the name to canary-krill-deployment and set replicas: 4, keeping all pod template labels identical so the krill-Service selector still matches. (2) Apply it - kubectl apply -f canary.yaml. (3) Scale down the original - kubectl scale deployment current-krill-deployment -n goshawk --replicas=6. The pod template labels on BOTH deployments MUST match the Service's selector (e.g., app: krill); the Deployment name itself is irrelevant to the Service. Do NOT add a label that uniquely identifies the deployment version to the pod template, or the Service will stop sending traffic to one of them.

Concept tested. Kubernetes Canary Deployment pattern - traffic splitting via replica count manipulation under a shared Service label selector, combined with namespace-scoped resource creation and replica arithmetic (40% of 10 = 4 canary pods, 60% = 6 stable pods).

Reference. Kubernetes Docs: Canary Deployments - https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments

Topics

#Canary Deployment#Kubernetes Deployment#Kubernetes Service#Traffic Splitting

Community Discussion

No community discussion yet for this question.

Full CKAD Practice