FAQs

General

F: Was ist Kubernetes

Kubernetes (K8s) ist ein Open-Source-System zur Automatisierung der Bereitstellung, Skalierung und Verwaltung containerisierter Anwendungen (siehe Kubernetes Dokumentation).

F: Was is SKE?

STACKIT Kubernetes Engine (SKE) ist ein robuster, skalierbarer und verwalteter Kubernetes-Service. SKE bietet CNCF-zertifizierte Kubernetes Cluster und vereinfacht damit die Bereitstellung und Verwaltung von containerisierten Anwendungen. Benutzerdefinierte Kubernetes Cluster können einfach per Self Service über das STACKIT Cloud Portal erstellt und verwaltet werden.

F: Wie funktioniert SKE?

Der SKE Service stellt sicher, dass alle Control Plane Komponenten Ihres SKE Clusters stabil laufen. Sie können zur Bereitstellung und Betrieb Ihrer Anwendungen mit Hilfe einer Kubeconfig auf Ihr Cluster zugreifen. Im Hintergrund laufen konfigurierbare SKE Komponenten, die die nötigen Betriebssystem und Kubernetes Versions-Updates sicherstellen. Zudem bietet SKE Mechanismen zur Kosteneinsparung wie Ruhezustand und die automatische Skalierung von Node Pools.

F: Warum sollte ich SKE nutzen?

SKE ist eine CNCF-zertifizierter Managed Kubernetes Anbieter. Der Service verwaltet die Control Plane des Kubernetes Clusters und erlaubt es Ihnen Ihre Anwendungen zu betreiben, ohne Ihre Ressourcen in den Betrieb eines solchen Clusters investieren zu müssen.

Kubernetes

F: Kann ich bereits vorhandene Kubernetes-Anwendungen und -Tools auch für Kubernetes verwenden?

Ja, SKE stellt einen vollständig upstream-kompatiblen Kubernetes Service zur Verfügung.

F: Welche Kubernetes Versionen kann ich auswählen?

Für einen Überblick aller aktuell verfügbaren Kubernetes Versionen öffnen Sie bitte die Kubernetes Cluster-Erstellungs-Oberfläche im STACKIT Cloud Portal. Allgemein wird versucht alle neuen Kubernetes Versionen so schnell wie möglich auf SKE anzubieten. Dabei werden immer die 3 aktuellsten Versionen unterstützt und mit Updates versorgt.

F: Kann ich Windows Container auf SKE betreiben?

Nein, da SKE aktuell keine Windows Nodes unterstützt.

F: Welche Container Runtimes kann ich nutzen?

Abhängig von der gewählten Betriebssystem-Version werden containerd und docker als OCI Runtimes unterstützt.

Cluster Management

F: Wie lange dauert die Erstellung eines SKE-Clusters?

Die Clustererstellung dauert in der Regel ca. 5-10 Minuten. In dieser Zeit wird SKE automatisch alle erforderlichen Nodes erstellen und die Komponenten der Control Plane starten. Es wird auch gewartet, bis alle Komponenten (z.B. der Kubernetes-API-Server) bereit sind, sodass Sie direkt loslegen können, sobald Ihr Cluster verfügbar ist.

F: Wie funktioniert das Löschen von Clustern?

Der Löschprozess kümmert sich um eine geordnete Löschung der Clusterresourcen. Die SKE Gebühren fallen nur für die Cluster an, die sich nicht im Status des Löschprozesses befinden.

F: Was muss ich sichern?

Die Control Plane Ihres Clusters wird durch SKE gesichert. Diese Art der Sicherung erfolgt vollständig automatisiert und wird für die Notfallwiederherstellung verwendet. Es ist nicht als Kundenservice-Tool gedacht. Die Daten auf den Worker Nodes und Daten in Persistent Volumes werden nicht automatisch gesichert. Bitte verwenden Sie ein Tool wie Velero, um diese Ressourcen selbst zu sichern.

F: Kann ich ein SKE Cluster herunterfahren?

Ja, die Cluster können in den Ruhezustand versetzt werden. Dadurch werden alle vorhandenen Worker Nodes gelöscht und somit die Kosten Ihres Clusters drastisch reduziert. Die Control Plane und Persistent Volume Claims (PVCs) bleiben jedoch erhalten. Sobald Sie das Cluster aufwecken, wird alles wiederhergestellt, wie es vor dem initiierten Shutdown war.

