Build an SCS-compatible cluster

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.

Syself builds the Kubernetes-as-a-Service layer for the Sovereign Cloud Stack (the SCS VP-05 tender), and Syself Autopilot runs the same Cluster Stacks framework, so a Syself Autopilot cluster starts from a conformant base. A Syself Autopilot cluster already provides the tested Kubernetes layer, a supported CNI, storage integration, and lifecycle management; what you add for SCS compatibility is spreading nodes across physical hosts, shown below.

You can make your own clusters SCS-compatible by using placement groups or bare metal control planes .

Prerequisites 

Go through the Getting started section of the docs first.

It assumes you have already completed the Prerequisites described there, have access to the management cluster and have connected your Hetzner account .

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 

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

You can also build one in the Cluster Configurator : turn on placement groups there and export the matching manifest instead of writing it by hand.

				apiVersion: cluster.x-k8s.io/v1beta2
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:
    classRef:
      name: hetzner-apalla-1-36-v9
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: workeramd64hcloud
          name: md-0
          replicas: 1
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cpx42
    variables:
      - name: region
        value: nbg1
      - name: controlPlaneMachineTypeHcloud
        value: cpx42
      - name: hcloudPlacementGroups
        value:
          - name: controlPlaneSpread
            type: spread
      - name: controlPlanePlacementGroupNameHcloud
        value: controlPlaneSpread
			

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:

				apiVersion: cluster.x-k8s.io/v1beta2
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:
    classRef:
      name: hetzner-apalla-1-36-v9
    controlPlane:
      class: hetznerbaremetal
      replicas: 3
      variables:
        overrides:
          - name: controlPlaneHostSelectorBareMetal
            value:
              matchLabels:
                role: controlplane
                cluster: example
    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, register and label your HetznerBareMetalHost resources.

For more information on using bare metal control planes, see Bare-metal control planes .

Create the cluster 

To create the cluster from your manifest, follow Create a cluster . It shows how to apply the manifest, check that the cluster is ready, and get its kubeconfig.

The conformance tests below use that kubeconfig, saved as example-kubeconfig.yaml.

Prove conformance yourself 

Being SCS-compatible is something you can verify against your own cluster, not just take on trust. Two suites matter, and both run against the workload cluster's kubeconfig.

CNCF conformance with sonobuoy 

The upstream CNCF conformance suite checks that your cluster is a standard, conformant Kubernetes. Run it with sonobuoy⁠:

				$ sonobuoy run --mode=certified-conformance --kubeconfig example-kubeconfig.yaml
$ sonobuoy status --kubeconfig example-kubeconfig.yaml
$ results=$(sonobuoy retrieve --kubeconfig example-kubeconfig.yaml)
$ sonobuoy results $results
			

Wait until sonobuoy status reports the run is complete. A passing run reports no failed tests. Clean the run up afterwards with sonobuoy delete --wait --kubeconfig example-kubeconfig.yaml.

SCS Kubernetes checks 

The SCS project publishes its own conformance tests for the Kubernetes-as-a-Service layer, including the node-distribution requirement you configured above. Run them from the SCS standards tooling⁠ against the same kubeconfig and read the report it produces.

What this does not cover 

• This makes the Kubernetes layer SCS-compatible. It does not cover the underlying IaaS layer, which is Hetzner's infrastructure.
• It is not a formal Syself SCS certification. It shows that your own cluster meets the Kubernetes-layer requirements and lets you run the suites to prove it.
• It does not involve a hardware trust anchor such as a TPM.

Related 

• Bare-metal control planes , the single-tenant, physical-host option
• Configure control planes , sizing and spreading the control plane
• Sovereignty