Erster Cluster

Eine detaillierte Erläuterung der Konfigurationsdatei cluster.lok8s.yaml.

Voraussetzungen

• lok8s CLI installiert
• Ein Hetzner Cloud-Konto mit einem API-Token
• Ein SSH-Schlüsselpaar (Ed25519 empfohlen)

Vollständige Konfigurationsreferenz

# cluster.lok8s.yaml
apiVersion: cluster.lok8s.dev/v1beta1
kind: KubeOne
metadata:
  name: my-cluster
spec:
  kubernetes:
    version: "v1.35.5"
  cluster:
    domain: example.com          # Cluster-Domain fuer Ingress/Zertifikate
    namespace: default           # Standard-Namespace fuer Workloads
  provider: hetzner
  hcloud:
    region: fsn1                 # fsn1, nbg1 oder hel1
    sshPublicKeyFile: "~/.ssh/id_ed25519.pub"
    network:
      cidr: "10.0.0.0/16"       # Bereich des privaten Netzwerks
  ssh:
    user: root
    publicKeyFile: "~/.ssh/id_ed25519.pub"
    privateKeyFile: "~/.ssh/id_ed25519"
  controlPlane:
    replicas: 3                  # 1 fuer Dev, 3 fuer HA-Produktion
    type: cx33                   # Hetzner-Servertyp
  workers:
    platform:
      replicas: 2
      type: cpx31                # oder 'dedicated' fuer Bare Metal
  bootstrap:                     # Cluster-Infra-Addons, in Reihenfolge angewendet
    - cilium                     # CNI (Standard, wenn weggelassen)
    - ccm                        # Hetzner cloud-controller-manager
    - cert-manager
    - monitoring
  kubehz:
    hosting: self                # 'self' (verfuegbar) oder 'hosted' (Early Access)
    access: registered           # 'none', 'registered' oder 'managed' (Supporter+)
    apiUrl: https://api.kubehz.cloud

Wichtige Abschnitte

spec.kubernetes

Legt die Kubernetes-Version fest. Unterstützte Versionen: v1.33 bis v1.35.

spec.hcloud

Hetzner-Cloud-Einstellungen. region bestimmt den Standort des Rechenzentrums. Das Feld network.cidr definiert das private Netzwerk für die Pod-zu-Pod-Kommunikation.

spec.controlPlane

Verwende replicas: 1 für Entwicklungs-Cluster und replicas: 3 für Produktions-HA. Das Feld type ist den Hetzner-Servertypen zugeordnet.

spec.workers

Definiere einen oder mehrere Worker-Pools. Jeder Pool gibt replicas und type an. Verwende dedicated für Bare-Metal-Server.

spec.bootstrap

Eine geordnete Liste von Cluster-Infra-Addons (CNI, CCM, cert-manager, Monitoring, …), die beim Provisionieren angewendet werden, bevor Workloads landen. Jeder Eintrag wird angewendet und abgewartet, bevor der nächste folgt. Blanke Namen lösen zu lok8s-Framework-Addons auf; ./pfad-Einträge zeigen auf deine eigenen Kustomize-Verzeichnisse. Wenn weggelassen, ist der Standard cilium — jeder Cluster braucht ein CNI. Die vollständige Liste steht im lok8s-Addons-Guide.

spec.kubehz

Optionale Integration der kubehz-Plattform auf zwei unabhängigen Achsen. Heute verfügbar: hosting: self mit access: registered — du betreibst den Cluster auf deinem eigenen Konto und kubehz gibt dir schreibgeschützte Dashboard-Sichtbarkeit. hosting: hosted (kubehz betreibt die Control Plane) ist im Early Access; access: managed fügt kubehz' Verwaltungsfunktionen auf registered obendrauf — Healing-Richtlinien, Kapazitäts-Überwachung und die Verwaltung des gewünschten Zustands, gesteuert aus dem Dashboard — und erfordert ein Supporter-Abo oder höher. Das Ausführen ist Pull-basiert: Der clusterinterne Agent holt den gewünschten Zustand von der Plattform ab und wendet ihn mit den eigenen Zugangsdaten deines Clusters an — kubehz hält niemals eingehenden Zugriff. Siehe Wie es funktioniert für das vollständige Modell und die Vertrauensgrenze sowie Registrierung, um die Sichtbarkeit zu aktivieren.

Cluster bereitstellen

lo provision

Überprüfen

kubectl get nodes
kubectl get pods -A

Nächste Schritte

• Dashboard-Einrichtung — deinen Cluster überwachen
• Registrierung — mit dem kubehz-Dashboard verbinden
• KubeOne-Leitfaden — fortgeschrittene KubeOne-Konfiguration

---

Doku-Status

Aspekt	Detail
Zustand	aktiv
Zuletzt geprüft	2026-07-10