Docker Cookbook

5.8 Using Cluster IP Services for Dynamic Linking of Containers | 147

---

A MySQL service can then be defined as a different type of Kubernetes object. It can
be managed through the API. A service definition for MySQL would be as follows:
kind: Service
apiVersion: v1
metadata:
name: mysql
spec:
selector:
tier: wp-mysql
ports:
- port: 3306
Note the 
selector
field in the 
spec
section. This selector will match all pods that
contain the 
tier: wp-mysql
label. The service will create a new “cluster IP” that will
be accessible to any other pod in the cluster. Any connections to this cluster IP will be
proxied and load-balanced to one of the underlying endpoints.
You can inspect the endpoints that are backing this service:
$ kubectl describe services/mysql
Name: mysql
Namespace: default
Labels:
Selector: tier=wp-mysql
Type: ClusterIP
IP: 10.0.175.152
Port: 3306/TCP
Endpoints: 10.244.1.4:3306
Session Affinity: None
No events.
Furthermore, if you are running the (highly recommended) DNS add-on, the cluster
IP will be given a logical name that can be used by any clients. You use this in your
WordPress pod configuration so that it can find the database no matter where it is.
You can see this with the 
WORDPRESS_DB_HOST
environment variable:
apiVersion: v1
kind: Pod
metadata:
labels:
tier: fe
name: wp
spec:
containers:
- env:
- name: WORDPRESS_DB_NAME
value: wordpress
- name: WORDPRESS_DB_USER
value: wordpress
- name: WORDPRESS_DB_PASSWORD
value: wordpresspwd
148 | Chapter 5: Kubernetes

---

- name: WORDPRESS_DB_HOST
value: mysql
image: wordpress
name: wordpress
ports:
- containerPort: 80
hostPort: 80
protocol: TCP
WordPress is exposed to the public Internet the same way as in 
Recipe 5.7
, through
another service of type 
LoadBalancer
:
apiVersion: v1
kind: Service
metadata:
name: wordpress
spec:
type: LoadBalancer
ports:
- port: 80
selector:
tier: fe
Discussion
Along with pods and replication controllers, services are key entities of Kubernetes.
Services bring a locality abstraction on top of pods, which is key to self-discovery and
a dynamic behavior in a large-scale cluster when failures happens. With services, a set
of pods can be given a stable name that can be reliably accessed no matter where
those pods are scheduled.
Creating a Kubernetes service will allocate a new cluster IP address for the service
that is independent of any specific pod or node. This creates a stable way to talk to the
service no matter where the implementation is running. When a calling pod then
establishes a connection to that service, it will be handled by the local Kubernetes
proxy that is running on its node. This proxy then forwards the connection to a pod
identified by the service definition (usually by a label selector). If multiple pods are
backing a service, the proxy will load-balance across those pods. See 
Figure 5-2
.