CCNA Ckad Deployment Questions

`kubectl rollout undo deployment app` reverts the Deployment's pod template to the previous revision, which the Deployment controller uses to create a new ReplicaSet with that older specification. The current ReplicaSet is scaled down to zero while the previous one is scaled up, effectively rolling back the application state without deleting the Deployment object or its history.

Using a single Service with the broad selector `app: api` is the correct native Kubernetes approach because it makes the Service's Endpoints object include pods from both the stable and canary Deployments simultaneously. The kube-proxy component (or the in-cluster DNS/round-robin mechanism) then picks endpoints for each new connection uniformly, so the fraction of traffic each version receives is directly proportional to the number of ready pods it contributes—for 9 stable and 1 canary pod, roughly 90% of connections go to stable and 10% to canary. This ratio can be tuned by scaling the `replicas` field in each Deployment, but you cannot get fine-grained percentages because each pod is an equal unit and there is no weighting factor beyond pod count.

The livenessProbe sends an HTTP GET to port 8080 on the container's IP. Nginx by default listens on port 80 inside the container, so the kubelet's request to 8080 will get a connection refused error. Since the probe never succeeds, the kubelet marks the container unhealthy and after three consecutive failures kills the container. The container then restarts, but the same probe failure repeats, resulting in CrashLoopBackOff.

The overlay explicitly sets replicas: 5 in its patch, so Kustomize uses exactly that value in the final output. Since overlays take precedence over base values, the base's original replica count is overwritten. This is the core of how Kustomize enables environment-specific customizations: the overlay's patch always wins for fields it specifies, making 5 the correct and deterministic result.

Updating the Service's label selector to 'app: myapp, version: green' is the canonical blue-green switch: the Endpoints controller immediately recalculates the endpoint set to include only green pods, so new traffic flows to green while blue receives no new connections. Because this is a single atomic change (e.g., kubectl patch), there is zero downtime, and the blue Deployment remains intact for instant rollback if green fails.

With maxSurge=2, the Deployment controller may temporarily create up to 2 extra pods beyond the desired replica count of 5. This means the total number of pods running simultaneously during a rolling update can reach 7. The controller enforces this ceiling to maintain availability while rolling out changes, and 7 is therefore the absolute maximum possible.

DaemonSet is the correct controller because it automatically ensures a copy of the pod runs on every node in the cluster, including nodes added after the DaemonSet is created. It is designed for cluster-level daemons such as logging agents, monitoring exporters, and network proxies that need node-local presence. DaemonSet respects scheduling constraints like nodeSelectors and tolerations, but by default it provides the per-node coverage the requirement demands.

The HPA controller reconciles a HorizontalPodAutoscaler object against a scalable target, so the HPA resource must reference the Deployment as its scaleTargetRef. Without it, no autoscaling logic runs, regardless of metrics availability or container resource requests.

The command `kubectl rollout undo deployment/frontend --to-revision=1` is the correct rollback mechanism: it instructs the Deployment controller to revert the current pod template to the exact spec stored in revision 1 of its rollout history. This is the idiomatic way to undo a bad change, because it creates a new rollout (incrementing the revision number) while applying the old template, thereby preserving auditability. Using `--to-revision` explicitly targets a specific historical revision, ensuring the rollback is deterministic rather than merely undoing the most recent change.

The Recreate strategy is defined by this exact sequence: the Deployment controller first scales down all old ReplicaSets to zero, terminating every existing pod, and only then scales up the new ReplicaSet to the desired number of replicas. This ensures that no old and new versions ever run at the same time, but it also means there is a brief period of downtime. This behavior is explicitly set via `strategy.type: Recreate` in the Deployment manifest.

You can expose canary pods by creating a dedicated Service whose selector matches only the canary version label—e.g., version=canary. This Service gets its own stable ClusterIP (or LoadBalancer) and routes exclusively to canary pods, providing a direct endpoint for testers, QA teams, or automated verification pipelines. This approach is valid because it gives controlled access to the canary without mixing it into the production traffic path, but it does not automatically shift user traffic—it is for manual or targeted testing.

Correct. A Service's spec.selector is an equality-based label selector. When you create a Service, its selector matches Pods that carry the specified labels, and the Service's Endpoints object is populated with those Pods, enabling traffic distribution. The selector must exactly match the labels on the Pod template at creation time.

Adding the label 'version: stable' to the canary Deployment's pod template ensures that its pods are selected by the existing Service selector (which is already set to 'version: stable'). The Service then load-balances across all matching pods from both Deployments, distributing traffic proportionally to their replica counts. For example, with 9 stable and 1 canary pod, the canary receives about 10% of traffic, enabling controlled rollout while both versions share the same label and the Service selector remains unchanged.