Skip to content

KubeOne op Hetzner ​

Zet een productie-Kubernetes-cluster op met KubeOne als provisioner.

Vereisten ​

  • lok8s CLI geïnstalleerd
  • hcloud CLI geïnstalleerd en geauthenticeerd
  • Een SSH-sleutelpaar toegevoegd aan je Hetzner-project
  • Hetzner Cloud API-token geëxporteerd als HCLOUD_TOKEN

Clusterconfiguratie ​

Maak clusters/example.com/cluster.lok8s.yaml aan met kind: KubeOne (de map is vernoemd naar je domein) en voer daarna lo use example.com uit. De machines declareer je in de Hetzner-providerbeschrijving: één server-item per node, met de rol in het label lok8s.dev/role. Zie Eerste cluster voor elke sleutel.

yaml
# clusters/example.com/cluster.lok8s.yaml
apiVersion: cluster.lok8s.dev/v1beta1
kind: KubeOne
metadata:
  name: production
spec:
  kubernetes:
    version: "v1.35.5"
  cluster:
    # VERPLICHT: een domein dat je beheert; voor het API-endpoint en certificaten
    domain: example.com
  provider:
    name: hetzner
    config:
      cluster_name: production
      sshUser: root
      sshPrivateKey: ~/.ssh/id_ed25519
      sshPublicKey: ~/.ssh/id_ed25519.pub
      ssh-key:
        - name: production
          public-key-from-file: ~/.ssh/id_ed25519.pub
      network:
        - name: production
          ip-range: 10.0.0.0/16
          "#subnets":
            - network-zone: eu-central
              type: cloud
              ip-range: 10.0.0.0/24
      server:
        - name: cp-1
          type: cpx32
          image: ubuntu-24.04
          location: fsn1
          ssh-key: [0]
          network: 0
          label: lok8s.dev/cluster=production,lok8s.dev/role=control-plane
        - name: cp-2
          type: cpx32
          image: ubuntu-24.04
          location: fsn1
          ssh-key: [0]
          network: 0
          label: lok8s.dev/cluster=production,lok8s.dev/role=control-plane
        - name: cp-3
          type: cpx32
          image: ubuntu-24.04
          location: fsn1
          ssh-key: [0]
          network: 0
          label: lok8s.dev/cluster=production,lok8s.dev/role=control-plane
        - name: worker-1
          type: cpx32
          image: ubuntu-24.04
          location: fsn1
          ssh-key: [0]
          network: 0
          label: lok8s.dev/cluster=production,lok8s.dev/role=worker
        - name: worker-2
          type: cpx32
          image: ubuntu-24.04
          location: fsn1
          ssh-key: [0]
          network: 0
          label: lok8s.dev/cluster=production,lok8s.dev/role=worker

Het voorbeeld gebruikt cpx32 (4 vCPU’s, 8 GB RAM) voor elke server. Elk type met minstens evenveel vCPU’s en RAM dat je Hetzner-account op die locatie aanbiedt, werkt ook.

De voorraad verschilt per account en verandert per uur: weigert Hetzner een type, kies dan een ander type of een andere locatie (fsn1, nbg1 of hel1).

Uitrollen ​

bash
lo provision

Dit doet het volgende:

  1. Hetzner Cloud-servers aanmaken voor control plane en workers
  2. Het privénetwerk opzetten
  3. Kubernetes installeren via KubeOne
  4. De kubeconfig wegschrijven naar .kubeconfig/production.yaml in je project, vernoemd naar metadata.name, modus 0600. Je ~/.kube/config blijft ongemoeid.

De configuratie hierboven vraagt Hetzner om vijf servers (3 voor het control plane en 2 workers), die per uur worden gefactureerd tegen de gepubliceerde prijzen van Hetzner voor die servertypes. Niets hiervan is onomkeerbaar: lo destroy verwijdert wanneer je maar wilt elke server die lok8s heeft aangemaakt.

Verifiëren ​

kubectl wijst nog steeds naar de context die je eerder gebruikte, dus selecteer het nieuwe cluster expliciet; anders antwoordt get nodes voor je vorige cluster:

bash
export KUBECONFIG=.kubeconfig/production.yaml
kubectl get nodes
# (AGE trimmed — VERSION is what to check)
# NAME       STATUS   ROLES           VERSION
# cp-1       Ready    control-plane   v1.35.5
# cp-2       Ready    control-plane   v1.35.5
# cp-3       Ready    control-plane   v1.35.5
# worker-1   Ready    <none>          v1.35.5
# worker-2   Ready    <none>          v1.35.5

HA-overwegingen ​

  • Declareer drie control-plane-servers voor productie
  • Control plane-nodes worden automatisch over fault domains verspreid
  • Het privénetwerk (network[].ip-range) isoleert clusterverkeer

Bootstrap-addons toevoegen ​

Cluster-infra-addons (CNI, CCM, cert-manager, monitoring, …) staan onder spec.bootstrap en worden bij het provisionen in volgorde toegepast:

yaml
  bootstrap:
    - cilium
    - ccm
    - monitoring

Voer lo bootstrap uit om bootstrap-wijzigingen op een bestaand cluster toe te passen; het past spec.bootstrap opnieuw toe en slaat de reconcile van de infrastructuur over. lo provision doet beide en kun je ook veilig opnieuw uitvoeren.

Volgende stappen ​


Documentstatus ​

AspectDetail
Statusactive
Laatst herzien2026-09-05