2 Understanding containers and containerized applications

This chapter provides a practical and conceptual foundation for working with containers as the unit of deployment that Kubernetes manages. It contrasts containers with virtual machines, highlighting lower overhead, faster startup, and different isolation trade-offs when multiple workloads share a single kernel. The narrative introduces the core container workflow and vocabulary—images, registries, and running containers—along with portability caveats such as reliance on host kernel features and CPU architecture compatibility. It also situates Docker within a broader, standards-based ecosystem, explaining the roles of the Open Container Initiative and Kubernetes’ Container Runtime Interface with implementations like containerd and CRI-O.

Readers are guided through a hands-on journey using Docker: pulling and running existing images, understanding tags and variants, and then building, running, and inspecting a simple microservice-based demo application. The chapter demystifies Dockerfiles, image layering, and copy-on-write behavior, showing why layers improve distribution and storage efficiency while warning about operations that inflate image size. It covers the end-to-end workflow from local builds to remote distribution via an image registry, and demonstrates everyday container operations—port mapping, listing and inspecting containers, viewing logs, stopping and restarting containers, and cleaning up images—so that the same images can later be orchestrated by Kubernetes.

Under the hood, the chapter explains the Linux kernel features that make containers possible. Namespaces provide each process with a customized view of system resources (filesystems, PIDs, networking, hostname, users, time, and cgroups), enabling isolation and selective sharing across processes. Control groups enforce resource governance by limiting CPU and memory consumption. Security hardening is addressed by running without elevated privileges, granting only necessary capabilities, filtering syscalls with seccomp, and leveraging mandatory access controls such as AppArmor and SELinux. Together, these mechanisms deliver strong isolation and predictable resource usage for containerized applications while clarifying the differences from the stronger but heavier isolation of virtual machines.

Running applications in VMs vs. containers

How apps use the hardware when running in a VM vs. in a container

The difference between running applications on bare metal, in VMs, and in containers

The three main Docker concepts are images, registries, and containers

Building a container image

Uploading a container image to a registry

Running a container on a different computer

Containers can share image layers.

If a container requires specific kernel features or modules, it may not work everywhere.

Running echo “Hello, World!” in a container based on the busybox container image

A screenshot of the Kubernetes in Action Demo Application (Kiada)

The architecture and operation of the Kiada application

The operation when the client requests the text version

Building a new container image using a Dockerfile

Visualizing your running container

The network namespace limits the accessibility of network interfaces.

Each process is associated with multiple namespace types, some of which can be shared.

The PID namespace makes a process sub-tree appear as a separate process tree with its own numbering sequence.

• Containers are regular processes that are isolated from each other and all other processes in the host OS.
• Containers are much lighter than VMs, but because they use the same Linux kernel, they are not as isolated.
• Docker was the first container platform to make containers popular and the first container runtime supported by Kubernetes. Now, other containers are supported through the Container Runtime Interface (CRI).
• A container image contains the user application and all its dependencies. It is distributed through a container registry and used to create running containers.
• Containers can be downloaded and executed with a single docker run command.
• Docker builds an image from a Dockerfile that contains commands to execute during the build process. Images consist of layers that can be shared between multiple images. Each layer only needs to be transmitted and stored once.
• Containers are isolated by Linux kernel features called namespaces, control groups, capabilities, seccomp, AppArmor, and/or SELinux. Namespaces ensure that a container sees only a part of the resources available on the host, control groups limit the amount of a resource it can use, while other features strengthen the isolation between containers.

FAQ