Kolab can be deployed in many configurations to suit different needs; From small deployments on a single host, to high-availability deployments distributed over many hosts.
These different configurations come with different tradeoffs for scalability, high-availability and hardware requirements, as well as flexibility in management.
Smaller deployments are typically more bespoke in how resources are used, while larger, cluster based, deployments are more dynamic.
The reference architectures can be implemented on bare-metal or in virtual machines, but it is important to consider the failure domains (a high availability deployment on a single hypervisor will not result in high availability).
Reference VM Image
The reference VM image is based on AlmaLinux 9, and all ansible scripts are tailored to this VM image.
Other linux distributions are in principle possible (as long as k3s is available), but documentation and tooling are based on this platform.
Single node with K3S
Run kolab with all components on a single host.
This deployment consists of a single vm, and all workloads are executed in k3s.
This is the simplest deployment mode and suitable if the workload fits on a single system,
and downtime for maintenance or failure is acceptable.
Storage
Local disk storage is consumed via the local-path-provisioner storage provider.
Failure modes
There is no redundancy. Some durability guarantees can be achieved by using RAID disks.
Replicated on two nodes with K3S
Kolab is deployed in a two node K3S cluster, using local storage on the nodes (no shared storage required).
High availability is achieved running HA-Proxy with ip failover via keepalived, with all relevant components replicating between the nodes.
K3S requires an external datastore in this deployment mode, which is provided via a 2-node mariadb galera cluster on the same nodes.
Some load-balancing can be achieved by using services on both nodes, but to have high-availability a single node must be able to handle the complete load.
Both mariadb and HA-Proxy are run outside of k3s for this deployment.
This deployment is more complex in that not all components can be run in k3s, and workloads need to be explicitly assigned to nodes, but it allows to achieve high availability and a limited amount of load-balancing with minimal resources (only two nodes, with local disks).
Storage
Local disk storage is consumed via local-storage PersistentVolumes, pinning the workloads to a specific node.
Failure modes
One out of two nodes can fail with minimal service interruption, provided there is enough capacity on a single node.
Cluster: Three or more nodes with K3S
Run a cluster with 3 or more nodes.
A cluster allows to manage the entire system as a single unit. Storage can be abstracted from the individual nodes, so workloads can move from one node to the other, making the entire system self-healing.
This simplifies management, and makes the system particularly resilient.
Storage
Either use local storage and pin deployments to specific nodes, or set-up a ceph cluster.
Failure modes
One out of three nodes can fail with minimal service interruption.