Kontena, Influenced by Docker Swarm and Kubernetes, but of a Different Magnitude – InApps 2022

In their own words, “Kontena is an open-source system for deploying, managing, scaling and monitoring containerized applications across multiple hosts on any cloud infrastructure. It is primarily targeted for running applications composed of multiple containers, such as elastic, distributed micro-services.”

In the continuing battle for Docker orchestration supremacy, we have seen many different players on the scene, such as Google with its Kubernetes Docker orchestration platform, Docker with its new orchestration tools, and many others. While most of the tools that have come out in Docker-land have been open source, they are often backed by a larger corporation. That isn’t necessarily an issue, except open source projects with large corporate backers often become harder for those outside the corporation to contribute to — as seen in the recent io.js / Node.js issues — and they can be a little over-engineered towards the specific needs of the corporate sponsor.

In contrast to this, Kontena is created by the recently incorporated Kontena, Inc., based in Finland. The code base is an order of magnitude smaller than Kubernetes, and it has a simpler architecture. The architecture of Kontena is influenced by both Docker Swarm and Kubernetes, so it’s had some opportunities to learn from those projects’ mistakes and successes.

Unlock Docker Swarm and Kubernetes, Kontena is implemented in Ruby instead of the Go programming language. As Kontena is influenced by Ruby — and likely, by association, the Rails community — it values convention over configuration. As such, you’ll see that Kontena configuration files are fairly concise and succinct. Like Kubernetes, it works at a level of abstraction higher than containers; the primitive building components of Kontena are called services. The other main components of Kontena’s architecture are the grid, services, the master node, host nodes and the Kontena CLI.

The Grid

The grid is the outermost container of the Kontena system. It provides an overlay network using Weave and OpenVPN to allow inter-service communications across hosts. Out of the box — at least at the time of the release of Kontena, as Docker is currently working on a networking solution — Docker didn’t provide means for cross-host communication. Containers on the same machine can communicate with each other using Docker links, but having containers communicate across hosts has been far more ad-hoc, hence the need for an overlay tool such as Weave. The VPN component is useful as well as it allows you to connect directly to the Kontena master to do administration. Put simply, the grid allows you to treat all your nodes as if the they are on the same local network.

Services

Services are another construct used by Kontena. For those of you familiar with Kubernetes, you will see many familiarities with Kubernetes’ service construct. In both Kubernetes and Kontena, the idea behind services is that containers provide insufficient abstraction for modern software applications. This is because most modern software applications are multi-container, and the specific relationships between these containers is often very important.

Another issue with containers is that they are ephemeral in nature, hence you shouldn’t have any strict dependencies on particular containers. Even when containers get individual IP addresses and ports, that isn’t much help when an individual container goes offline. With Kontena, you launch services instead of containers. Kontena will then manage and scale the individual containers that are part of a service.

Another nice feature of services is that you can state if you want your service to be stateful or stateless. While stateless architectures have many benefits, and are often more simple to understand and manage, they are often impractical. A database service is something that is going to be intrinsically stateful. Most other Docker orchestration systems don’t have have specific facilities for stateful components. In practice, Kontena will automatically mount and manage Docker data volumes for stateful services. This is a really nice feature, as managing volumes using Docker’s native facilities can get rather complex. Additionally, Kontena gives you the ability to link services together, which lends itself very nicely to a modern microservices-based architecture.

The Master Node

Similar to Kubernetes, Kontena works on a master-slave architecture. There is one master node that you administer Kontena through, and several slave nodes that run your underlying services/containers. The idea is that an organization or group will have one master node, through which all administration tasks are done, creating multiple grids if required. In short, this means masters-to-grids are a one-to-many relationship. Unlike some other container orchestration solutions, this master node doesn’t provide any of the underlying processing power, and its purpose is purely for management and to provide audit logging. Kontena’s next construct — called host nodes — are what provide the processing power and run the physical Docker containers.

Host Nodes

Each host node is an actual bare metal or virtual Linux machine, such as an AWS EC2 instance or DigitalOcean Droplet. Each host node is assigned to one — and only one — grid, and communicates with the master node over a secure web socket. Kontena can be configured to automatically provision and assign new nodes to grids when additional capacity is necessary. Host nodes can also be deallocated by Kontena when traffic slows down. All logging and statistics are saved by the master node, as host nodes are also potentially ephemeral.

Kontena CLI

Let’s get a quick taste of how Kontena defines application architectures. If you have played with docker-compose or fig, you will find configuring Kontena very intuitive. While not a one-to-one match, Kontena’s kontena.yml files are very close to docker-compose.yml files. In fact, you can even have a base docker-compose.yml file that you can then extend and reference using a kontena.yml file. For example, let’s say that we had an application that we were building from a local Dockerfile and wanted to link to a mySQL database image:

We can then use and extend the above docker-compose.yml file into a Kontena service:

In a world of increasingly complex container orchestration software, it’s refreshing to see a solution with a focus on intuitiveness and simplicity. It’s also exciting to see some of the new features that Kontena brings to the field, such as its built-in support for stateful containers. It’s a little early in Kontena’s life to say if it will be the next big thing in container orchestration, but I have high hopes of it making some waves on the container scene.

Docker and Weaveworks are sponsors of InApps.

Feature image: “An architecture of participation” by opensource.com is licensed under CC BY-SA 2.0.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.