Running a single backend on the cloud is not cool. So, we run multiple slaves to handle the massive read traffic of all those who would really like to know what people think of your model railroad display. We do this by running the following command:

kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml

The output would be something like this:

ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-deployment.yaml
 deployment.apps/redis-slave created
 ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl get all
 NAME READY STATUS RESTARTS AGE
 pod/redis-master-585bd9d8fb-p9qml 1/1 Running 0 21h
 pod/redis-slave-b58dc4644-2hpr7 0/1 ContainerCreating 0 3s
 pod/redis-slave-b58dc4644-bz9dj 0/1 ContainerCreating 0 3s
 
 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
 service/Kubernetes  ClusterIP 10.0.0.1 <none> 443/TCP 1d
 service/redis-master ClusterIP 10.0.22.146 <none> 6379/TCP 1h
 
 NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
 deployment.apps/redis-master 1 1 1 1 21h
 deployment.apps/redis-slave 2 2 2 0 3s
 
 NAME DESIRED CURRENT READY AGE
 replicaset.apps/redis-master-585bd9d8fb 1 1 1 21h
 replicaset.apps/redis-slave-b58dc4644 2 2 0 3s
 ab443838-9b3e-4811-b287-74e417a9@Azure:~$

Based on the preceding output, you can guess that this time we asked 2 replicas of the redis slave pods. That is confirmed true when you examine the redis-slave-deployment.yaml file:

  1 apiVersion: apps/v1 # for versions before 1.9.0 use apps/v1beta2
  2 kind: Deployment
  3 metadata:
  4   name: redis-slave
  5   labels:
  6     app: redis
  7 spec:
  8   selector:
  9     matchLabels:
 10       app: redis
 11       role: slave
 12       tier: backend
 13   replicas: 2
 14   template:
 15     metadata:
 16       labels:
 17         app: redis
 18         role: slave
 19         tier: backend
 20     spec:
 21       containers:
 22       - name: slave
 23         image: gcr.io/google_samples/gb-redisslave:v1
 24         resources:
 25           requests:
 26             cpu: 100m
 27             memory: 100Mi
 28         env:
 29         - name: GET_HOSTS_FROM
 30           value: dns
 31           # Using `GET_HOSTS_FROM=dns` requires your cluster to
 32           # provide a dns service. As of Kubernetes 1.3, DNS is a built-in
 33           # service launched automatically. However, if the cluster you are using
 34           # does not have a built-in DNS service, you can instead
 35           # access an environment variable to find the master
 36           # service's host. To do so, comment out the 'value: dns' line above, and
 37           # uncomment the line below:
 38           # value: env
 39         ports:
 40         - containerPort: 6379

Everything is more or less the same other than the following:

• The role is declared to be a slave.
• Replicas is equal to 2.
• We are using the gb-redisslave image.
• Setting the GET_HOSTS_FROM=dns;, we can presume that the slave is going to get the master IP using DNS. Let's check whether our assumption is correct by running the following code:

ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl exec -it redis-slave-<pod-id> bash
 root@redis-slave-b58dc4644-2hpr7:/data# cat /proc/1/cmdline
 /bin/sh-c/run.shroot@redis-slave-b58dc4644-2hpr7:/data# cat /run.sh
 #!/bin/bash
 #...
 if [[ ${GET_HOSTS_FROM:-dns} == "env" ]]; then
 redis-server --slaveof ${REDIS_MASTER_SERVICE_HOST} 6379
 else
 redis-server --slaveof redis-master 6379
 fi
 root@redis-slave-b58dc4644-2hpr7:/data# root@redis-slave-b58dc4644-2hpr7:/data# ping redis-master
 PING redis-master.default.svc.cluster.local (10.0.22.146): 48 data bytes

As expected, run.sh in the image checks whether the GET_HOSTS_FROM variable is set to env. In this case, it is set to dns, so it returns false. redis-server is launched in slave mode pointing to the redis-master host as the master. If you ping redis-master, you can see it is set to the ClusterIP of the redis-master service.

Similar to the master service, we need to expose the slave service by running the following:

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

apiVersion: v1
kind: Service
metadata:
  name: redis-slave
  labels:
    app: redis
    role: slave
    tier: backend
spec:
  ports:
  - port: 6379
  selector:
    app: redis
    role: slave
    tier: backend

The only difference between this Service and the redis-master Service is that this service proxies traffic to pods that have the role:slave label in them.

Create the redis slave service by running the following command:

ab443838-9b3e-4811-b287-74e417a9@Azure:~$ kubectl apply -f https://k8s.io/examples/application/guestbook/redis-slave-service.yaml
 service/redis-slave created
 ab443838-9b3e-4811-b287-74e417a9@Azure:~$ 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 2h
 redis-slave ClusterIP 10.0.14.218 <none> 6379/TCP 3s
 ab443838-9b3e-4811-b287-74e417a9@Azure:~$

To check whether the slave service responds at the mentioned ClusterIP and port 6379, run the following commands:

kubectl run checkredisslave -it --image ubuntu
# on the terminal or run 
kubectl attach <pod-name> # to get to the terminal
# apt update
apt install -y netcat # re-run apt update in case you copied the # by mistake in the previous command
nc -vz <redis-slave ClusterIP> 6379
# you should get ... (?) open