Container & Orchestration Concepts

A container is several fences applied at once: its own root filesystem, process table, network stack, host identity and inter-process channels, plus an accounting group that caps what it consumes. The kernel underneath stays shared.

Passing the CPU ceiling only slows a process: it is throttled, waits for the next period's quota, and stays alive. Passing the memory ceiling ends it — there is no memory throttle, so the kernel kills a process inside the boundary.

Root inside a container is an id read in that container's own view, and the runtime already trimmed its privilege set, so host-wide powers like setting the clock are missing. Many setups also map that id onto an unprivileged host id.

A container shares the host's already-running kernel; a virtual machine boots a guest kernel and a whole system of its own from a disk image. Sharing removes the boot, so a container starts a process in milliseconds instead of booting a machine.

The fences hide other workloads; they do not rewrite the interfaces that report machine capacity. Those numbers come from the shared kernel's host-wide view, while the container's ceiling lives in an accounting group nobody told the process about.

A tag is a label a publisher attaches and can re-attach to different content at any time, while a digest is computed from the image's own bytes — change one byte and it is a different digest, so nothing can republish under the old one.

A pull moves only the layer blobs a host is missing. A host that already holds most of them reads a manifest and little else, while a host with an empty content store has to transfer every layer and expand it to disk.

A union filesystem stacks the layers and serves one merged tree: for any path the highest layer that mentions it wins, so an upper layer's copy hides the identical path in every layer beneath it. The lower bytes remain in the image.

The reference is parsed and resolved at the registry to a manifest and its digest, the client proves it may read that repository, the manifest is read for the blobs it lists, and only the digests the host lacks are fetched, checked and expanded.

Layers are append-only and immutable. The later layer records a deletion marker that hides the path, but the bundle's bytes stay in the earlier layer, so they are still stored, still transferred to every host that fetches the image, and still counted in its size.

Everything the distribution shipped that the process does not carry itself: the shell and its utilities, the package manager, usually the trusted-certificate store, timezone and locale data, and most system libraries. Only the artifact and whatever the build copied in remain.

Everything under the directory the build was pointed at, recursively, minus whatever the ignore rules exclude. That packaged set is the build context, and it is transferred before step one. An instruction can only read files that are inside it.

Everyone who can pull the image, and everyone already holding a copy of it. The value sits in a read-only layer and in the build record that travels with it, so pull access is credential access.

Each build step's reuse depends on the layer it starts from. The edit changed the inputs of the step that copies that file, so the step ran again and wrote a new layer - and every later step then started somewhere new and missed.

A single-stage build ships everything the build needed, not only what the run needs: the compiler toolchain, development headers, the whole source tree, intermediate output and package-manager caches all stay in the image's layers beside the 40 MB artifact.

Each restart attempt is a new instance with a fresh output stream, so a request for the logs returns the attempt that just started, not the one that failed. Read the previous attempt's retained output instead.

Failing a liveness check costs the instance its life: the platform ends the process and starts a fresh one, discarding everything in memory. Failing a readiness check costs it only traffic: it leaves the routing set, keeps running, and rejoins when it passes again.

The exit code is the container's own verdict on its run: zero means the work completed, any non-zero value means it did not. At stop time the supervisor branches on that one number, not on anything the job printed.

A long-running service wants restarting whenever it ends, because any ending is abnormal. A run-to-completion job wants restarting only when it ends badly, so that a successful run is not repeated forever.

Because removal from the routing set is not instant. For a few seconds after the stop request, callers are still being sent here, and a closed listener turns each one into a connection failure. Leave the routing set first, keep serving while that propagates, then refuse new work.

A host path hands the container a directory that already exists on whichever machine it runs on. A platform-provisioned volume is storage the platform creates, tracks as its own object, and re-attaches wherever the workload lands.

The write landed in that instance's own thin writable layer, a private area created empty on top of the read-only image. Replacing the instance discards the layer, and nothing written only there is kept or recoverable.

Mounted storage keeps the ownership and mode bits it has outside the container, and the check compares numeric ids: if the process is neither the owner nor in the owning group, only the others bits apply — which rarely include write.

The platform treats the declaration as a request: it looks for an existing backing store that satisfies the size and writer count, or creates one on demand, then binds the request to that one store. The workload starts only after binding.

A data-owning copy holds data no other copy has, so the replacement is useful only if it comes back as that same copy. A durable per-copy name plus storage bound to that name, not to the instance, is what makes that possible.

Each container normally gets its own network view: its own interface, its own address and its own loopback. So localhost inside a container means that container itself, and nothing is listening there. Reach the other container by its address or its name.

A host port is an exclusive claim on a host address, so only one mapping can hold it there. Inside, each container has its own network view, so both processes can hold 8080 without ever meeting.

Publishing claims a port on the host and installs an address-translation rule, so traffic arriving at that host port is rewritten and delivered to the container's own address and port. The process inside binds nothing on the host and is unchanged.

