Exposing the Redis master service

With plain Docker, the exposed port is constrained to the host it is running. There is no support for making the service available if the host goes down. Kubernetes provides Service, which handles exactly that problem. Using label-matching selectors, it proxies traffic to the right pods, including load balancing. In this case, the master has only one pod, so it just ensures that, independent of which node the pod runs, the traffic is directed to that pod. To create the service, run the following command:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-master-service.yaml

The Redis master service has the following content:

  1 apiVersion: v1
  2 kind: Service
  3 metadata:
  4   name: redis-master
  5   labels:
  6     app: redis
  7     role: master
  8     tier: backend
  9 spec:
 10   ports:
 11   - port: 6379
 12     targetPort: 6379
 13   selector:
 14     app: redis
 15     role: master
 16     tier: backend
~                                                                        

Let's now see what we have done in the preceding code:

• Lines 1-8: Tell Kubernetes we want a proxy service that has the same labels as our redis-master server.
• Lines 10-12: Say that this Service should handle traffic arriving at 6379 and forwarded to 6,379 ports of the pods that are matched by the selector defined in line 13-16
• Line 13-16: Used to find the pods to which the incoming traffic needs to be proxied. So, any pod with labels matching (app:redis, AND role:master AND tier:backend) is expected to handle port 6379 traffic.

We can check the properties of the service by running the following:

 kubectl get service
 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
 Kubernetes  ClusterIP 10.0.0.1 <none> 443/TCP 1d
 redis-master ClusterIP 10.0.22.146 <none> 6379/TCP 7m

You see that a new service, named redis-master, has been created. It has a cluster wide IP of 10.0.22.146 (in this case, YMMV). Note that this IP will work only within the cluster (hence the ClusterIP type). For fun, you can test this out by running the following commands:

ab443838-9b3e-4811-b287-74e417a9@Azure:/usr/bin$ ssh -p 6379 10.0.22.146 # just hangs
^C
ab443838-9b3e-4811-b287-74e417a9@Azure:/usr/bin$ ssh -p 80 www.google.com # very quick rejection
ssh_exchange_identification: Connection closed by remote host

To verify it does work inside the cluster, we do our exec trick again:

ab443838-9b3e-4811-b287-74e417a9@Azure:/usr/bin$ ssh -p 6379 10.0.22.146 # just hangs
^C
ab443838-9b3e-4811-b287-74e417a9@Azure:/usr/bin$ ssh -p 80 www.google.com # very quick rejection
ssh_exchange_identification: Connection closed by remote host

Verify that the connection actually works inside the cluster:

ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl exec -it redis-master-<pod-id> bash
root@redis-master-585bd9d8fb-p9qml:/data# apt-get install telnet
Reading package lists... Done
...
update-alternatives: using /usr/bin/telnet.netkit to provide /usr/bin/telnet (telnet) in auto mode
root@redis-master-585bd9d8fb-p9qml:/data# telnet 10.0.22.146 6379 # remember that Ctrl+] is needed to "escape" from the session
Trying 10.0.22.146...
Connected to 10.0.22.146.
Escape character is '^]'.
^]
telnet&gt; quit
Connection closed.

You can try other ports and it won't work.