Kubernetes across three Swiss datacenters

A cluster created in the console, and the kubeconfig downloaded from its page. A namespace for the workload to spread. Nothing to install on the nodes: Talos exposes neither SSH nor an admin shell, and the control plane is operated by Hidora SA.

In the console, create or edit a node group with a minimum and maximum node count. Plan for at least three nodes so the workload can actually occupy the three sites. Hikube places workers across Geneva, Gland and Lucerne: you do not choose a node’s datacenter, which is exactly why the next step matters.

This is the part that falls to you, and it is not optional. Without it, nothing stops your replicas from landing on the same node. Add topology spread constraints to your deployment to spread the pods, and a PodDisruptionBudget to bound how many replicas can be unavailable at once. Hikube spreads the nodes; spreading the pods across those nodes is your declaration.

Count the nodes actually present with kubectl get nodes, and check the budget is honoured with kubectl get pdb: the ALLOWED DISRUPTIONS column must be greater than zero, otherwise a node cannot be drained without cutting the service. The cluster page in the console shows the node groups and their node count.

Four distinct things, often conflated. Replication sits at the volume level: your data exists in several copies across the three sites, included in the volume price. Application availability sits at your pods: it comes from step 3, not from replication. RPO, the amount of data lost, depends on the volume’s replication mode, synchronous or asynchronous. RTO, the time to restore service, is not covered by the SLA: repair times are not guaranteed and no MTTR is published; a committed deadline is contracted case by case. Concretely, if a site goes down the nodes of the other two remain, and your pods survive only if you declared the spread and the PDB. SLA scope: the security and compliance evidence.