Skip to content

Containerization & Kubernetes

Why Kolab is containerized

Kolab's components are packaged and distributed as OCI containers that can be run via various tools such as podman, docker or kubernetes.

Containers address a couple of concerns:

Kolab consists of a set of existing open source components, such as cyrus-imap and postfix. While Kolab technically can be made to work with alternatives, such as Dovecot IMAP instead of cyrus-imap, this results in essentially a new product with it's own set of issues and needs to be developed/validated/managed accordingly. It is therefore beneficial to have exactly one defined software configuration of each component. This ensures that we run what's being tested and that we take responsibility in what's included in Kolab, which is paramount to ensure environments are reliably reproducible, so that each installation doesn't have to be treated individually.

Many of the components that Kolab uses have a vast amount of configuration options, allowing one to build entirely different things just based on configuration. When we talk about Postfix in Kolab for instance, we expect a specific configuration, and containers provide the means to ensure that all components run with the expected configuration.

Another benefit of the container model is that we get a very clear separation for the "state". All state is written to mounted volumes in the containers, and the containers themselves are by definition ephemeral.

Finally, Kolab delivers a software solution that can be fully built from source, and containers provide a readily available build-system to build all components directly from source. This is a huge benefit in comparison to maintaining completely separate package building infrastructure for a variety of platforms, and provides Kolab with a great developer where all components are readily available to modify, build and distribute changes.

Why Kubernetes & Helm

While containers provide great building blocks for the overall solution, it is ultimately required to orchestrate the execution of the various workloads in a defined configuration.

Kubernetes provides us with:

  • A uniform model to orchestrate workloads on one or more nodes (servers).
  • A communication plane for the individual workloads to communicate with each other.
  • A solution to monitor and supervise the various workloads and to collect the logs.
  • A declarative specification of the workloads to run.
  • A uniform way to execute administrative tasks on the command line, that is independent from where the workload is running.

Kubernetes uses a verbose declarative specification to schedule the workloads, which is unwieldy to use directly, but lends itself to automation. Helm provides us with a templating mechanism that renders that configuration from a much more use-friendly configuration file, with well defined configuration points, which leads to uniform and standardized deployments that can be better understood and analyzed.

This approach then also allows for a GitOps approach where the expected state of the system can be fully tracked in version control.