Containers

Two namespace outlines contain left0 and right0 as one paired link; the right namespace also owns a loopback destination.

A veth pair carries frames between two endpoints; routing supplies their meaning

A veth pair consists of two interconnected virtual Ethernet devices. A frame transmitted through one is delivered to the other, where the receiving network stack or bridge handles it. The two ends can reside in separate Linux network namespaces, making the pair useful for container networking. Creating the pair supplies a link; addresses, routes, bridge membership, forwarding, and access policy are additional configuration. ...

A constrained process cannot write to the read-only root but can use its designated writable working volume.

Security context defines constraints that need runtime evidence

A Kubernetes securityContext configures process identity and selected operating-system constraints. It can reduce what a compromised application is permitted to do, but it does not establish a complete security boundary by itself. Start with the operations the application actually needs, configure the appropriate fields, and test both a permitted operation and a forbidden one in the resulting container. ...

A digest is bound to a signer while build provenance remains a separate evidence lane.

Image signatures bind a digest to a trusted signer

A container image tag is a mutable pointer; a digest identifies content. A valid signature binds a signed statement about that digest to a signing key. Whether that key represents an authorized person or workload is a trust-policy decision. Signing alone does not prove who built the image, that the build followed a claimed process, or that the resulting software is safe. ...

A pinned base fixes one input; the release needs the rest

Pinning a container base by digest fixes the referenced image object instead of relying on a movable tag. That removes one source of unexpected build changes, but it does not make every derived image or running instance identical. Application source, build arguments, fetched dependencies, target platform, runtime configuration, and persistent data can still change what gets built and how it behaves. ...

Within one Pod a regular prepare init retries, then transform completes, then the application starts; all mount the same emptyDir.

Regular init containers establish startup prerequisites

A regular init container performs setup before a Pod’s application containers start. It has its own command, image and filesystem view, and can mount a volume that the application later reads. This separates a prerequisite from the main process, but does not make arbitrary setup safe or automatically bounded. Design the step around its actual retry behavior and the lifetime of its output. ...

Container A and container B each see a process at PID 1 and their own loopback address. Both use the same daemon-side Linux kernel.

A container combines process isolation with a shared Linux kernel

A conventional Linux container runs processes using the daemon host’s Linux kernel while providing selected isolated views through namespaces. Image files supply a userspace environment; they do not boot a separate kernel for each container. On Docker Desktop for macOS, the daemon and Linux containers run inside a Linux virtual machine, so the shared kernel is that VM’s kernel, not the macOS kernel. ...

Three cgroup controller lanes show CPU bandwidth throttling, memory reclaim with possible OOM, and task-creation refusal. The budgets belong to one hierarchy.

cgroup v2 enforces different budgets with different failure modes

cgroup v2 organizes resource control in a unified hierarchy. A workload’s processes can share aggregate budgets, with limits inherited through the hierarchy rather than applied only to one particular PID. CPU bandwidth, memory usage, and task count are separate controllers with different enforcement behavior. Reading the actual cgroup files and failure counters is more useful than treating every configured limit as the same kind of hard stop. ...

Selected program output crosses from a large builder to a runtime stage with its own base and required runtime files. Compiler and source do not automatically follow.

Multi-stage builds need a tested runtime boundary

A multistage Dockerfile can compile software in one stage and copy selected outputs into another stage that becomes the runtime image. The final stage inherits its own base and the files explicitly copied into it, rather than automatically inheriting the builder’s compiler, source tree, and package caches. This creates a useful boundary, but the author must still identify everything the program needs when it executes. ...