FAQs

Is a container just a process? Essentially yes - a process (or tree) wrapped in namespaces and cgroups with an image-provided root filesystem.

Why can containers start in milliseconds? There is no kernel boot or hardware initialization; the runtime just sets up namespaces and execs your binary.

Can two containers share memory or PIDs? Only if you explicitly share a namespace, which pods do for the network namespace and optionally the PID namespace.

Does a container need an init process? For simple apps, no, but a minimal init (or --init) reaps zombies and forwards signals correctly when your app spawns children.

Are Windows containers the same idea? Conceptually yes, but they use Windows kernel isolation primitives and require a Windows host or Hyper-V isolation.

Why does my container see all host CPUs? Cgroup limits constrain scheduling, but /proc often still reports host topology, so size runtimes from limits explicitly.

Are containers less secure than VMs? The default boundary is weaker because the kernel is shared, but hardened containers plus sandbox runtimes narrow the gap substantially.

Do containers run inside VMs in the cloud? Almost always - your Kubernetes nodes are VMs, and pods are containers sharing each node's kernel.

Why are containers so much faster to start? They skip hardware init and kernel boot; the runtime just sets up namespaces and cgroups and execs your process.

Can I run Windows and Linux containers together? Not on the same node kernel - they need matching host kernels, so you schedule them onto different node pools.

When should a tech lead still pick VMs? For untrusted multi-tenancy, compliance boundaries requiring separate kernels, or workloads needing a specific or custom kernel.

Does gVisor make containers as safe as VMs? It meaningfully reduces host kernel attack surface, but a full VM or Kata still offers a stronger hardware-backed boundary.

Is a Docker image different from an OCI image? In practice no - modern Docker builds OCI-compliant images, and the container ecosystem treats them as the same artifact.

What actually guarantees interoperability? Compliance with the OCI image, runtime, and distribution specs, which fix the format, the run contract, and the registry API.

Why pin by digest instead of tag? A digest is the content hash and is immutable, so it defends against silent repushes and makes deployments reproducible.

How does multi-arch work under one tag? An image index maps the tag to per-platform manifests, and the client selects the one matching its architecture.

Does Kubernetes use the runtime spec directly? Indirectly - the kubelet calls containerd over the CRI, and containerd invokes an OCI runtime (runc) that implements the runtime spec.

Can I store Helm charts or SBOMs in a registry? Yes - the distribution spec plus referrers lets registries hold OCI artifacts beyond images, which tools like ORAS and cosign use.

What is the one-line difference? Namespaces control what a process can see; cgroups control how much it can use.

Why is my container OOM-killed with free host memory? Because its memory cgroup limit, not host memory, is the ceiling the kernel enforces.

Do CPU limits kill my pod? No - CPU limits throttle scheduling, adding latency; only memory limits cause OOM kills.

Why do pod containers share localhost? They share one network namespace, so they see the same loopback and pod IP.

Are namespaces enough for security? No - combine them with non-root users, dropped capabilities, seccomp, and read-only rootfs, or a sandbox runtime.

Can I inspect the applied limits? Yes - read /sys/fs/cgroup/... inside the container or check node cgroup paths to see memory.max and cpu.max.

Does immutable mean nothing can be written at runtime? No - the artifact is immutable, but you still write to mounted volumes and scratch space; only the baked image and OS should not change in place.

Where do config and secrets go then? Injected at runtime via ConfigMaps, Secrets, or an external secrets manager, so the image stays constant across environments.

How do I roll back? Redeploy the previous image digest; because releases are versioned artifacts, the prior state is exactly reproducible.

Is SSHing into a pod ever OK? For read-only debugging, yes; for fixing state that must persist, no - make the change in the image and redeploy.

How does this relate to GitOps? GitOps stores the desired immutable state (pinned images plus manifests) in Git and reconciles the cluster to it automatically.

What about stateful workloads? Keep the compute immutable and push durable state to PVCs or managed data services so the container remains disposable.

Is one process per container a hard rule? It is a strong default, not dogma; sidecars and rare supervised apps are fine when justified and documented with a real init.

Requests or limits - which matters more? Requests drive scheduling and are almost always worth setting; memory limits protect the node, while CPU limits should be used sparingly to avoid throttling.

Why non-root if the container is isolated? Isolation is not a hard boundary, so non-root plus dropped capabilities limits the damage if the process is compromised or escapes.

Do these apply to Docker Compose dev setups too? Many do (non-root, pinned bases, one concern), but the security and resource controls are enforced by Kubernetes in production, not Compose.

How do I enforce this without nagging? Push checks into CI and admission control - scanning, signing, and the restricted Pod Security Standard - so violations are blocked automatically.