liveBook · Manning

Container

As explained in Kubernetes for Developers

A container instance is a runtime invocation of a container image that persists as a Docker-managed container until it is removed.

When several applications share a machine, their dependencies and resource needs can interfere with one another. A container runs an application and its dependencies in an isolated environment without requiring a separate operating system kernel for each application. This makes containers lighter than virtual machines while retaining much of their isolation. section 1.1 section 1.1.1

An image and a container are not the same thing. An image is a file artifact, either downloaded or built locally. A container instance—usually called a container—is one invocation of that image. Each local Docker invocation creates an instance that remains Docker-managed after its process stops, until it is cleaned up. section 2.1.2

Try an isolated shell

Run `docker run -it ubuntu bash` to start an interactive shell from the Ubuntu image. Commands in that shell run inside the container: installing Python there does not install it on your local system. Exit the shell to stop the container; the stopped instance remains available. section 2.1.2

$ docker ps -a
CONTAINER ID   IMAGE     COMMAND    CREATED         STATUS                  
c5e023cab033   ubuntu    "bash"     5 minutes ago   Exited (0) 1 second ago
 
$ CONTAINER_ID=c5e023cab033
$ docker start $CONTAINER_ID
$ docker attach $CONTAINER_ID
# echo "run more commands"
# exit

The command sequence lists a stopped container, starts it by ID, and attaches to its shell again. It illustrates why stopping a local container is different from removing it. section 2.1.2

Containers also separate projects with different languages, libraries, or package versions. A Dockerfile records how to build the image, helping reproduce the environment in development and production. Local container instances still need housekeeping: repeated runs can leave many stopped containers using disk space. section 1.1.1 section 2.0 section 2.1.2

In Kubernetes, containers run inside Pods. A Pod may contain one container or several scheduled together; a Deployment can request multiple replicas of a Pod. Kubernetes configuration names images rather than persistent Docker instances: the container instances are created at runtime and deleted when their Pod stops. section 1.2.1 section 2.1.2

How Kubernetes for Developers covers it

How deep it goes
Distinguishes images from runtime instances and walks through starting, stopping, and reconnecting to one; does not examine container internals.
Examples
Uses an Ubuntu shell, an in-container Python installation, and Docker commands that revisit a stopped instance.
What it assumes
Introduces containers through familiar application-hosting problems before using Docker commands; requires no prior Kubernetes knowledge.
What you can do after
Operate/configure it with Docker by running an image, recognizing the resulting instance, and restarting a stopped container.
How it connects
Connects containers to images, Dockerfiles, virtual machines, Pods, and Deployments.

Also explained in

Compare how 27 books explain container →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Kubernetes for Developers. The section links point to the parts of the book it draws on.