Docker Cookbook

132 | Chapter 5: Kubernetes

---

•
Multiple Docker containers
can exist in a pod. This allows for some advanced sce‐
narios explored in 
Recipe 5.7
. Each container starts with its filesystem and pro‐
cess as normal.
• Pods define a 
shared network interface
. Unlike regular containers, containers in a
pod all share the same network interface. This allows for efficient and easy access
across containers using 
localhost
. It also means that different containers in the
same pod cannot use the same network port.
•
Storage volumes
are defined as part of the pod. These volumes can be mapped
into multiple containers as needed. Specialized types of volumes also exist, based
on the needs of users and the capabilities of the cluster.
Here is the general flow for how work is run with Kubernetes:
1. Via the kubectl tool and the Kubernetes API, the user creates a specification for a
replication controller with a pod template and a count for the number of desired
replicas.
2. Kubernetes uses the template in the replication controller to create a number of
pods.
3. The Kubernetes Scheduler (part of the master) looks at the current state of the
cluster (which nodes are available and what resources are available on those
nodes) and binds a pod to a specific node.
4. The kubelet on that node watches for a change in the set of pods assigned to the
node it is running on. It then starts up or kills pods as necessary. This includes
configuring any storage volumes as necessary, downloading the Docker image to
that specific node, and calling the Docker API to start/stop individual containers.
Fault-tolerance is implemented at multiple levels. Individual containers within a pod
can be health checked and monitored by the local kubelet. If pods stop or fail, they
can be restarted automatically. If the entire node fails, the master will notice this and,
after a time-out to make sure the node does come back, delete all of the pods on that
node. At that point, replication controllers (if used) will create replacements for pods
that were on that node. Multiple levels of monitoring and restarting help to keep
applications running even when the cluster is experiencing problems (software or
hardware).