Is a container the same thing as a lightweight virtual machine?

No. A virtual machine runs its own guest kernel behind a hypervisor. A Linux container is usually a host process whose view of the system has been changed with namespaces and constrained with cgroups. That makes startup and packaging different, but it also means the host kernel is part of the security and compatibility story.

What is actually inside a container image?

An image is a content-addressed package of filesystem layers plus metadata such as the command, environment and root filesystem definition. When a container runs, those layers are mounted into a filesystem view, often with a writable layer on top. The image is the template; the running container is a process using that template.

Why does PID 1 inside a container matter?

The first process in a PID namespace has PID 1 and inherits responsibilities that application authors often forget about, such as handling signals and reaping child processes. If a server process runs directly as PID 1 and ignores those behaviours, shutdowns can be messy and zombies can accumulate. Many setups add a tiny init process for this reason.

Are files changed inside a container saved?

It depends where the file is written. Changes in the container’s writable layer belong to that container instance and normally disappear when it is removed. Data that must survive should be written to an explicit volume, bind mount or platform storage abstraction such as a Kubernetes PersistentVolume, not just to the image filesystem.

Containers

A container is a process run with isolated Linux namespaces, cgroup resource controls, and a packaged root filesystem. It is not a small virtual machine: the host kernel still runs the process, but the process sees its own filesystem, network, process tree, hostname and limits.

Containers are necessary because ordinary processes share too much of a machine by default. An application can depend on files that happen to exist on the host, collide with ports, inspect other processes, or consume memory until unrelated workloads fail. Packaging alone does not solve this, and isolation alone does not make deployment repeatable. A container combines a controlled view of the system with a filesystem assembled from the application’s image.

Concretely, a runtime such as runc starts a normal Linux process with namespace flags. A PID namespace makes the process appear as PID 1 inside, while the host sees a different PID. A mount namespace points it at an image root filesystem, often built with OverlayFS layers. A network namespace gives it separate interfaces and routes, commonly joined to the host through a veth pair and bridge. Cgroups account for and enforce CPU and memory limits.

The trade-off is that containers share the host kernel, so the boundary is weaker than a full virtual machine and depends heavily on kernel features, runtime configuration and privileges. Root inside a container is commonly misunderstood: it is not automatically harmless, especially with host mounts or the Docker socket. Resource limits are also real limits, not hints; exceeding a cgroup memory ceiling can get the process killed even when the host has spare RAM.

Engineers meet containers through Docker, Kubernetes, Cloud Run, Lambda container images, CI jobs and local development environments. The practical debugging surface is not magic: inspect the image layers, the writable layer, the cgroup path, the mounts, the network namespace and the process running as PID 1. When a container “exits”, usually its main process ended; in Kubernetes that becomes container state, restart behaviour and sometimes an OOM diagnosis.

Go deeper

DeploymentContainersTake a container apart into namespaces, cgroups and a root filesystem, so it stops being a black box.Open the lesson

Common questions

Is a container the same thing as a lightweight virtual machine?: No. A virtual machine runs its own guest kernel behind a hypervisor. A Linux container is usually a host process whose view of the system has been changed with namespaces and constrained with cgroups. That makes startup and packaging different, but it also means the host kernel is part of the security and compatibility story.
What is actually inside a container image?: An image is a content-addressed package of filesystem layers plus metadata such as the command, environment and root filesystem definition. When a container runs, those layers are mounted into a filesystem view, often with a writable layer on top. The image is the template; the running container is a process using that template.
Why does PID 1 inside a container matter?: The first process in a PID namespace has PID 1 and inherits responsibilities that application authors often forget about, such as handling signals and reaping child processes. If a server process runs directly as PID 1 and ignores those behaviours, shutdowns can be messy and zombies can accumulate. Many setups add a tiny init process for this reason.
Are files changed inside a container saved?: It depends where the file is written. Changes in the container’s writable layer belong to that container instance and normally disappear when it is removed. Data that must survive should be written to an explicit volume, bind mount or platform storage abstraction such as a Kubernetes PersistentVolume, not just to the image filesystem.

Every term