Creating SCS compatible clusters

Introduction

Syself is an SCS compatible Kubernetes-as-a-Service provider. The SCS (Sovereign Cloud Stack) is a European initiative for an open, transparent and vendor-neutral cloud ecosystem that guarantees sovereignty. In order to be conformant, the platform needs to fulfill all requirements in the SCS test suite. One of these requirements is the distribution of nodes across physical hosts for enhanced reliability.

This guide will explain how you can make your own clusters SCS-compatible by using placement groups or bare metal control planes.

Prerequisites

It is suggested that you go through the Getting started section of the docs before reading this guide.

This guide assumes you have already completed the Prerequisites described in there, have access to the management cluster and have done the account preparation.

For creating clusters, you also need to apply the ClusterStacks.

How to make your cluster SCS-compatible

The SCS guidelines require your cluster control plane nodes to be distributed across different physical hosts. This can be achieved in two ways: using placement groups or bare metal control planes.

Using placement groups

The example cluster.yaml below is SCS-compatible. The important parts, which are related to control plane replica count and placement groups, are highlighted:

cluster.yaml yaml

apiVersion: cluster.x-k8s.io/v1beta1 kind: Cluster metadata: name: example spec: clusterNetwork: services: cidrBlocks: ['10.128.0.0/12'] pods: cidrBlocks: ['192.168.0.0/16'] serviceDomain: 'cluster.local' topology: class: hetzner-apalla-1-34-v6 version: v1.34.6 controlPlane: // [!code tooltip:3:1:Use at least three replicas to have a highly available control plane.] replicas: 3 workers: machineDeployments: - class: workeramd64hcloud name: md-0 // [!code tooltip:1:1:We are using one replica to speed up the provisioning. You can change this.] replicas: 1 failureDomain: nbg1 variables: overrides: - name: workerMachineTypeHcloud value: cpx42 variables: - name: region value: nbg1 - name: controlPlaneMachineTypeHcloud value: cpx42 - name: hcloudPlacementGroups // [!code ++] value: // [!code ++] - name: controlPlaneSpread // [!code ++] type: spread // [!code ++] - name: controlPlanePlacementGroupNameHcloud // [!code ++] value: controlPlaneSpread // [!code ++]

And apply it to the management cluster with:

Cluster creation will take a few more minutes. You can monitor the process by looking at the machine objects:

These represent actual machines in your Hetzner project. If all of them are in the Running phase, it means your cluster is ready!

Using bare metal control planes

When using bare metal control planes, every node is tied to its own physical bare metal host, meaning they are also SCS-compatible.

The example cluster.yaml below represents a cluster using bare metal control planes. The important parts, which are related to control plane replica count and class, are highlighted:

cluster.yaml yaml

apiVersion: cluster.x-k8s.io/v1beta1 kind: Cluster metadata: name: example spec: clusterNetwork: services: cidrBlocks: ['10.128.0.0/12'] pods: cidrBlocks: ['192.168.0.0/16'] serviceDomain: 'cluster.local' topology: class: hetzner-apalla-1-34-v6 version: v1.34.6 controlPlane: class: hetznerbaremetal // [!code ++] replicas: 3 // [!code ++] variables: // [!code ++] overrides: // [!code ++] - name: controlPlaneHostSelectorBareMetal // [!code ++] value: // [!code ++] matchLabels: // [!code ++] role: controlplane // [!code ++] cluster: example // [!code ++] workers: machineDeployments: - class: workeramd64hcloud name: md-0 replicas: 1 failureDomain: nbg1 variables: overrides: - name: workerMachineTypeHcloud value: cpx42 variables: - name: region value: nbg1

Before creating a cluster with a baremetal control plane, ensure your HetznerBareMetalHost resources are registered and labeled appropriately.

For more information on using bare metal control planes, refer to this page.

You can apply the manifest to the management cluster with:

Cluster creation will take a few more minutes. You can monitor the process by looking at the machine objects:

These represent actual machines and bare metal servers in your Hetzner account. If all of them are in the Running phase, it means your cluster is ready!

Accessing your cluster

To get the kubeconfig of your workload cluster, you can use the command:

Now, you can change the KUBECONFIG environment variable to point to your new cluster:

If you want more information about workload and management clusters, check the Management and Workload Clusters section.

When accessing your cluster, you may see some pods still pending. This is normal, you just have to wait for it to be completely initialized. When all pods are running and the four nodes are in ready state, it means your cluster is completely provisioned.

And that's it! Now you have a production-ready, SCS-compatible Kubernetes cluster managed by Syself Autopilot.