Kubernetes is a great platform to run your applications on. There are plenty of blogs out there that go into why Kubernetes is great, so go read some if you haven’t already. One of the many great fits is a Django application. Here, we’ll run through the very basics.
We’ll deploy this demonstration to Google Cloud Platform as this provides a good foundation to spin up a Kubernetes cluster and required ancillaries. All of the kubectl commands are ambiguous to where you’ve installed Kubernetes.
First, pull the demo repository. This contains some manifest templates, a couple of Dockerfiles and a simple Django guestbook, written by Bill Prin, who was influential in me this post.
git clone https://github.com/joedborg/django-kubernetes-demo.git
You’ll need to have kubectl and gcloud installed. You’ll also need a GKE
account if you want to follow this guide step-by-step; you can do this here.
snap install kubectl --classic
See here for instructions
on installing gcloud.
Assuming you have Homebrew installed.
brew install kubectl
brew install google-cloud-sdk
Make sure gcloud is up-to-date.
gcloud components update
If you’ve not already setup one, we need to create a project. We must call it something unique. For
this blog, I’ll call it guestbook-jb.
If you’ve never used to gcloud before, you need to initialise it. You can
follow the steps to create a new project.
gcloud init
Otherwise, do the following.
gcloud projects create guestbook-jb
Then we need to set it as the project ID.
gcloud config set project guestbook-jb
Now that we have gcloud setup, we can start a Kubernetes cluster.
gcloud container clusters create guestbook --scopes "userinfo-email","cloud-platform","datastore","default" --num-nodes 2
The --scopes flag specifies which other Google Cloud APIs your cluster can
utilise. We’ll only use 2 nodes for this demonstration to keep costs sane.
We then want to copy the cluster’s config into our kubectl.
gcloud container clusters get-credentials guestbook
We can then test by looking for our 2 nodes.
kubectl get nodes
We need generate completed yaml manifest files. Make sure you’re in the repository directory.
make templates
Kubernetes has a built in secrets manager which allows you to store secrets and then inject them into pods via different means.
Having generated the templates, the file secrets.yaml will have been created with a randomly generated password. This password will then be injected into the Django and Postgres pods.
To apply these secrets.
kubectl apply -f ./secrets.yaml
We’re going to use Redis to cache the amount of page views.
kubectl apply -f ./redis.yaml
Postgres is a bit more complex because we need a persistent volume to store our data. Fortunately, Kubernetes also has a built in component to handle this too.
First of all, we need to crate a volume in GCP.
gcloud compute disks create pg-data --size 200GB
This is then tied to the database by Kubernetes with the persistentvolume and persistentvolumeclaim directive in the postgres.yaml manifest.
To handle Kubernetes secrets, we’ve got a very simple, custom Docker image in the postgres directory. This needs to be built and pushed to our registry.
cd postgres/
docker build . --tag gcr.io/$(gcloud config list project --format="value(core.project)")/postgres-pw:v1
gcloud docker -- push gcr.io/$(gcloud config list project --format="value(core.project)")/postgres-pw:v1
Finally, we can deploy Postgres.
cd ../
kubectl apply -f ./postgres.yaml
Note there may been some errors thrown regarding persistent volume claims, this should clear up in a minute or less; it’s a race condition within Kubernetes.
We’re finally ready to deploy Django. The manifest also defines a load balancer which will act as Nginx or Apache would in a legacy deployment.
First, we need to build and push the initial Docker image. The Dockerfile for our guestbook is generic enough to be used with most basic Django deployments. You will, however, need to change the settings.py to get the correct username and password from the mounted secrets directory. Open settings.py to see how this handled.
cd guestbook/
docker build . --tag gcr.io/$(gcloud config list project --format="value(core.project)")/guestbook:v1
gcloud docker -- push gcr.io/$(gcloud config list project --format="value(core.project)")/guestbook:v1
We can then deploy.
cd ../
kubectl apply -f guestbook.yaml
And run migrations.
kubectl exec $(kubectl get pods | grep guestbook | awk '{ print $1 }') python ./manage.py migrate
We can then get the public IP address from the load balancer.
kubectl get services
You should then be able to connect to that IP address and see your Django site!
This is all great, but hasn’t really bought us much over a legacy deployment. Let’s explore a couple of very simple things Kubernetes buys us straight away.
We can roll out updates to our Django application. These roll outs are zero downtime and will stop if there is an issue that means that Django won’t start.
First off make a change, then build and push the Docker image. Pay attention to change the version tag.
cd guestbook/
docker build . --tag gcr.io/$(gcloud config list project --format="value(core.project)")/guestbook:v2
gcloud docker -- push gcr.io/$(gcloud config list project --format="value(core.project)")/guestbook:v2
Now we need to tell Kubernetes to use the new image. This will create a new pod and only swap if the container inside starts (i.e. Django starts).
kubectl set image deployment/guestbook guestbook=gcr.io/$(gcloud config list project --format="value(core.project)")/guestbook:v2
We can see if the roll out is working.
kubectl rollout status deployment/guestbook
You can read more about roll outs here.
Another thing we might want to do is scale our Django application.
We can either do that manually.
kubectl scale deployment guestbook --replicas=3
Or we can set criteria for automatic scaling.
kubectl autoscale deployment guestbook --min=1 --max=5 --cpu-percent=80
You can read more about scaling here.
If you’ve just run through this as a demonstration, I advise you clean up the cluster and storage to keep costs down.
gcloud container clusters delete guestbook
gcloud compute disks delete pg-data