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.
Kontena's Architecture
The architecture of Kontena consists of four layers:
- An (potentially external) authentication service
- Masters, each one managing a grid
- Grids, a logical abstraction containing the actual nodes that provide compute power
- And last but not least, your services that will be run on top of these grids.
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.
- Separate authentication server
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.
- Master does access control based on roles and users
Kontena separates authentication from authorization. Each master can assign user rights, per project.
- Audit log
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.
- Vault
Kontena's vault is similar to Kubernetes' secrets.
- Overlay network, OpenVPN support
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.
- Master is server, nodes in a grid clients that connect to the master
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.
- Integrated logging & statistics
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.
- Built-in Docker image registry
There is support to set up a private registry within a grid with just a few commands.
- Built-in Let's Encrypt support
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.
Conclusion
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.
What's next
In the next posts we'll install Kontena on Google Compute Engine and try out some of the examples and see how they behave.
Previous article
