Cloud Native & Kubernetes Engineering
Learn cloud-native operation from one explicit container contract through Kubernetes reconciliation, scheduling, networking, storage, identity, policy, delivery, observation, upgrades, and honestly bounded recovery evidence.
Containers, images, and the cloud-native contract
Objective Explain an image and container as separate artifacts, then validate one explicit process contract before using a container engine.
Core explanation
A process is a running program with an identity, arguments, environment, open resources, and lifecycle. An image is an immutable filesystem-and-metadata artifact used as an input to a container runtime; a container is one running process environment created from that image while still sharing the host kernel. A registry stores and distributes image artifacts, a layer is one content-addressed filesystem change, and a digest identifies exact artifact bytes. A tag such as latest is a movable name, so it cannot establish which bytes ran. A container is therefore not a tiny virtual machine, and packaging alone does not prove portability, isolation, security, or correct application behavior. A runtime contract states the command, numeric user, readable and writable paths, configuration source, network dependencies, health meanings, resource expectations, and termination deadline that the surrounding platform must supply. The Node.js program validates a teaching contract before any real image is built: it accepts an immutable digest-shaped reference, non-root user 10001, read-only root filesystem, one declared writable path, runtime configuration, and a bounded stop grace period. It rejects a controlled mutation containing a movable tag, root user, and zero-second shutdown window. This proves only deterministic validation of supplied plain values; it does not build an image, create namespace or cgroup isolation, inspect a registry, verify artifact provenance, receive an operating-system signal, or measure shutdown. The later isolated-container lab must supply those environment-specific observations.
Separate process, image, container, and host
A process is a running program; an image is immutable filesystem and metadata input; a container is a process environment created by a runtime; and the host supplies the shared kernel. These are different states, so an image can exist without running and a running container can fail even when its image was built successfully.
Namespaces can give a process different views of identifiers, networks, mounts, and users, while cgroups can account for and constrain resources. Those mechanisms reduce selected interactions but do not create a separate kernel or prove that the application, dependency, identity, filesystem, network, or data policy is safe.
Write the runtime contract before writing a Dockerfile
Name the exact process command, numeric user, configuration source, readable and writable paths, ports, outbound dependencies, health meanings, CPU and memory expectations, temporary storage, signal behavior, and shutdown deadline. Each field assigns responsibility either to the image, application, runtime, or surrounding platform.
Use an immutable digest for exact image bytes and treat a tag as a movable lookup name. A digest alone does not explain how bytes were produced, so locked inputs, source revision, build record, tests, software inventory, signature policy, and supported architecture remain separate provenance evidence.
Run and mutate the contract validator
Predict the five output lines before running the dependency-free Node.js file. The baseline accepts one digest-shaped reference, positive uid, read-only root, declared temporary path, runtime configuration, and twenty-second stop window; the unsafe fixture produces mutable-image, root-user, and unbounded-shutdown in that exact order.
Change only uid 10001 to 0 in a copied fixture and identify the one additional reason before execution. Restore the clean fixture after observing the assertion difference, because a controlled mutation teaches which decision owns the failure without turning the broken form into the learner’s starting point.
Carry the contract into one isolated engine lab
Only after the local model is understood, use the container engine already selected in DevOps to build the small prerequisite service in a disposable project. Record engine version, source identity, build command, real image digest, runtime command, numeric identity, mounts, read-only root behavior, port, health result, stop signal, measured exit time, and final cleanup.
The engine evidence belongs only to that engine, host, image, and run. A teaching digest string did not build an artifact; non-root does not eliminate kernel risk; a read-only root still permits declared mounts; a clean scan is not provenance; and one graceful stop does not prove every load or dependency failure.