A county library app Dockerfile copies source, runs npm install, then leaves compilers and caches in the final image. How should the team shrink the runtime image?

County library teams often leave compilers, npm caches, and source trees in the final image after a single-stage Dockerfile. A multi-stage build fixes that: an early builder stage runs npm install and compiles assets, then a final runtime stage copies only the built artifacts into a slim base. The resulting OCI image for the library app contains what patrons’ sessions need at runtime, not the scaffolding used at build time. CKAD expects this pattern because it directly shrinks pull size and attack surface while keeping the build reproducible in CI.

Deleting node_modules on cluster nodes after each Deployment rollout fails because those directories live inside container layers, not as durable node packages you can mop up after scheduling; even if you exec and delete, the next pull recreates the fat image. Forcing imagePullPolicy to Never does not shrink the image; it only risks ImagePullBackOff when workers lack local layers. Converting the Dockerfile into a DaemonSet fails conceptually: DaemonSets schedule Pods, they do not replace image build stages or remove build tools from an application image.

Exam caveat: multi-stage is about separating build and runtime layers in the Dockerfile (or equivalent CI), not about init containers or node agents. Do not confuse build-time npm install with a runtime sidecar.

Operational check: compare image sizes before and after the multi-stage change, inspect the final stage for absence of compilers, roll a Deployment, and confirm Pods become Ready with faster pulls via kubectl get events and kubectl describe pod.