A progressive delivery product is unavailable in the cluster. How should a CKAD candidate implement a basic canary?
Select an answer to reveal the explanation.
Short Explanation
CKAD wants you fluent with the built-in Legos—Deployments and Services—not a branded progressive-delivery box. Spin a small v2 Deployment, share the Service, watch the fraction. Mesh can wait.
Full Explanation
When a progressive delivery product is unavailable in the cluster, a CKAD candidate should implement a basic canary with native Deployments and a Service, using replica weighting to expose a small v2 set. You do not need a service mesh to demonstrate canary fundamentals for municipal APIs on the exam.
Postponing the release until a mesh and progressive-delivery controller are installed exceeds CKAD scope and blocks delivery. Encoding canary percentages in the container entrypoint script does not split Service traffic. Replacing Kubernetes with a SaaS feature-flag platform for Pod scheduling confuses feature flags with Endpoints weighting.
Exam caveat: Know what you can do with core objects versus what requires Ingress controllers or meshes. Replica-weighted canary is the expected baseline answer.
Operational check: create deploy/stable and deploy/canary; point one Service at both via labels; scale canary to 1; kubectl get endpoints; raise canary replicas after validation. In municipal environments, document the chosen pattern in the service runbook so on-call engineers apply the same kubectl checks during incidents, and keep the change tied to the application Deployment or Job rather than ad-hoc node mutation.