F: Kann ich den Zugriff auf den Kubernetes-API-Server einschränken?

Aktuell sind alle Kubernetes-API-Server mit öffentlichen IP-Adressen erreichbar. Sie können den Zugriff auf die Kubernetes-Ressourcen basierend auf ServiceAccounts, Roles und RoleBindings einschränken.

F: Wirkt sich ein OS- oder Kubernetes-Upgrade auf den laufenden Workload aus?

Nein, alle Updates werden als Rolling-Updates ausgeführt. Daher sollten sich diese nicht auf laufende Applikationen auswirken, solange das Pod Disruption Budget Ihrer Anwendung richtig konfiguriert ist.

F: Wie kann ich Audit Logging für mein SKE Cluster verwenden?

STACKIT bietet einen Audit Log Service an. Audit-Logs sind der Schlüssel zur Beantwortung der Frage: "Wer hat was, wann und wo getan?" 

Im STACKIT Audit Log werden jegliche Anfragen gespeichert, die über die SKE-API geschickt werden. Dies inkludiert beispielsweise Clustererstellung, Änderungen am SKE-Cluster (z.b. Aktualisierungen der Kubernetes-Version, Änderungen an Node Pools, Credentials-Rotation usw.), Löschung des Clusters und vieles mehr. 

Zusätzlich können Sie Audit Logging für die Control Plane Ihres Kubernetes Clusters beantragen. Dafür benötigen Sie ein SKE-Cluster und eigenen Splunk-Index zur Speicherung der Audit-Logs. Kontaktieren Sie dafür bitte den STACKIT Support mit diesen Informationen.

Wichtige Hinweise:

  • Die Bereitstellung und Verwaltung des Splunk-Index liegt in Ihrer Verantwortung
  • Sie können die Granularität und den Umfang der Audit Events nach der Aktivierung nicht selbst konfigurieren - wenden Sie sich bei Änderungswünschen an den STACKIT Support

F: Wie aktualisiere ich meinen Kubernetes-Cluster auf eine neue Version?

Es gibt folgende Updatearten: automatische Updates (Kubernetes Versionsupdates werden automatisch ausgeführt), manuelle Updates (über das STACKIT Portal, notwendig für Kubernetes Minor Versions-Updates) und erzwungene Updates (wenn eine Version abgelaufen ist, wird ein Update erzwungen).

Für weitere Informationen siehe: Aktualisieren und Pflegen eines SKE Clusters.

F: Wie kann ich das Betriebssystem meiner Worker Nodes aktualisieren?

Betriebssystemversionsaktualisierungen für Node Pools werden im Allgemeinen automatisch während des Wartungsfensters des Clusters ausgeführt, solange diese Option nicht deaktiviert ist. Wenn Sie eine neue Preview-Version ausprobieren möchten, haben Sie die Möglichkeit, den Node Pool im STACKIT Cloud Portal manuell zu aktualisieren.

Weitere Informationen finden Sie unter Aktualisieren und Pflegen eines SKE Clusters.

F: Warum dauert mein Node-Update länger als erwartet?

Immer wenn ein Rolling-Node-Update durchgeführt wird (z.B. Kubernetes oder OS Version-Update), versucht SKE automatisch jede Node nacheinander (sofern nicht anders konfiguriert) zu aktualisieren.

Manchmal können PodDisruptionBudgets (PDBs) die Aktualisierung verlängern. Ein Beispiel könnte sein, dass ein PodDisruptionBudget für Anwendungen mit Allowed Disruptions auf Null konfiguriert ist. Da unser System das PodDisruptionBudget respektiert, kann SKE nicht mit der Aktualisierung der Node fortfahren. Dies hat zur Folge, dass sich ein Node-Update so lange verzögert, bis das von der SKE definierte harte Limit (2 Stunden) erreicht wurde. Danach werden Pods gelöscht, die sich noch auf dieser Node befinden und der Update-Prozess wird für die nächste Node weitergeführt.

F: Was bestimmt die Anzahl der Nodes in meinem Cluster?

