Container orchestration with Kubernetes

Hosting a small number of containers on a single server is no huge undertaking, especially with easy access to container images on the Docker platform. But hosting hundreds or thousands across multiple machines? Without a way to coordinate those containers, tell them what to do, how to do it, and when, it’s totally impractical.

So if you’re using containers in a production environment, you need an orchestration tool. This is especially true in web or application development, where you might need to deploy new versions several times a day, while also maintaining 24/7 availability. There are a few options, but the leading solution when it comes to filling this vital role is Kubernetes.

What is Kubernetes?

Greek for ‘helmsman’, Kubernetes started life as a Google project in 2014, before passing into the realm of open source in 2015. It automates the deployment, scheduling, scaling and management of applications via containerisation – in other words, it creates an infrastructure of containers.

This infrastructure is made up of one or more nodes (physical servers or virtual machines), with several nodes forming a cluster. If a node fails, Kubernetes restarts, replaces or reschedules containers as required. Kubernetes can also automatically scale containers across nodes to meet current performance demands.

The smallest units handled by Kubernetes aren’t actually individual containers, but what are known as pods. A pod can hold a single container, but more often it’s a grouping of several that work in close coordination and share things like storage and IP addresses.

By orchestrating multiple pods across multiple nodes, Kubernetes greatly simplifies the management of containerised applications – both in terms of the containers themselves, and other resources such as storage and networking.

Because Kubernetes is responsible for updating containers on a large scale, change rollouts can be performed seamlessly. And rollbacks too, if required, with old instances automatically kept alive when changes are applied.

Kubernetes vs Docker Swarm

Docker Swarm is an orchestration tool developed alongside the Docker container platform, now emerging as a competitor for Kubernetes. So what’s the difference?

While Docker Swarm is perfectly capable of running and scheduling containerised apps across multiple machines, Kubernetes ultimately allows larger, more complex clusters that can be more effectively scaled. It achieves this with automated features like self-healing and customisable scheduling – areas where Docker Swarm can’t yet compete.

But Docker Swarm does have the advantage of being more closely integrated with Docker components. And Swarm can be less time-consuming and tricky to pick up, especially if you’re already familiar with Docker itself. In fact, the usability of Docker Swarm might make it a more welcoming first step into the world of container orchestration, especially for smaller-scale projects.

That said, Kubernetes remains the first choice for enterprise-level container deployments. Not surprising, considering how much time, effort and experience went into its development at Google.

More recently it’s become clear that Kubernetes is maturing and regularly adding features, with a special focus on metrics, monitoring and reporting. Kubernetes also has the support of a large and dedicated community, particularly on GitHub.

A virtualised environment is the ideal place to get started with container orchestration. Run Kubernetes yourself on CloudNX, our next-generation cloud hosting platform, with the ability to scale multiple virtual machines and create your own container-centric infrastructure.