Docker Cookbook

130 | Chapter 5: Kubernetes

---

Pods
A group of containers that 
must
be placed on a single node and work together as
a team. Allowing a set of containers to work closely together on a single node is a
powerful way to make applications even more manageable.
Labels
Data attached to pods in order to organize a group for monitoring and manage‐
ment.
Replication controllers
Agents that work to make sure that a horizontal scaling group or pod is reliably
maintained.
Network services
A way to communicate between not just pods, but groups of pods by using
dynamically configured naming and network proxies.
With that, let’s jump into understanding and using Kubernetes!
5.1 Understanding Kubernetes Architecture
Problem
You need a container management system that provides scale and fault-tolerance, and
you would like to understand the architecture of Kubernetes (see 
Figure 5-1
).
Solution
The main architecture of a Kubernetes cluster includes the following:
Kubernetes master services
These centralized services (that can run in Docker containers) provide an API,
collect and surface the current state of the cluster, and assign pods to nodes. Most
users will always interact directly with the master API. This provides a unified
view of the entire cluster.
Master storage
Currently all persistent Kubernetes state is stored in 
etcd
. New storage engines
likely will be built out over time.
Kubelet
This agent runs on every node and is responsible for driving Docker, reporting
status to the master, and setting up node-level resources (like remote disk stor‐
age).
5.1 Understanding Kubernetes Architecture | 131

---

Kubernetes proxy
This proxy runs on every node (and can run elsewhere) and provides local con‐
tainers a single network endpoint to reach an array of pods.
Figure 5-1. Kubernetes architecture
Discussion
A user interacts with a Kubernetes master through tools (such as kubectl) that call the
Kubernetes API. API documentation (automatically generated from source) is avail‐
able on 
the Kubernetes site
. The master is responsible for storing a description of
what users want to run (referred to as a 
spec
in the API). It then works to turn that
specification into reality. It reports the current state of the cluster as status.
Running on every worker node in the cluster are the kubelet and the proxy. The
kubelet is responsible for driving Docker and setting up other node-specific states,
like storage volumes. The proxy is responsible for providing a stable local endpoint
for talking to services (frequently implemented by a set of containers running in the
cluster).
Kubernetes works to manage pods. 
Pods
are a grouping of compute resources that
provide context for a set of containers. Users can use pods to force a set of containers
that work as a team to be scheduled on a single physical node. While simple applica‐
tions can be built as a single container, pods help to enable advanced scenarios: