Docker Cookbook

Discussion
Recipe 5.1
 mentioned that every node in a Kubernetes cluster runs a 
kubelet
. This
process watches over the pods that are scheduled on a node and makes sure they keep
running. But what happens if the node dies? Kubernetes needs to have a way to
reschedule that pod on another node automatically as well as keep a number of repli‐
cas up for availability. This is what replication controllers help you achieve.
Although replication controllers are extremely helpful for guaranteed availability and
elasticity, they are also a great way to perform application deployment scenarios such
as canary deployment. In fact, Kubernetes has a built-in rolling update mechanism
based on replication controllers that is worth investigating:
5.6 Using a Replication Controller to Manage the Number of Replicas of a Pod | 143

---

$ ./kubectl rollingupdate -h
Perform a rolling update of the given ReplicationController.
Replaces the specified controller with new controller, updating one pod at a time
to use the new PodTemplate. The new-controller.json must specify the same
namespace as the existing controller and overwrite at least one (common) label
in its replicaSelector.
...
See Also
• Documentation on 
replication controllers
5.7 Running Multiple Containers in a Pod
Problem
You know how to run a single container in a pod, but would like to run multiple ones
that will be co-located. You might already have some containers in production that
use the Docker linking mechanism on a single host and would like to use Kubernetes
to do the same.
Solution
A pod definition is not restricted to a single container. You can define as many con‐
tainers as you want, as well as volumes. 
Recipe 5.4
created a simple pod definition
that started a single container. The following example starts WordPress by using the
official images from Docker Hub for WordPress and MySQL. Both run as separate
containers and use environment variables to configure the installation. The Word‐
Press container defines the database host through the environment variable 
WORD
PRESS_DB_HOST
and sets it to 127.0.0.1. This allows WordPress to reach the MySQL
database also started within the pod. This works, because pods get a single IP address
in the current Kubernetes networking model (see 
Recipe 5.2
). Create the following
wordpress.yaml
file:
apiVersion: v1
kind: Pod
metadata:
labels:
name: wp
name: wp
spec:
containers:
- name: wordpress
env:
- name: WORDPRESS_DB_NAME