Syself is an [SCS compatible](https://docs.scs.community/standards/certification/overview/#scs-compatible-kaas) Kubernetes-as-a-Service provider. The [SCS (Sovereign Cloud Stack)](https://sovereigncloudstack.org/en/) 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](/docs/hetzner/apalla/servers-and-nodes/provision/placement-groups) or [bare metal control planes](/docs/hetzner/apalla/clusters/configure/fully-bare-metal-cluster).

## Prerequisites

Go through the Getting started section of the docs first.

It assumes you have already completed the [Prerequisites](/docs/hetzner/apalla/getting-started/prerequisites) described there, have [access to the management cluster](/docs/hetzner/apalla/getting-started/access-the-management-cluster) and have done the [account preparation](/docs/hetzner/apalla/getting-started/prepare-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:

```yaml vars title="cluster.yaml"
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-v4
    version: v1.36.4
    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:

```console
$ 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:

```console vars
$ 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.4
example-jndgf-sb6b8              example   example-jndgf-sb6b8              nbg1             True    True        True         Running   8m    v1.36.4
example-jndgf-vhbsb              example   example-jndgf-vhbsb              nbg1             True    True        True         Running   5m    v1.36.4
example-md-0-zw8ln-pxztl-j4stb   example   example-md-0-zw8ln-pxztl-j4stb   nbg1             True    True        True         Running   4m    v1.36.4
```

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:

```yaml vars title="cluster.yaml"
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-v4
    version: v1.36.4
    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 [HetznerBareMetalHost](/docs/hetzner/apalla/servers-and-nodes/provision/add-bare-metal-servers) resources.

For more information on using bare metal control planes, see [Run bare-metal control planes and clusters](/docs/hetzner/apalla/clusters/configure/fully-bare-metal-cluster).

You can apply the manifest to the management cluster with:

```console
$ 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:

```console vars
$ 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.4
example-jndgf-sb6b8              example   bm-example-2437306                                True    True        True         Running   8m    v1.36.4
example-jndgf-vhbsb              example   bm-example-2702314                                True    True        True         Running   5m    v1.36.4
example-md-0-zw8ln-pxztl-j4stb   example   example-md-0-zw8ln-pxztl-j4stb   nbg1             True    True        True         Running   4m    v1.36.4
```

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:

```console
$ 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:

```console
$ export KUBECONFIG=example-kubeconfig.yaml
```

If you want more information about workload and management clusters, check the [Management and Workload Clusters](/docs/hetzner/apalla/concepts/foundations/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.

## 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](https://sonobuoy.io/):

```console
$ 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](https://github.com/SovereignCloudStack/standards) 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

- [Run bare-metal control planes and clusters](/docs/hetzner/apalla/clusters/configure/fully-bare-metal-cluster), the single-tenant, physical-host option
- [High-availability control plane](/docs/hetzner/apalla/clusters/configure/high-availability-control-plane), sizing and spreading the control plane
- [Sovereignty](/docs/hetzner/apalla/concepts/ownership/sovereign-cloud-stack)