Some weeks ago, I encountered Kontena. It is an open source project for containerized application orchestration, that does things a little different compared to the currently big players, such as Kubernetes and Mesos.
Before we continue with looking at what makes Kontena different, you should know about the architecture of Kontena.
The architecture of Kontena consists of four layers:
In general, orchestrators are software systems that manage where which container runs, and often provide additional features such as failure recovery.
Apart from these standard features that most orchestrators have, Kontena has some interesting additional features. I've ordered them based on what I think is most important, with an explanation of what each feature entails.
All interactions with Kontena must be done from a user context. This user context is provided by an authentication provider, which can either be self hosted, or the one centrally hosted by Kontena. I think this is an important feature, since it decouples user authentication from the master. This would allow easy integration with an enterprise's LDAP infrastructure, for example.
Kontena separates authentication from authorization. Each master can assign user rights, per project.
Kontena logs all events that happen, and actions triggered by users via the CLI or API to an audit log. This is a very desirable feature for enterprises in highly regulated fields, which often must store proofs of how their environment is managed.
Kontena's vault is similar to Kubernetes' secrets.
Kontena uses Weave Net to provide an overlay network for each grid. It's trivial to add an OpenVPN server to a grid to have access to the internal services. This is useful to get access to a development cluster, or to access the build-in Docker image registry.
This feature makes it possible to run nodes in a grid in a more restricted network environment, which is useful both for cloud and on-premise setups.
Kontena runs cAdvisor on each node. By default, the CLI tool reports a time-based window, but it's easy to configure an external statsd service.
There is support to set up a private registry within a grid with just a few commands.
Kontena's core product also supports Let's encrypt integration. Admittedly, this reduces the work to make Let's Encrypt work, but I'm not sure that this should be a core feature of the product. A plugin might be more suitable.
I'd also like to touch on the implementation language. Kontena is implemented in Ruby, which is an interesting choice against the trend of implementing orchestrator platforms in more low level languages. Kubernetes and Nomad are implemented in Go and Mesos is mostly a mix of C++ and Java. I believe that for a smaller project such as Kontena, this can be an advantage. Ruby is a more expressive language than C++, Java or Go. This implies that new features could be implemented faster than their competitors.
I think that Kontena has all the basic ingredients to become a successful container orchestration platform for enterprises. The separate authentication server requirement, fine grained access control options and a good audit log make it especially attractive to enterprise environments.
More competition for different container orchestration platforms is always a good thing to speed up innovation in this space. The biggest remaining question is if these features are compelling enough to gather a big enough community of users that use, and want to contribute to Kontena. At the time of writing, according to GitHub' Kontena has 27 contributors. Compared to Kubernetes (918), Nomad (122) and Mesos (211), this is quite a low number, and might prevent them from reaching feature parity, or implement more/better features than the big boys in the orchestration space.
In the next posts we'll install Kontena on Google Compute Engine and try out some of the examples and see how they behave.
