Docker Cookbook

144 | Chapter 5: Kubernetes

---

value: wordpress
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: wordpresspwd
- name: WORDPRESS_DB_HOST
value: 127.0.0.1
image: wordpress
ports:
- containerPort: 80
hostPort: 80
- name: mysql
env:
- name: MYSQL_ROOT_PASSWORD
value: wordpressdocker
- name: MYSQL_DATABASE
value: wordpress
- name: MYSQL_USER
value: wordpress
- name: MYSQL_PASSWORD
value: wordpresspwd
image: mysql
ports:
- containerPort: 3306
Create the pod:
$ kubectl create -f wordpress.yaml
Once the containers start, you will have a working WordPress installation.
You can view the logs of the containers in your pod with the
kubectl
client:
$ kubectl logs wp wordpress
Here, 
wp
is the name of the pod you started and 
wordpress
the
name of the container you want to see the logs from.
Discussion
Although starting multiple containers through a pod is straightforward, accessing the
application running within a pod requires using Kubernetes 
services
. Each pod gets
its own IP address in a private network. To access an application from outside the
Kubernetes cluster through a public IP address, you need to create a service that will
bind the application to a public IP address or make use of an external load-balancer
service.
In Google Container Engine, using an external load-balancer in a service definition is
done directly in the YAML file describing the service. For instance, to expose the
5.7 Running Multiple Containers in a Pod | 145

---

WordPress application that is running through the pod defined in this recipe, you
need to create the service file 
sgoogle.yml
like so:
apiVersion: v1
kind: Service
metadata:
labels:
name: wordpress
name: wordpress
spec:
createExternalLoadBalancer: true
ports:
- port: 80
selector:
name: wp
The service has metadata associated with it, but the important part is the selector filed
in the 
spec
section. In the preceding example, the selector 
wp
will allow the service to
create a proxy that will bind the IP address given by the load-balancer to the pod that
matches the 
wp
label. Once you obtain the IP address of the load-balancer, you can
access it from the public Internet. The Kubernetes service will proxy the request to
the node where the pod is running. If the pod has been started with a replication con‐
troller, the service will also load-balance the requests among all the running pods.
On a cloud provider whose load-balancing system is not yet supported by Kuber‐
netes, you can bind the pod to a public IP address manually with a service definition
like this (where 
1.2.3.4
needs to be replaced with the public IP):
apiVersion: v1
kind: Service
metadata:
labels:
name: wordpress
name: wordpress
spec:
publicIPs: [
"1.2.3.4"
]
ports:
- port: 80
selector:
name: wp