Four entry shapes: internal-only, a port reserved on every host, a balancer provisioned for that one workload, or a shared edge routing many hostnames and paths. They trade cost per external address against routing power and blast radius.

The bind address decides which interfaces a listener will accept traffic on. Bound to loopback, it accepts only what arrives on that view's loopback; traffic from outside arrives on the container's other interface and is never delivered to it.

A control loop runs continuously, reading the live state, comparing it with the declared spec and acting on the difference. A copy count raised by hand is exactly such a difference, so the next pass removes the extra copies.

The control plane decides: an API, the state store behind it, and the scheduler and controllers that act on declared state. Each host's node agent runs and supervises the containers assigned to that host, alongside the workloads themselves serving traffic.

Members of a co-located group share one host, one network address and port space, and a scratch area every member can mount. The group is also what the platform places, replaces and deletes — never one member on its own.

The platform's control loop sees four copies where the spec declares five and starts a fifth. The replacement is a new instance built from the same spec: new address, empty writable layer, cold caches. Nothing from the dead copy is recovered.

They disagree about what a process exiting means. A replicated long-running service must never exit, so the platform recreates any copy that does. A run-to-completion job is supposed to exit once; a clean exit is the whole point and ends it.

Replica autoscaling watches a load signal - processor utilisation, queue backlog, requests in flight - and compares it against a configured target, adding copies while the signal sits above that target and removing them while it sits below.

Stopping all six copies leaves the shared name with no copy able to serve until a replacement finishes starting, so every request in that window fails. Replacing a batch at a time keeps the rest serving throughout.

Because those copies are not interchangeable. Each owns a slice of durable data and a name the replacement must reclaim, and the group needs a majority alive, so only one may be missing at a time.

The signal does not track the pain. A rendering worker that spends most of its time waiting on downloads and uploads shows modest processor use even while items pile up, so the measurement never crosses its target and the copy count never rises.

A revision is a snapshot of the entire declared spec at one apply - image reference, copy count, reservations, ceilings and settings together. Reapplying an earlier revision runs a normal forward rollout whose target happens to be that older spec.

Delivery and consumption are separate events. The process parsed the file once at start-up and serves from that in-memory copy; nothing re-reads it unless the process was written to, so the old value stands until it re-reads or is replaced.

Only the values supplied around the artifact may differ: endpoints, credentials, copy count, verbosity, feature switches. The image bytes stay identical, because identical bytes are what makes an earlier environment's test evidence mean anything in production.

Everyone who can obtain the artifact holds the credential, because the value travels with the image to every registry, mirror, host and environment it reaches. Changing it means building a new artifact and rolling it out, so rotation becomes a release.

Two shapes: a flat set of name-value pairs the process inherits when it is created, or a directory of files mounted into its filesystem. The choice decides who else can read the value and what changing it costs.

Reload on a signal fails when nothing sends the signal to every instance, or the handler rebuilds only part of the state. Watching the file fails when the watcher misses a whole-directory swap, storms on repeated events, or dies silently and never updates again.

Privileged mode hands the container the host's full privilege set, reachable host devices and no confinement profile, so the process can reconfigure the machine. The per-resource views and the resource ceilings usually remain, which is why it still looks contained.

A read-only root filesystem refuses every write except into paths declared writable, so the renderer needs one mounted at its scratch directory and its temporary-file setting pointed there. Declare the size and the owning id too, or it breaks again.

Running as the superuser hands any code-execution bug full in-container privilege: it can rewrite the program files the running process reads, open every mounted credential regardless of ownership, and exploit whatever the boundary fails to close. An unprivileged, explicitly declared numeric id removes that head start.

Anything that can reach the runtime's control socket can ask it to create a privileged container with the host's filesystem mounted in, and the runtime obeys as a host-level process. No privilege inside the calling container is needed.

An admission gate runs after a workload spec is submitted and before the platform stores or schedules it. It reads the spec and the image reference the spec names, then admits the request or refuses it outright.

The container's own figure decides: usage is accounted inside its boundary and judged against the ceiling declared for it. The host's free memory is capacity this workload may never use, so 92% means it is near being killed.

A container platform's log contract is the process's standard output and error streams — the runtime captures those. A file written inside the container is outside that capture, so nothing collects it, and it is gone when the instance is replaced.

Four separate failures look identical from outside: the image never arrived on the node, the start was refused before any code ran, the process started and died, or it runs and never reports ready. Naming which one is the first move.

It asked the system how many processors the machine has, and the host answered. The pool and its per-worker buffers are sized for hardware it never gets, so workers contend for one small run-time allowance.

Everything that needs a program inside the container: no interactive session, no install, no file viewing, no probing from within. What is left is a joined debug container, the instance's retained output, copying a file out, and a local rebuild with tools added.