Docker Cookbook

Pods Get Scheduled Only Once
After a pod is scheduled on a node, it will never be moved. If that node is lost or
removed from the cluster, the pod will not be restarted. This is surprising behavior
given that a goal of Kubernetes is to reliably keep work running. This is required, as
networks are imperfect. In the event that the master cannot talk to a node, any pod on
5.1 Understanding Kubernetes Architecture | 133

---

that node is in an indeterminate state as far as the master is concerned—it may or
may not be running. If that same pod were restarted on another machine, two pods
with the exact same name/identity could be running at the same time. This can cause
all sorts of problems. For instance, distributed logs might be written from multiple
places, all keyed to the same pod ID. Or the pod ID may be used as part of a master
election system, and clients may be confused as to which pod is really the master.
Instead, to reliably run a workload, it is necessary to use a replication controller. This
takes a pod template and tries to ensure that a specific number of pods is always run‐
ning to accomplish that task. In the case of the master not being able to talk to a node,
a replication controller is in charge of spinning up a new pod to replace the lost pods.
If communication is reestablished, it is up to the replication controller to delete one of
the redundant pods.
5.2 Networking Pods for Container Connectivity
Contributed by Joe Beda
Problem
You want to control how network traffic is directed to your containers as they are
scheduled across a Kubernetes cluster.
Solution
Use a networking subsystem that gives each container its own IP address so that each
can be addressed directly.
Shipping with Kubernetes are a set of scripts that make it easy to launch in various
clouds. Many of these cluster deployment systems set up the network appropriately
for you automatically. However, if you are digging into the details, an easy system to
start with is 
Flannel
from CoreOS (see 
Recipe 6.1
).
Other options include the following:
• Build in internal network routing for the cloud you are running on. Support is
built in for GCE and Amazon EC2.
•
Project Calico
 for larger bare-metal deployments.
•
Weave
for a solution that supports encryption across wide areas (see 
Recipe
3.11
).
The solution is to use Kubernetes services. These can be used to communicate
between containers within a cluster or to direct external traffic to a set of pods.