Secrets as of now are hardcoded given we are using a flavor which is essentially a template. If you want to use your own naming convention for secrets then you'll have to update the templates. Please make sure that you pay attention to the sshkey name.
For bare metal, use the Syself CCM until an upstream release includes PR fix robot name lookup after stale cache miss.
In the long run we (Syself) want to switch from our fork to the upstream CCM.
The CCM is the "Cloud Controller" which runs in the workload-cluster. The most important tasks of the CCM are:
The CCM calls the Hetzner APIs. To authenticate, it reads the credentials from a secret. This secret has to be in the workload cluster, when the CCM runs in the workload cluster. CAPH creates the secret and syncs the credentials specified in the management cluster to the workload cluster. In our default templates this secret is called hetzner . The upstream HCloud chart defaults to a secret called hcloud , so you need to override the secret references when installing the chart.
Important: CAPH and the CCM must both use the same ProviderID format for bare metal. Unfortunately (for historical reasons), there are two formats:
hcloud://bm-NNNN hrobot://NNNN The upstream HCloud CCM uses the new format.
If you use the new format, set the annotation capi.syself.com/use-hrobot-provider-id-for-baremetal to "true" on the HetznerCluster . Our default templates have this annotation set.
If CAPH and the CCM do not agree on the ProviderID format, then new nodes will not be able to join the cluster, because CAPI waits for the wrong ProviderID.
This only applies to new nodes. Once a node has a ProviderID, it will never change. Both CCMs support both formats when the ProviderID is already set.
This applies only to bare metal. HCloud nodes always use the format hcloud://NNNN .
Since we have already created secret in hetzner robot, hcloud and ssh-keys as secret in management cluster, we can create a workload cluster. Generate the manifest by using clusterctl generate :
And apply it:
After a while, our first controlplane should be up and running. You can verify it using the output of kubectl get kcp followed by kubectl get machines
Once it's up and running, you can get the kubeconfig of the workload cluster using the following command:
This is important for the functioning of the cluster otherwise the cluster won't work.
This requires a secret containing access credentials to both Hetzner Robot and HCloud.
For bare metal, use the Syself CCM until an upstream release includes PR fix robot name lookup after stale cache miss.
Be sure that the HetznerCluster has the annotation capi.syself.com/use-hrobot-provider-id-for-baremetal: "true" .
For CNI, let's deploy cilium in the workload cluster that will facilitate the networking in the cluster.
Now, the cluster should be up and you can verify it by running the following commands:
Please note that HCloud servers are prefixed with hcloud:// and bare-metal servers are prefixed with either hcloud://bm- or hrobot:// , depending on your ProviderID format configuration.