Kubernetes for developers

I’m a developer and I’m a huge fan of Kubernetes — its an incredible piece of work based on Google’s Borg. Given Google have been running zillions of containers in production for many years; they clearly know a thing or two about it.

Whether you use a cloud & container ready Linux distro like Atomic or CoreOS, a PaaS like OpenShift or public clouds like Google’s GKE there’s already Kubernetes baked in; if you’re using something else its really easy to install (e.g. on AWS).

So as a developer I think you should start thinking of taking advantage of this awesome technology to help you write better cloud ready applications.

What does kubernetes do?

So what does Kubernetes buy you as a developer? Well Kubernetes helps you write distributed applications using immutable docker container images that run in any environment (namespace) in any kubernetes hosted cloud with:

• manual scaling of any part of your infrastructure with liveness checks and automatic restarts of dead containers (with automatic scaling on the way soon…)
• service discovery to wire all your containers to the services they need
• load balancing across all your containers for any network protocol; both internal and external load balancers
• rolling upgrades of changes
• simple REST APIs and CLIs to work with your containers and services

In addition your app can be easily provisioned in multiple environments (e.g. Dev, Test, UAT, Pre-Prod and Prod) all on the same Kubernetes infrastructure; using namespaces to separate environments which really helps with Continuous Integration and Continuous Delivery.

Developer view of Kubernetes

Kubernetes is a relatively small bit of software you install on each box to make your own cloud. As a developer you don’t need to worry about whats behind the curtain; stuff like etcd, master node, minions, kubelets, iptables and all kinds of infrastructure magic. Though its not that complex if you wanna dive in! ☺

As a developer to work on Kubernetes you mostly just have to grok the 3 sub atomic particles of Kubernetes:

• Pods
• Replication Controllers
• Services

Then you need to grok namespaces, names and labels.

Once you can master those things you’ll be able to create some docker containers, configure them with environment variables, services and maybe volumes and you’re on your way to a simpler more powerful way to develop cloud native container based applications that runs on any cloud / PaaS / modern linux!

Pods

A pod is a collection of one or more docker containers co-located on a single physical host. A pod is the minimum deployment unit in Kubernetes and deployment of a Pod is atomic (it either works or its deleted).

If you decide to colocate containers together into a pod then the containers can communicate directly to each other using the local ports without having to go through any network proxy.

Pods can also have volumes; which can then be mounted into one or more of the containers and shared between containers in the same pod. e.g. one container could write to local disk, the another could read.

Replication Controllers

A Replication Controller is just metadata to define how many replicas (instances) of a particular pod template should run.

e.g. if you want 4 Tomcat pods and 5 Cassandra pods; then just create a replication controller for Tomcat and Cassandra; configure the pod template with the docker image name and any required environment variables values and set the replica counts to 4 and 5 respectively.

Then Kubernetes will keep watching the live cluster and if there are not enough or there are too many pods of a certain kind it’ll start/stop them as required. Lose a pod or machine? No biggie, kubernetes will restart the missing pods!

If you use a persistent volume; then as a pod gets restarted on another node by Kubernetes, the pods persistent volume gets remounted for you.

You can change the replica count on a replication controller at any time to manually scale up or down. So high availability and scaling of your pods in one easy-ish blob of JSON/YAML.

If you want to get advanced you can add liveness checks to the JSON/YAML on a pod so that Kubernetes can keep pinging each pod to check its really alive and well; if not Kubernetes will kill it and restart a fresh one.

Services

So if you’re running a bunch of containers for a database or REST service; how do you talk to them from your container? Thats where Kubernetes services come in.

Kubernetes services are a way of grouping some pods together and exposing their ports on a unique IP address.

Under the covers, Kubernetes takes care of all the load balancing; watching as pods come and go or as things scale up or down. On startup your container can bind to a fixed IP address and port for each service it needs; whether its a database, a REST API, message broker, redis, whatever.

Thats it — service discovery as a developer writing apps is literally just 2 environment variables per service. Simples!

e.g. for a service named foo-bar you can use these 2 environment variables to access the service:

• FOO_BAR_SERVICE_HOST is the host (IP) address of the service
• FOO_BAR_SERVICE_PORT is the port of the service

So you could access a web site or service via this expression:

http://${FOO_BAR_SERVICE_HOST}:${FOO_BAR_SERVICE_PORT}/

Naming: namespaces, names and labels

Resources like Pods, Replication Controllers and Services have names which are unique within a namespace. A namespace is a way you can separate out logical clusters.

For example each team could have a Dev, Test, UAT, PreProd and Prod namespace in the same Kubernetes cluster. Within a single namespace (a teams Test environment) service discovery (and the associated environment variables) only relates to the current namespace. So you won’t accidentally discover the production database in a test environment ;)

Labels are a set of key / value pairs of strings to attach to pods. Use any keys or values you like. Then you can create a selector, which is a set of key / value pairs to query for the pods you need; i.e. to select all pods with labels matching those in the selector.

Then you can configure a selector on a Replication Controller to find the pods its replicating; so it can count the number of related pods to create or delete.

Or you can configure a selector on a Service to define the pods which it load balances across.

Summary

If you’ve made it this far then you’ve well on the way to being a cloud native developer writing microservices on top of Kubernetes. Well done!

If you want to play around with Kubernetes you could try setup a cluster and then try install some apps including the nice fabric8 console which visualises the pods, services, replication controllers and apps running in kubernetes and makes it easy to resize things, start and stop pods etc.

There’s a little more detail here on discovering services both internal to the Kubernetes cluster and external services together with exposing services to the outside world and how to discover services when running processes outside of Kubernetes.

If you’re a Java developer I’ll write a dedicated Java-flavour blog post soon; in the meantime you might want to check out these handy tools for working with Kubernetes / OpenShift from Java.

Or you could just watch a video ;). Enjoy your ride with kubernetes!