Zum Inhalt springen

Deinen ersten Cluster anlegen

Das ist der erste Schritt des Lernpfads. Du legst den Cluster an, den du für die folgenden Schritte behältst, und diesmal ist jede Entscheidung bewusst: ein eigenes Hetzner-Projekt, ein eigenes Token im Cluster, die Kubernetes-API nur für dich offen, und ein Bucket für die Snapshots. Danach findest du jedes Teil des Clusters wieder, in deinem Hetzner-Projekt und in Kubernetes.

Einen k3s-Cluster mit einem Node namens upcheck-prod, für die Produktion einer App. Der Lernpfad deployt upcheck, eine kleine Django-App, und benennt jeden Cluster nach App und Stage; Schritt 4 stellt upcheck-staging neben diesen.

Er kostet 29 € inkl. MwSt. im Monat, außerhalb der EU 29 US-$ zzgl. anfallender Steuern. Ist er der erste Cluster deines Teams, startet er das Abonnement des Teams und kostet den vollen Monat, auch wenn du ihn früher löschst. Hast du den Cluster first aus dem Schnellstart behalten, lösch ihn, sobald upcheck-prod bereit ist: Dann ist er nicht mehr der einzige Cluster des Teams, und der Rest seines Monats wird gutgeschrieben. In Arbeit Die Abrechnung über Paddle ist noch nicht gelaufen.

  • Ein neues Hetzner-Cloud-Projekt, nur für deine Cluster. Ein Hetzner-API-Token öffnet sein ganzes Projekt, lesend und schreibend; eine engere Art bietet Hetzner nicht an. Ein eigenes Projekt beschränkt diese Reichweite auf deine Cluster.
  • Zwei API-Tokens dieses Projekts, beide Read & Write, aus Security → API tokens in der Hetzner-Konsole. Das erste ist für das Portal, das den Server anlegt. Das zweite ist für den Cluster selbst: Sein Cloud Controller und sein Volume-Treiber brauchen eines. Ein Pod, der das zweite Token liest, hält nie das erste, und du kannst es für sich allein widerrufen.
  • Einen S3-Bucket mit Access Key und Secret Key, für die Snapshots. Ein Bucket bei Hetzner Object Storage am Standort des Clusters kostet am wenigsten. In Arbeit Hetzner Object Storage selbst ist mit PaaSbox noch nicht gelaufen; das Labor nutzte an seiner Stelle einen selbst betriebenen S3-Server.
  • Die öffentliche IP-Adresse, von der aus du arbeitest, um die Kubernetes-API für sie zu öffnen und für nichts sonst.
  • kubectl auf deinem Rechner und einen Browser mit JavaScript.
  1. Das Projekt verbinden. Öffne PaaSbox Clusters → Hetzner projects, wähle Add a Hetzner project, trag einen Project name ein, füge das erste Token unter HCLOUD_TOKEN (read/write) ein und wähle Validate & connect. Liegen im Projekt schon andere Ressourcen als Server, etwa Netze oder Snapshots, listet das Portal sie auf und bittet dich zu bestätigen, dass das Projekt für PaaSbox reserviert ist. Ein neues Projekt hat keine.

  2. Ihn benennen. Wähle New cluster. Trag als Name upcheck-prod ein und lass das DNS label leer: Es wird aus dem Namen gebildet. Das DNS-Label wird der erste Teil des Namens der Kubernetes-API und lässt sich später nicht ändern.

  3. Den Server wählen. Lass A new server stehen. Wähle einen Standort (Location) nahe bei deinen Nutzern und den Servertyp (Server type) cpx22: 4 GB Speicher tragen den Cluster und eine kleine App. Lass den Kanal auf stable und die Topologie auf Single node. Lass PaaSbox Platform auf No platform; Schritt 2 schaltet sie an.

  4. Das Wartungsfenster setzen. Voreingestellt sind Samstag und Sonntag, 02:00 bis 05:00 Uhr, Europe/Berlin. Das Fenster ist für Upgrades und Neustarts von k3s, und jedes Upgrade startet den Node neu, also wähle Stunden, in denen niemand die App nutzt. In Arbeit Dass eingeplante Upgrades und Neustarts auf das Fenster warten, ist auf einem echten Cluster noch nicht gelaufen.

  5. Die Snapshots auf deinen Bucket richten. Lass Who holds the bucket’s keys beim Portal (ob das Portal deine Snapshots lesen kann, hängt davon ab, wer die Schlüssel hält). Trag den S3 endpoint als Hostnamen ohne https:// ein, den Bucket, den Folder upcheck-prod und die Region, dann Access key und Secret key. Lass den Zeitplan stehen: alle sechs Stunden ein Snapshot, die letzten 28 bleiben, das sind sieben Tage.

  6. Die API nur für dich öffnen. Ersetze unter Who may reach the Kubernetes API (port 6443) die Einträge 0.0.0.0/0 und ::/0 durch deine Adresse, zum Beispiel 203.0.113.7/32. Die Ports 80 und 443 bleiben für alle offen, für deine App; Port 22 bleibt zu.

  7. Dem Cluster ein eigenes Token geben. Lass unter Hetzner token inside the cluster die Option A separate token (recommended) stehen und füge das zweite Token ein.

  8. Anlegen. Wähle Create cluster und verfolge die Schritte auf der Seite des Clusters. Der Cluster ist bereit, wenn pbx-agent eine gesunde Kubernetes-API meldet; im Labor dauerte das 2 Minuten 46 Sekunden, 69 davon für das Kopieren des Node-Images in das neue Projekt.