Die Anzahl der im Cluster bereitgestellten Nodes ergibt sich aus den konfigurierten Min- und Max-Werten in den Node Pools. Darüber hinaus verwenden SKE Cluster den Cluster Autoscaler, um die Größe des Clusters dynamisch zu ändern. Die Anzahl der Nodes im Cluster erhöht sich, wenn neue Pods nicht genügend Ressourcen zur Verfügung haben oder der Cluster Autoscaler erkennt, dass mehr Knoten benötigt werden. Der Cluster Autoscaler wird jedoch niemals weniger bzw. mehr Nodes erstellen als im Node Pool konfiguriert. 

Für mehr Informationen siehe: When does Cluster Autoscaler change the size of a cluster?

Node Konfiguration

F: Welche Betriebssysteme kann ich für meine Nodes verwenden?

Aktuell wird nur Flatcar/CoreOS als Betriebssystem unterstützt. Windows Nodes werden nicht unterstützt.

F: Kann ich verschiedene VM Flavors in einem Cluster nutzen?

Ja, indem Sie mehrere Node Pools mit unterschiedlichen VM Flavors verwenden. Diese können unabhängig voneinander skaliert werden.

F: Welche VM Flavors kann ich für meine Nodes auswählen?

Es werden alle vom STACKIT IaaS Service unterstützten Flavors mit mehr als einer vCPU und 2 GB RAM unterstützt. Weitere Informationen finden Sie in der IaaS Dokumentation.

F: Kann ich die STACKIT Availability Zones in SKE nutzen?

Ja, SKE unterstützt alle Availability Zones, die vom STACKIT IaaS Service unterstützt werden.

F: Wie kann ich Taints und Labels zu Nodes hinzufügen?

Labels und Taints können in der Node Pool Bearbeitungsmaske im STACKIT Cloud Portal bearbeitet werden. Diese werden dann für alle Knoten des bearbeiteten Node Pools gesetzt.

F: Wie kann ich die Container Runtime meines Node Pools von Docker auf containerd ändern?

Eine Container Runtime wird pro Node Pool festgelegt, daher wählen Sie bitte links in der Cluster-Ansicht "Node Pools" aus. Klicken Sie dann auf den gewünschten Node Pool und Sie sehen in der "Übersicht"-Registerkarte ein "Poolconfiguration"-Menü. Klicken Sie auf "Bearbeiten" und ändern Sie die Container Runtime von "docker" in "containerd". Speichern Sie die Änderung und unser managed Kubernetes wird ein rollendes Update für Sie starten. Nach einigen Minuten sind die neuen Nodes mit "containerd" als Runtime verfügbar.

Loadbalancer

F: Kann ich eine statische IP-Adresse für meinen Loadbalancer konfigurieren?

Unsere SKE Services/Loadbalancer können für eingehenden Traffic konfiguriert werden, z.B. die Verwendung bestehender Floating IPs (Nutzung bestehender öffentlicher IPs für LoadBalancing -SKE-). Diese Konfigurationen haben keine Auswirkungen auf den ausgehenden Datenverkehr über die OpenStack Router IP (weitere Informationen).

F: Kann ich eine statische IP-Adresse für meinen ausgehenden Cluster-Datenverkehr konfigurieren?

Nein, es ist nicht möglich Ihrem SKE-Cluster eine bestimmte IP-Adresse für den ausgehenden Datenverkehr zuzuweisen. Beim Aufbau des Clusters wird automatisch eine IPv4 Adresse aus dem bei STACKIT zur Verfügung stehenden IP-Pool ausgewählt. Diese Egress-IP-Adresse bleibt während des gesamten Lebenszyklus des Clusters festgelegt und kann nicht geändert werden.

Der gesamte ausgehende Traffic wird über den Router innerhalb Ihres Kubernetes-Clusters geroutet. Um die IP-Adresse des Routers zu ermitteln, können Sie eine der folgenden Methoden verwenden:

  • Portal: aktuell nicht möglich
  • IaaS API:
    1. Verwenden Sie den ListNetworks-Endpunkt, um die Netzwerk-ID abzurufen
    2. Verwenden Sie den GetNetwork-Endpunkt, um die publicIp des Netzwerks abzurufen.
  • Openstack:
    1. Auflisten der Openstack-Router: openstack router list (der Router heißt shoot--xyz-name, name ist der Clustername)
    2. Anzeigen der Routerdetails: openstack router show ID
    3. Die Egress-IP ist in external_fixed_ips.ip_address zu finden, das sich im Feld external_gateway_info befindet

