Local Django on Kubernetes with Minikube

Minikube

It’s been over half a year since I last wrote aboutDjango on Kubernetes, along with Postgres and Redis containers, and I wanted to update it to talk about one of the most exciting projects to emerge in the Kubernetes ecosystem in the last year ― Minikube .

Minikube makes it really, really easy to run a Kubernetes cluster locally. While there previously were lots of options for running Kubernetes locally, to some degree the community is coalescing around Minikube, and it’s an official part of the Kubernetes Github organization.

All the code for this tutorial can be found on this Github project .

Here are some other tutorials on getting started with Minikube:

Minikube Getting Started from the Kubernetes Doc s

Getting Started With Kubernetes via Minikube

Configuring the Ultimate Development Environment for Kubernetes

The Minikube project itself usually has the most up-to-date docs in the README on different ways to install it, as well as an Issue Tracker that the development team actively responds to.

Besides Minikube, there a few other changes made to the project:

I started using Jinja 2 templates via jinja cli to populate any environment variables, and to refactor parts of the configuration that are Minikube or Container Engine specific. I switched all the Replication Controllers to the new Deployments , which are pretty much the same thing with a more declarative update system

Our Django project used a few Cloud features such as Load Balancers and Volumes (via GCE Persistent Disk) that you might wonder how it gets translated to Minikube. So this post will go over the following topics:

Minikube tips and gotchas I’ve run into Persistent Volumes and Persistent Volume Claims Minikube services vs External LoadBalancers Port forwarding and why it’s useful Hot reloading your code in development with host mounts Minikube tips

Another big 2016 announcement was Docker for Mac, which is super great for those of us who didn’t like running VirtualBox and futzing with docker-machine. The default Minikube driver is still VirtualBox though, so if you’re using Docker for Mac, make sure you specify the xhyve driver (xhyve is the hypervisor that drives Docker for Mac):

$ minikube start ― vm-driver=xhyve

Or set this permanently with:

$ minikube config set vm-driver=xhyve

Another thing to consider with Minikube is that it won’t always have credentials to pull from private container registries. If you’re using public DockerHub images, this is no big deal, but if you’re using a private registry (like Google Container Registry by default), it’s a problem. There are two solutions ― the first is to add imagePullSecrets to all your pod specs. The other alternative is just to avoid having Minikube pulling images, by making sure that imagePullPolicy is set to IfNotPresent.

Keep in mind that the default imagePullPolicy is IfNotPresent, unless the image is tagged as latest, in which case it’s Always. Images without tags are considered to have the tag latest. So it’s best just to tag your images and explicitly set your imagePullPolicy.

My sample repo has gone with the latter approach and avoids pulling images when working locally. In order for Minikube to get the images it needs, you can share your Docker daemon with Minikube.

$ eval $(minikube docker-env)

Now when you do Docker builds, the images you build will be available to Minikube.

When switching back and forth between Container Engine and Minikube, make sure to switch the contexts:

$ gcloud container cluster get-credentials mycluster # Container Engine context $ kubectl config use-context minikube # Minikube context Persistent Volumes and Persistent VolumeClaims

In the original project, I attached a GCE Persistent Disk directly to the Postgres Pod as a Volume:

volumes:
- name: postgresdata
gcePersistentDisk:
# your disk name here
pdName: pg-data
fsType: ext4
- name: secrets

The problem is that Minikube will not be able to access a GCE disk.Of course, this is easily solved by our Jinja2 templates. However, Kubernetes has the concepts of PersistentVolumes and PersistentVolumeClaims, which generalize the nature of storage, so I figured it would be a good place to add it anyway.

Instead of attaching a specific volume, we attach a PersistentVolumeClaim, which simply asks for some sort of storage. Of course, the claims can specify what read/write permissions they need, how much storage, etc.

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: postgres-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi

Then we can attach the PVC to the Pod instead.

volumes:
- name: postgresdata
persistentVolumeClaim:
claimName: postgres-data

Claims will need to be bound to PersistentVolumes that satisfy their constraints. For Container Engine, we will still create a GCE disk:

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 5Gi
gcePersistentDisk:
pdName: pg-data
fsType: ext4

But for Minikube, we can just create a local directory and use a hostmount as a persistent volume instead.

apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
accessModes:
- ReadWriteOnce
capacity:
storage: 5Gi
hostPath:
path: /data/pv0001/ Load Balancers

Our frontend that serves web traffic used a Service of type: LoadBalancer, which on Container Engine provisions a Google Compute Engine L7 Load Balancer. That provided us with an External IP when we ran:

$ kubectl get services that we could then reach o