@@ -21,25 +21,36 @@ See the companion [Setup Kubernetes](https://github.com/GoogleCloudPlatform/kube
Note: This redis-master is *not* highly available. Making it highly available would be a very interesting, but intricate exersize - redis doesn't actually support multi-master deployments at the time of this writing, so high availability would be a somewhat tricky thing implement, and might involve periodic serialization to disk, and so on.
Use (or just create) the file `examples/guestbook/redis-master.json` which describes a single pod running a redis key-value server in a container:
Use (or just create) the file `examples/guestbook/redis-master-controller.json` which describes a single pod running a redis key-value server in a container:
Note that, although the redis server runs just with a single replica, we use replication controller to enforce that exactly one pod keeps running (e.g. in a event of node going down, the replication controller will ensure that the redis master gets restarted on a healthy node).
Once that's up you can list the pods in the cluster, to verify that the master is running:
```shell
kubectl get pods
$ kubectl get pods
```
You'll see all kubernetes components, most importantly the redis master pod. It will also display the machine that the pod is running on once it gets placed (may take up to thirty seconds):
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e3eed3e5e6d1 dockerfile/redis:latest "redis-server /etc/re 2 minutes ago Up 2 minutes k8s_master.9c0a9146_redis-master.etcd_6296f4bd-70fa-11e4-8469-0800279696e1_45331ebc
me@kubernetes-minion-7agi:~$ sudo docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
0ffef9649265 dockerfile/redis:latest "redis-server /etc/r About a minute ago Up About a minute k8s_redis-master.767aef46_redis-master-controller-gb50a.default.api_4530d7b3-ae5d-11e4-bf77-42010af0d719_579ee964
```
(Note that initial `docker pull` may take a few minutes, depending on network conditions. You can monitor the status of this by running `journalctl -f -u docker` to check when the image is being downloaded. Of course, you can also run `journalctl -f -u kubelet` to see what state the kubelet is in as well during this time.
...
...
@@ -113,14 +127,11 @@ to create the service by running:
This will cause all pods to see the redis master apparently running on <ip>:6379. The traffic flow from slaves to masters can be described in two steps, like so.
- A *redis slave* will connect to "port" on the *redis master service*
...
...
@@ -140,26 +151,28 @@ Use the file `examples/guestbook/redis-slave-controller.json`, which looks like
"apiVersion":"v1beta1",
"desiredState":{
"replicas":2,
"replicaSelector":{"name":"redisslave"},
"replicaSelector":{"name":"redis-slave"},
"podTemplate":{
"desiredState":{
"manifest":{
"version":"v1beta1",
"id":"redis-slave-controller",
"id":"redis-slave",
"containers":[{
"name":"slave",
"name":"redis-slave",
"image":"brendanburns/redis-slave",
"cpu":200,
"ports":[{"containerPort":6379,"hostPort":6380}]
"ports":[{"containerPort":6379}]
}]
}
},
"labels":{
"name":"redisslave",
"uses":"redis-master"
}
}},
"labels":{"name":"redisslave"}
},
"labels":{
"name":"redis-slave",
"uses":"redis-master",
"app":"redis"
}
}
},
"labels":{"name":"redis-slave"}
}
```
...
...
@@ -169,9 +182,10 @@ to create the replication controller by running:
The redis slave configures itself by looking for the Kubernetes service environment variables in the container environment. In particular, the redis slave is started with the following command:
...
...
@@ -186,10 +200,10 @@ Once that's up you can list the pods in the cluster, to verify that the master a
You will see a single redis master pod and two redis slave pods.
...
...
@@ -208,29 +222,26 @@ The service specification for the slaves is in `examples/guestbook/redis-slave-s
"port":6379,
"containerPort":6379,
"labels":{
"name":"redisslave"
"name":"redis-slave"
},
"selector":{
"name":"redisslave"
"name":"redis-slave"
}
}
```
This time the selector for the service is `name=redisslave`, because that identifies the pods running redis slaves. It may also be helpful to set labels on your service itself as we've done here to make it easy to locate them with the `cluster/kubectl.sh get services -l "label=value"` command.
This time the selector for the service is `name=redis-slave`, because that identifies the pods running redis slaves. It may also be helpful to set labels on your service itself as we've done here to make it easy to locate them with the `cluster/kubectl.sh get services -l "label=value"` command.
Now that you have created the service specification, create it in your cluster by running:
Once that's up (it may take ten to thirty seconds to create the pods) you can list the pods in the cluster, to verify that the master, slaves and frontends are running:
### A few Google Container Engine specifics for playing around with the services.
- In GCE, you can grab the external IP of that host from the [Google Cloud Console][cloud-console] or the `gcloud` tool, and visit `http://<host-ip>:8000`.
In GCE, `cluster/kubectl.sh` automatically creates forwarding rule for services with `createExternalLoadBalancer`.
You can grab the external IP of the load balancer associated with that rule and visit `http://130.211.188.51:8000`.
In GCE, you also may need to open the firewall for port 8000 using the [console][cloud-console] or the `gcloud` tool. The following command will allow traffic from any source to instances tagged `kubernetes-minion`:
```shell
...
...
@@ -364,7 +414,7 @@ In other environments, you can get the service IP from looking at the output of
And of course, finally, if you are running Kubernetes locally, you can just visit http://localhost:8000.
### Step Six: Cleanup
### Step Seven: Cleanup
To turn down a Kubernetes cluster, if you ran this from source, you can use