Öffne das Projekt in der Hetzner-Konsole. Alles, was das Portal für den Cluster angelegt hat, trägt die Labels pbx-cluster=<die ID des Clusters> und pbx-managed=true, so unterscheidest du es von allem anderen:

  • den Server upcheck-prod-cp-1, angelegt aus einem Snapshot mit dem Label pbx-image: das Node-Image, einmal ins Projekt kopiert;
  • ein privates Netz, 10.0.0.0/16 mit dem Subnetz 10.0.1.0/24;
  • eine Firewall, die Port 6443 von deiner Adresse, die Ports 80 und 443 von allen und ICMP hereinlässt, und sonst nichts;
  • eine primäre IPv4-Adresse.

Die Seite des Clusters zeigt oben den Namen der Kubernetes-API. Er lautet upcheck-prod.<dein Team>.k3s., gefolgt von der Zone von PaaSbox, und zeigt auf diese Adresse.

  1. Wähle auf dem Reiter Access des Clusters admin und 1 hour, dann Get kubeconfig und Download kubeconfig. Eine view-Kubeconfig wäre nur lesend und könnte die Nodes nicht auflisten.

  2. Lass dir den Node zeigen und was darauf läuft:

    Terminal-Fenster
    export KUBECONFIG=~/Downloads/upcheck-prod-admin.kubeconfig
    kubectl get nodes -o wide
    kubectl get pods -A

    Ein Node, upcheck-prod-cp-1, Ready, mit der k3s-Version aus dem Release des Clusters. Die Pods sind CoreDNS, Traefik auf den Ports 80 und 443, metrics-server, der Hetzner Cloud Controller und der Treiber für Volumes auf der Platte des Servers. Im Labor belegte ein frischer Cluster 1,2 GiB vom Speicher des cpx22.

  3. Sieh dir den Speicher an und die beiden Secrets, die pbx-agent geschrieben hat:

    Terminal-Fenster
    kubectl get storageclass
    kubectl -n kube-system get secret hcloud pbx-etcd-s3

    local-lvm-thin ist die Standardklasse: Volumes auf der eigenen Platte des Servers. Das Secret hcloud hält das zweite Token, für den Cloud Controller und den Volume-Treiber; pbx-etcd-s3 hält Adresse und Schlüssel deines Buckets, die k3s bei jedem Snapshot liest.

  1. Wähle auf der Overview des Clusters Snapshot now. Operations zeigt seine Schritte; im Labor war ein Snapshot nach 25 Sekunden im Bucket.

  2. Öffne Backups. Der Snapshot steht unter Snapshots, und Where sagt, dass er in S3 liegt. Sieh in deinem Bucket nach: Die Datei liegt im Ordner upcheck-prod.

Einen Cluster für die Produktion einer App, in einem eigenen Projekt, mit der API nur für dich offen, einem eigenen Token für den Cloud Controller und Snapshots in deinem Bucket alle sechs Stunden. Behalte ihn: Der nächste Schritt deployt die App darauf.