Skip to main content

Build an SCS-compatible cluster

Inspect 1.36

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 or .

Prerequisites#

Go through the Getting started section of the docs first.

It assumes you have already completed the described there, have and have done the .

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:

cluster.yamlyaml
		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-v2
    version: v1.36.3
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: workeramd64hcloud
          name: md-0
          replicas: 1
          failureDomain: nbg1
          variables:
            overrides:
              - name: workerMachineTypeHcloud
                value: cpx41
    variables:
      - name: region
        value: nbg1
      - name: controlPlaneMachineTypeHcloud
        value: cpx41
      - name: hcloudPlacementGroups
        value:
          - name: controlPlaneSpread
            type: spread
      - name: controlPlanePlacementGroupNameHcloud
        value: controlPlaneSpread

And apply it to the management cluster with:

		$ kubectl apply -f cluster.yaml
cluster.cluster.x-k8s.io/example created

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

		$ kubectl get machines
NAME                             CLUSTER   NODE NAME                        FAILURE DOMAIN   READY   AVAILABLE   UP-TO-DATE   PHASE     AGE   VERSION
example-jndgf-r4k7v              example   example-jndgf-r4k7v              nbg1             True    True        True         Running   10m   v1.36.3
example-jndgf-sb6b8              example   example-jndgf-sb6b8              nbg1             True    True        True         Running   8m    v1.36.3
example-jndgf-vhbsb              example   example-jndgf-vhbsb              nbg1             True    True        True         Running   5m    v1.36.3
example-md-0-zw8ln-pxztl-j4stb   example   example-md-0-zw8ln-pxztl-j4stb   nbg1             True    True        True         Running   4m    v1.36.3

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.yamlyaml
		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-v2
    version: v1.36.3
    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: cpx41
    variables:
      - name: region
        value: nbg1

Before creating a cluster with a baremetal control plane, register and label your resources.

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

You can apply the manifest to the management cluster with:

		$ kubectl apply -f cluster.yaml
cluster.cluster.x-k8s.io/example created

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

		$ kubectl get machines
NAME                             CLUSTER   NODE NAME                        FAILURE DOMAIN   READY   AVAILABLE   UP-TO-DATE   PHASE     AGE   VERSION
example-jndgf-r4k7v              example   bm-example-2928603                                True    True        True         Running   10m   v1.36.3
example-jndgf-sb6b8              example   bm-example-2437306                                True    True        True         Running   8m    v1.36.3
example-jndgf-vhbsb              example   bm-example-2702314                                True    True        True         Running   5m    v1.36.3
example-md-0-zw8ln-pxztl-j4stb   example   example-md-0-zw8ln-pxztl-j4stb   nbg1             True    True        True         Running   4m    v1.36.3

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:

		$ kubectl get secrets example-kubeconfig -o=jsonpath='{.data.value}' \
| base64 -d \
> example-kubeconfig.yaml

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

		$ export KUBECONFIG=example-kubeconfig.yaml

If you want more information about workload and management clusters, check the 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.

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#

OIDC configuration for your cluster

Set up OIDC for Kubernetes cluster using token-based auth with your own identity provider and improve your operations.

Check the Kubernetes version and Cluster Stack

Find the Kubernetes version and Cluster Stack release used by a cluster.