This tutorial shows you how to build and deploy a simple, multi-tier web application using Kubernetes and Docker. This example consists of the following components:
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:
To check the version, enter kubectl version
.
Download the following configuration files:
The guestbook application uses Redis to store its data. It writes its data to a Redis master instance and reads data from multiple Redis slave instances.
The manifest file, included below, specifies a Deployment controller that runs a single replica Redis master Pod.
redis-master-deployment.yaml
file:
kubectl apply -f redis-master-deployment.yaml
guestbook/redis-master-deployment.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
Query the list of Pods to verify that the Redis Master Pod is running:
kubectl get pods
The response should be similar to this:
NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 28s
Run the following command to view the logs from the Redis Master Pod:
kubectl logs -f POD-NAME
Note: Replace POD-NAME with the name of your Pod.
The guestbook applications needs to communicate to the Redis master to write its data. You need to apply a Service to proxy the traffic to the Redis master Pod. A Service defines a policy to access the Pods.
redis-master-service.yaml
file:
kubectl apply -f redis-master-service.yaml
guestbook/redis-master-service.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
Note: This manifest file creates a Service namedredis-master
with a set of labels that match the labels previously defined, so the Service routes network traffic to the Redis master Pod.
kubectl get service
The response should be similar to this:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.0.0.1 <none> 443/TCP 1m
redis-master 10.0.0.151 <none> 6379/TCP 8s
Although the Redis master is a single pod, you can make it highly available to meet traffic demands by adding replica Redis slaves.
Deployments scale based off of the configurations set in the manifest file. In this case, the Deployment object specifies two replicas.
If there are not any replicas running, this Deployment would start the two replicas on your container cluster. Conversely, if there are more than two replicas are running, it would scale down until two replicas are running.
redis-slave-deployment.yaml
file: kubectl apply -f redis-slave-deployment.yaml
guestbook/redis-slave-deployment.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
kubectl get pods
The response should be similar to this:
NAME READY STATUS RESTARTS AGE
redis-master-1068406935-3lswp 1/1 Running 0 1m
redis-slave-2005841000-fpvqc 0/1 ContainerCreating 0 6s
redis-slave-2005841000-phfv9 0/1 ContainerCreating 0 6s
The guestbook application needs to communicate to Redis slaves to read data. To make the Redis slaves discoverable, you need to set up a Service. A Service provides transparent load balancing to a set of Pods.
redis-slave-service.yaml
file: kubectl apply -f redis-slave-service.yaml
guestbook/redis-slave-service.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
kubectl get services
The response should be similar to this:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes 10.0.0.1 <none> 443/TCP 2m
redis-master 10.0.0.151 <none> 6379/TCP 1m
redis-slave 10.0.0.223 <none> 6379/TCP 6s
The guestbook application has a web frontend serving the HTTP requests written in PHP. It is configured to connect to the redis-master
Service for write requests and the redis-slave
service for Read requests.
frontend-deployment.yaml
file: kubectl apply -f frontend-deployment.yaml
guestbook/frontend-deployment.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
kubectl get pods -l app=guestbook -l tier=frontend
The response should be similar to this:
NAME READY STATUS RESTARTS AGE
frontend-3823415956-dsvc5 1/1 Running 0 54s
frontend-3823415956-k22zn 1/1 Running 0 54s
frontend-3823415956-w9gbt 1/1 Running 0 54s
The redis-slave
and redis-master
Services you applied are only accessible within the container cluster because the default type for a Service is ClusterIP. ClusterIP
provides a single IP address for the set of Pods the Service is pointing to. This IP address is accessible only within the cluster.
If you want guests to be able to access your guestbook, you must configure the frontend Service to be externally visible, so a client can request the Service from outside the container cluster. Minikube can only expose Services through NodePort
.
Note: Some cloud providers, like Google Compute Engine or Google Kubernetes Engine, support external load balancers. If your cloud provider supports load balancers and you want to use it, simply delete or comment outtype: NodePort
, and uncommenttype: LoadBalancer
.
frontend-service.yaml
file: kubectl apply -f frontend-service.yaml
guestbook/frontend-service.yaml docs/tutorials/stateless-application/guestbook
|
---|
|
kubectl get services
The response should be similar to this:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend 10.0.0.112 <none> 80:31323/TCP 6s
kubernetes 10.0.0.1 <none> 443/TCP 4m
redis-master 10.0.0.151 <none> 6379/TCP 2m
redis-slave 10.0.0.223 <none> 6379/TCP 1m
NodePort
If you deployed this application to Minikube or a local cluster, you need to find the IP address to view your Guestbook.
minikube service frontend --url
The response should be similar to this:
http://192.168.99.100:31323
LoadBalancer
If you deployed the frontend-service.yaml
manifest with type: LoadBalancer
you need to find the IP address to view your Guestbook.
kubectl get service frontend
The response should be similar to this:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
frontend 10.51.242.136 109.197.92.229 80:32372/TCP 1m
Scaling up or down is easy because your servers are defined as a Service that uses a Deployment controller.
kubectl scale deployment frontend --replicas=5
kubectl get pods
The response should look similar to this:
NAME READY STATUS RESTARTS AGE
frontend-3823415956-70qj5 1/1 Running 0 5s
frontend-3823415956-dsvc5 1/1 Running 0 54m
frontend-3823415956-k22zn 1/1 Running 0 54m
frontend-3823415956-w9gbt 1/1 Running 0 54m
frontend-3823415956-x2pld 1/1 Running 0 5s
redis-master-1068406935-3lswp 1/1 Running 0 56m
redis-slave-2005841000-fpvqc 1/1 Running 0 55m
redis-slave-2005841000-phfv9 1/1 Running 0 55m
kubectl scale deployment frontend --replicas=2
kubectl get pods
The response should look similar to this:
NAME READY STATUS RESTARTS AGE
frontend-3823415956-k22zn 1/1 Running 0 1h
frontend-3823415956-w9gbt 1/1 Running 0 1h
redis-master-1068406935-3lswp 1/1 Running 0 1h
redis-slave-2005841000-fpvqc 1/1 Running 0 1h
redis-slave-2005841000-phfv9 1/1 Running 0 1h
Deleting the Deployments and Services also deletes any running Pods. Use labels to delete multiple resources with one command.
kubectl delete deployment -l app=redis
kubectl delete service -l app=redis
kubectl delete deployment -l app=guestbook
kubectl delete service -l app=guestbook
The responses should be:
deployment "redis-master" deleted
deployment "redis-slave" deleted
service "redis-master" deleted
service "redis-slave" deleted
deployment "frontend" deleted
service "frontend" deleted
kubectl get pods
The response should be this:
No resources found.