What Cozystack is made of

Let’s start with the question the exam asks more often than any other: what is Cozystack by nature? Not “what is it for”, but what exactly it is made of.

The short answer: it is Kubernetes with new object types added. Not a fork, not a layer on top of someone else’s API, not a separate management server. When you ask the platform for a database, you create an object — just like a pod or a service, except it is called Postgres. From there an operator program watches it and does everything else.

It is worth getting this into your head before anything else, because almost everything else follows from it. Does kubectl work? It does. Does Terraform work? It does. Are permissions granted through ordinary RBAC? Yes, ordinary RBAC.

Three layers

The platform is built from three floors, and mixing up their order is the most common mistake on the exam.

Talos Linux is the node operating system (node OS). What sets it apart is that it has no command line: no SSH, no console, no package manager. It is configured declaratively, through its own API: you send a description of the desired state, and the node brings itself into line with it. The root filesystem is read-only.

For an administrator used to logging into a server and tweaking something, this feels uncomfortable at first. The point is elsewhere: if you cannot log in and tweak things, the node’s state does not drift over time. Two nodes built from the same description will still be identical a year later.

What gets installed is not stock Talos but the platform’s own image: it adds the DRBD kernel modules — LINSTOR replication depends on them — and ZFS. The regular image does not have them.

Kubernetes is the management cluster, running on top of Talos. Ordinary, unmodified: the same API, the same controllers.

Two different concepts are easy to confuse here. There is one management cluster — that is the platform itself. The clusters that tenants order (tenant clusters) are already its product: their control plane runs as pods inside the management cluster.

Cozystack is a set of components installed into that cluster. They are what add the new object types and watch over them.

Installation in three stages

The exam asks not about commands but about the order and meaning of the stages.

1. Talos on the nodes. The machines boot from the platform image and receive a machine configuration. There are three ways to do it: boot-to-talos — an installer that writes Talos to disk from an already running Linux, booting from an ISO, and network boot via PXE. PXE is served by two temporary containers: Matchbox serves the image over HTTP, and dnsmasq provides DHCP and TFTP.
2. Kubernetes. The management cluster is assembled from these nodes. The recommended tool is Talm, the platform’s own Talos configuration manager with Helm-style templates.
3. Cozystack. The platform itself is installed into the cluster, and from there it deploys its components on its own. It is installed with the cozy-installer chart into the cozy-system namespace, and then a single YAML is applied — the Platform Package. This is the only point of configuration: the platform domain, the apiserver address, address ranges, and the chosen installation variant.

The third stage works in an interesting way: the platform does not install components from a list; it describes the desired composition and hands it to FluxCD. From then on Flux brings the cluster into line with the description itself and keeps watching that the composition does not drift. Upgrading the platform means changing the version in the description, not rebuilding by hand.

Flux installs each platform component as a separate release — the object is called HelmRelease, abbreviated to hr in commands. So the question “is the platform up” is a question about releases, not about pods:

kubectl get hr -A

All of them in the READY True state — the installation is complete.

Four installation variants

The platform is not installed as a whole but as one of four sets. You need to know the names verbatim — and here is why this is not nitpicking: in version 1.5 they were renamed, and the old names (paas-full, distro-full and the like) live on in other people’s articles. It is easy to mix them up.

It is easier to remember as a single phrase: isp-full — everything on Talos, -generic — the same on other distributions, -hosted — only the platform, the infrastructure underneath is someone else’s, default — from scratch and by hand.

You choose once, at installation. Changing the set on a running platform is not a switch; it is a reinstallation.

The variant sets the default composition, and fine-tuning is done with packages. Every platform component is a package named cozystack.<component>, and you can see their state with a single command:

kubectl get package

Two keys in the Platform Package let you adjust the set: bundles.enabledPackages adds packages on top of the variant, bundles.disabledPackages removes them. A caveat that the exam asks about: packages can be disabled only before installation. A component will not be removed from a running platform this way — you will have to remove it by hand through Helm.

What it consists of

There are many components, but the exam asks who is responsible for what, not for the full list. Keep this map in your head:

The row about Kamaji is worth memorizing separately: it runs the control plane of tenant clusters as pods right in the management cluster — a tenant does not need separate machines for control-plane nodes.

Note what is not on the list: Prometheus and Loki. They are often slipped into answer options as a trap — metrics and logs here are collected by VictoriaMetrics and VictoriaLogs.

Hardware requirements

The numbers are asked verbatim, so you will have to learn the minimum profile as it is: three nodes, each with 8 cores, 24 GB of memory and two disks — 50 GB for the system and 256 GB for data. Two disks are not a whim here: the second one is given to LINSTOR. Fewer than three nodes gives fault tolerance neither to storage nor to the control plane.

The network is specified no less strictly: all nodes in one L2 segment, latency between them under 10 ms round-trip time (RTT).

If the nodes are themselves virtual — a lab in vSphere or Proxmox — enable nested virtualization and CPU flag passthrough. On bare metal this is not needed. A home lab built to this minimum is a legitimate way to go through the whole getting-started guide.

The platform is assembled. Next it has to be divided among someone — that is what the next lesson is about.

Learn more: platform overview · installation · getting started