This was a presentation at the Django SF meetup. It walks through deploying Django, PostgreSQL, and Redis into a Kubernetes (Container Engine) cluster, and compares it to other deployment options.
application (create and read) • Using local PostgreSQL and Redis Inspired by: http://instagram-engineering.tumblr.com/post/13649370142/what-powers- instagram-hundreds-of-instances
• Pros: Simple and easy, lots of useful features • Cons: Limited flexibility • Traditional VM/physical machine without containers • Pros: Familiar and proven • Cons: Poor isolation or resource usage, complex and heavy to scale • Containers • Pros: Efficiency, isolation, portability, immutability • Cons: Less proven, less familiar, “rough edges” (storage, security)
http://blog.circleci.com/its-the-future/ -No, it’s really easy. You just set up a Kubernetes cluster. I need a cluster? -Kubernetes cluster. It’ll manage the deployments of all your services. I only have one service. -What do you mean? You have an app right, so you gotta have at least 8-12 services?
the application • The Dockerfile adds my application code and dependencies to the image • Starts Django with a Gunicorn server • docker build . -t grc.io/my-project/guestbook
a cluster of nodes (VMs) • How does it get scheduled onto an appropriate node? • How does it discover other services like a database or another team’s microservice? • How do end-users or a client microservice know how to find it? • How do I scale it up and down? Manually and automatically? • How do I safely update it? Roll it back? A/B or canary test it? • Where do I store secrets like passwords and or SSL certificates? • How can I namespace my containers?
the word “Governor” • Container orchestrator • Runs containers • Supports multiple cloud and bare- metal environments • Inspired and informed by Google’s experiences and internal systems • Open source, written in Go Manage applications, not machines
problems? Submit a GibHub Issue or PR, mention @waprin. README.md is aimed at Google Container Engine (managed Kubernetes), but configs and guide should should work with slight modification on cloud providers that support external load balancers and persistent volumes (AWS, OpenStack, GCE). gcloud commands (Google Cloud SDK CLI) should be replaced by their equivalents.
commands: kubectl get <resource_type> # Gets a list of a given resource (Pods, Services) kubectl describe <resource_type> <resource_name> # Describe a resource kubectl logs <pod> # Get logs from a pod # Run Django Migrations from a Pod kubectl exec -it <frontend-pod> -- python /app/manage.py migrate
container kubectl create -f kubernetes_config/frontend.yaml This does a couple of things: • Creates a Replication Controller that will control how many Pods are run • Each Pod runs a container using the image we provide. • Creates a Service that maps an external IP to those Pods
given Label. kubectl scale rc frontend --replicas=5 kubectl rolling-update rc frontend --image=frontend:v2 Every Pod comes with a Virtual IP on a private network. Within a Kubernetes cluster, a Service will round-robin to a Pod that matches its Label.
redis-master and redis-slave Services created with their respective Replication Controllers • kubectl create -f db_password.yaml • Creates a Secret with our database passwords • kubectl create -f postgres.yaml • Mounts a Volume (GCE disk) and Secret (database passwords) • Not a highly available setup
critical things for CI/CD: isolation and scalability. • Docker gives you isolation • Kubernetes gives you scalability • https://github.com/GoogleCloudPlatform/jenkernetes • A/B or Canary Testing • Have one Service map to two Replication Controllers • Experiment with changing the ratio of each Pod type backing the Service
client Pods to simulate CPU usage and trigger Pod and Node autoscaling (beta feature). https://cloud.google.com/solutions/distributed-load-testing-using- kubernetes
Kubernetes • You love the portability, flexibility, composability, and immutability of containers • You want to deploy Django in a microservices environment • You want a toolkit that solves the distributed systems problems and lets you design the platform
Kubernetes • You love the portability, flexibility, composability, and immutability of containers • You want to deploy Django in a microservices environment • You want a toolkit that solves the distributed systems problems and lets you design the platform When You Should Not Deploy Django on Kubernetes • You are looking for a fully-fledged PaaS (though many are built on Kubernetes) • Containers and microservices offer more complexity than benefit for your use cases
Docker, similar toolchain • Disadvantages: Fewer features and abstractions, less of a cluster- oriented approach • Mesos • Advantages: Proven in production at scale, can schedule non- containerized workflows • Disadvantages: More resource-intensive, high complexity • Running Kubernetes on Mesos is possible
(http://deis.com) is an open source PaaS with Django support built on Kubernetes • Gondor (http://gondor.io) is a Django-focused PaaS built on Kubernetes • Flocker is a ClusterHQ (http://clusterhq.com) product providing additional tooling for storage on Kubernetes. • Sysdig (http://sysdig.org) provides container analytics products