Draft a small Deployment and Service manifest, explain selector matching and plan readiness and rollback checks.
A fictional static workshop site needs two replicas. Pods carry label app: workshop, the Service selects that label and maps port 80 to container port 8080. The image name is a placeholder until the learner supplies a verified local or approved image.
| Setting | Value |
|---|---|
| Replicas | 2 |
| Pod label | app: workshop |
| Service selector | app: workshop |
| Service port | 80 |
| Container port | 8080 |
A Deployment manages a desired set of pods; a Service selects matching pods to provide a stable access point. Distinguish the controller, its pod template and the Service. A manifest describes desired state, but actual behavior requires a cluster and a compatible image. This package prepares the design without provisioning infrastructure.
Draw the Deployment–Pods–Service relationship.
Workload map
Record your result and evidence here or in a separate file.
The Service selects pod labels rather than the Deployment name alone.
Compare the selector with the pod template labels.
Keep selector labels consistent and declare container and target ports deliberately. A mismatched target port can make an apparently running pod unreachable through the Service. Avoid embedding credentials or public load-balancer settings in a learning fixture. Use a placeholder image that must be replaced before execution.
Write the Deployment and ClusterIP Service YAML.
Manifest draft
Record your result and evidence here or in a separate file.
Replicas=2 and selector labels match exactly.
Compare keys and values character by character.
Readiness determines whether a pod should receive traffic; liveness concerns restarting an unhealthy container. Probes must match the actual application and should not be copied blindly. Resource requests and limits also need workload evidence. The design should label unverified probe paths and sizing assumptions.
Add a readiness proposal and resource-assumption table.
Operational assumptions
Record your result and evidence here or in a separate file.
No untested probe is described as verified against the placeholder image.
Connect each probe to an actual application behavior to test later.
A rollout check should inspect readiness, endpoints and the served response, not only the presence of a Deployment object. Define a rollback trigger and preserve the previous known-good image reference. This exercise does not execute kubectl or a container engine in the preparation environment.
Write local-cluster validation and rollback commands as a runbook.
Execution checklist
Record your result and evidence here or in a separate file.
Commands are labeled planned, with spaces for actual results.
Do not turn expected output into a fabricated cluster log.
A design review can catch inconsistent labels and ports but cannot prove runtime reachability. Record which checks were static and which need an engine. Avoid exposing the learning Service publicly by default. The final handoff should let a learner run the case in a controlled local cluster when available.
Complete the manifest review and unresolved-assumption list.
Workload handoff
Record your result and evidence here or in a separate file.
Static review and unperformed runtime checks are clearly distinguished.
Keep the placeholder-image blocker visible.
Deliver the object map, manifests, health assumptions and rollout/rollback checklist. Deliberately change one selector in a copy and show how the review detects the broken relationship.
No placeholder image is presented as deployable or a static manifest as a running workload.
| Criterion | Points | Evidence |
|---|---|---|
| Evidence and correctness | 30 | Calculations, source use and results match the supplied case; limitations are honest. |
| Required artifacts | 30 | All five stage outputs and the capstone handoff are present and inspectable. |
| Reasoning and decisions | 20 | Choices, assumptions, alternatives and the case-specific critical condition are explained. |
| Reproducibility | 10 | A reviewer can follow the stated steps and distinguish expected from observed results. |
| Clear communication | 10 | Labels, units, structure and evidence references make the work easy to review. |
Score at least 80/100, supply every required artifact, and satisfy the path-specific critical condition. Rework missing evidence before marking complete.
The Service selector app=workshop matches the pod-template label. Port 80 forwards to targetPort 8080, which must match the actual application listener. Two replicas are desired, not claimed running. Kubernetes and container-engine execution were not performed here.
This is a reviewed workload design, not a cluster deployment, security hardening review or capacity benchmark.