What is Kubernetes, and why should I care?
For a few years now, Kubernetes (pronounced coo-burr-net-eez, abbreviated to k8s) has been getting a lot of attention and hype in the DevOps world. However, it’s very hard to see what it does without having used it in a real world scenario.
From the kubernetes page
Kubernetes, also known as K8s, is an open-source system for automating deployment, scaling, and management of containerized applications.
It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.
Great, crystal clear. But what does it do?
To answer, we have to look at a bit of history. Not long ago, if you wanted a web application you had a server. Your developers wrote your application code, uploaded it to the server, started it and… it crashed. “That doesn’t happen on my machine!” cried the development team as one voice. After some investigation, it turns out that the whole team (which may be small) all had some software installed that your application depended on, but it wasn’t installed on the server. You install it, and your little application starts chugging away.
One week later, word of your application has spread, and you suddenly have 1 million people trying to use your app every day. Your poor little server can’t keep up. So you buy a few more servers, remember to install That One Important Thing on each of them, and deploy your application. You get some extra software running that will even out what users hit what servers, and everything is okay again.
Another week goes by, and your developers have added a new feature to the app. You have to update all of the servers with the new code. Not only that, but the new code makes use of features in an extra library which also needs installing on each server — you need an entire operations team just to deploy your relatively small update. Your new developers you’ve hired all need to set up their systems to match the servers you have. Hopefully all your servers are identical, otherwise you have to work even harder to make sure your application keeps going.
Containers and K8s, used together, attempt to solve the issues above. The field of DevOps is one that attempts to make Operations simple enough that it can be done by the Development team.
The first step is containers. A container is, put simply, a package of your application and all of the extra libraries it needs to run, and some description of a consistent environment. When you run a container, it runs as a whole — completely ignoring differences in the underlying hardware and operating system. This immediately alleviates some of the issues. Your development team have a consistent platform (the container) to develop on, and the servers run the container. “That doesn’t happen on my machine” is, hopefully, a thing of the past (in practice there are often still some differences between the development environment and production, but there are far fewer). Containers are isolated from one another, with standard communication methods. This means that two applications that require conflicting setups (maybe one of them needs Database v2 while the other absolutely has to have Database v4) can live side by side in their own containers on a single server.
Kubernetes (from a Greek word meaning “helmsman” or “pilot) is an application to automatically manage your containers. You hand over control of all of your servers to it — whether they’re physical servers, cloud virtual machines, or some esoteric mixture — and it will consider them to be a pool of resources that it’s allowed to use. When you say to kubernetes “Hey, here’s the container that has my application in it” it will take charge of deploying that container somewhere on your infrastructure, and connecting it to the external internet. K8s can also monitor your application, and deploy more copies of it to more servers as demand increases. You don’t have to guess any more and risk under-provisioning (your app will run slow or even crash) or over-provisioning (you’ll pay for more resources than you need), it will simply add or remove copies of your container as it needs to.
Kubernetes also shines when it comes to upgrading your app. When you give it v2 of your application (which will be a container so has all of the requirements bundled up with it), it will first deploy those containers side-by-side with your v1 of the app (which will still be running). When that is done, it will stop directing incoming connections to the v1 containers and route them to the v2 containers, and only once the v1 containers have finished what they’re doing, it will remove the v1. This give you a zero-downtime upgrade. (It can deal with crashes in a similar way, it will create a brand new instance of the container that crashed so there’s no chance of carrying over bad data and you don’t risk it happening again)
This all sounds a bit magical — this one tool has solved the issues of consistent platform, upgrades, scaling and crash handling. So what’s the catch?
The first catch is that the app needs to be developed with containers in mind. Since any two requests could go to different containers, your developers need to be careful about how they structure the application. It’s not a massive leap, but you can’t always “just put it in a container” where legacy applications are concerned.
The other is management of k8s itself. While it can automagically manage your infrastructure, it needs to be told what infrastructure you have, what the priorities are, limits on resource usage, etc. While you may not need a whole Operations team just to keep things going any more, you have increased the size of the development team’s job by adding DevOps into it. The Dev team need more people to maintain the same efficiency. This has been one of the most overlooked facts in the emergence of DevOps and k8s. For every 10 Ops guys you used to have, you’re going to need an extra developer to cover the extra work k8s adds to their plate.
K8s is a very well made tool, but like all tools it needs to be used correctly. It is also a very complex piece of software. It’s more akin to a forklift truck than a hammer, your dev team will need time and training to acclimatize to it, and may need additional hires who specialize in the field. It is not a magic bullet.