Q: Wieso ist meine lokale Pod zu Service-Kommunikation seit Kubernetes 1.25.x eingeschränkt? 

Wenn im Service ein loadbalancerSourceRange eingestellt ist, dann wird dieser ab der Kubernetes Version 1.25.x auch auf die lokale Kommunikation angewendet.
Wenn ein Pod den Service erreichen möchte, muss auch die podCIDR zu den loadbalancerSourceRanges im Ser hinzugefügt werden. Die podCIDR befindet sich in der shoot-info ConfigMap im kube-system Namespace.

podCIDR

kubectl get configmap -n kube-system shoot-info -oyaml
BASH

Sonstiges

F: Haben Sie offene Fragen, die in keinem unserer Dokumente beantwortet werden?

Sie können gerne eine Serviceanfrage im STACKIT Help Center erstellen.

Bekannte Probleme

Node Pool Rollouts führen zu Downtime, wenn mehrere AZs pro Pool verwendet werden (hinzugefügt am 2024-09-02)

Dieses Problem tritt nur auf, wenn Ihr Cluster über Node Pools verfügt, die mehrere AZs konfiguriert haben und der maxSurge Wert kleiner als die Anzahl der konfigurierten AZs ist.

Der Grund für dieses Verhalten ist, dass jeder Node Pool intern in einen "Sub-Pool" pro AZ aufgeteilt ist. Die Werte für maxSurge und maxUnavailable werden auf diese Sub-Pools verteilt, was bei einem zu geringen Wert dazu führt, dass einige Sub-Pools unerwünschte Werte aufweisen.

Beispiel:
Ein Node Pool mit mehreren AZs (eu01-1, eu01-2 & eu01-3) und maxSurge=1 & maxUnavailable=0 wird in drei Sub-Pools aufgeteilt:

  • eu01-1: maxSurge=1 & maxUnavailable=0
  • eu01-2: maxSurge=0 & maxUnavailable=0
  • eu01-3: maxSurge=0 & maxUnavailable=0

Für Sub-Pools mit maxSurge=0 & maxUnavailable=0 wird der Rollout wie maxSurge=0 & maxUnavailable=1 durchgeführt, was zu Downtime für betroffene AZs führt.

Lösung:
Setzen Sie maxSurge mindestens auf die Anzahl der konfigurierten AZs. Wir werden zusätzlich auch eine weitere Validierung dafür einführen.

Beispiel:
Ein Node Pool mit mehreren AZs (eu01-1, eu01-2 & eu01-3) sollte maxSurge=3 haben.

Image Pull schlägt fehl mit folgender Meldung: "too manyrequests: You have reached your pull rate limit."

Dies ist kein SKE-spezifisches Problem, sondern betrifft alle Docker Hub-Nutzer.

Docker hat im November 2020 eine Begrenzung der Docker Hub Pull Requests für kostenlose Nutzer eingeführt. Seitdem wurde der kostenlose Plan auf 100 Pulls pro 6 Stunden für anonyme Benutzer und 200 Pulls für authentifizierte Benutzer reduziert.

Weitere Informationen finden Sie unter Umgehen der Docker Hub Pull Request Limitierungen

Cluster befindet sich in einem fehlerhaften Status

Manchmal bleibt Ihr Cluster im Zustand "Ungesund". Dies kann mehrere Gründe haben. Manchmal dauert die Erstellung einiger Ressourcen wie der VMs für die Node Pools länger als erwartet. In diesem Fall versucht der SKE Service, das Cluster regelmäßig zu reconcilen, um die Probleme zu beheben, und er wechselt bei Erfolg automatisch wieder in den Status 'fehlerfrei'.

Ein weiterer häufiger Grund für den fehlerhaften Status können Quota Probleme sein, die die Erstellung einiger Ressourcen verhindern. Dies können Sie überprüfen, indem Sie einen Blick auf Ihre Quotas im Portal werfen.

Wenn Sie ein Problem haben und Ihr Cluster sich über einen längeren Zeitraum hinweg im Status "Ungesund" befindet, können Sie eine Serviceanfrage im STACKIT Help Center erstellen.