FAQ

Kubernetes-Versionen und Upgrades

Welche Kubernetes-Versionen werden aktuell unterstützt?

Die PSKE unterstützt stets die drei aktuellsten, von Gardener freigegebenen Kubernetes-Versionen. Eine aktuelle Übersicht der unterstützten Versionen sowie bevorstehende EOL-Termine findet sich unter Kubernetes Versionen EOL.

Was passiert, wenn eine Kubernetes-Version das End-of-Life-Datum erreicht?

Wird ein Cluster bis zum EOL-Datum nicht manuell aktualisiert, führt die PSKE das Upgrade automatisch auf die nächste unterstützte Minor-Version durch. Eine vorherige Benachrichtigung erfolgt über die Plusserver-Statusseite.

Wie führt man ein Cluster-Upgrade auf eine neue Kubernetes-Version durch?

Upgrades werden über das PSKE-Dashboard oder das Shoot-Manifest ausgelöst. Dabei gilt:

• Upgrades sind nur auf die nächste Minor-Version möglich (z.B. 1.30 → 1.31), kein Überspringen von Versionen.
• Der Upgrade-Prozess ist Rolling: Control Plane wird zuerst aktualisiert, danach die Worker Nodes.
• Während des Upgrades bleibt der Cluster verfügbar, einzelne Nodes sind kurzzeitig nicht erreichbar.

Vor dem Upgrade empfiehlt es sich, die Release Notes sowie die offiziellen Kubernetes-Changelog-Informationen auf Breaking Changes zu prüfen.

Werden Worker Nodes automatisch aktualisiert?

Ja, sofern unter “Maintenance” im Cluster die Option Auto Update für Machine Image und Kubernetes Version aktiviert ist. Updates werden dann im konfigurierten Wartungsfenster eingespielt. Details unter Auto-Updates.

LoadBalancer

Der LoadBalancer bekommt keine externe IP — was tun?

Mögliche Ursachen:

• Quota erschöpft: OpenStack-Floating-IP-Quota geprüft? Eine Übersicht der Limits findet sich unter Limits und Quotas.
• Falsche Annotation: Bei internem LoadBalancer (openstack-internal-load-balancer: "true") wird keine Floating IP vergeben — das ist korrekt.
• Netzwerkkonflikte: Das Service-CIDR oder Node-CIDR überlappt mit dem Floating-IP-Netzwerk.
• Provisioning läuft noch: Der CCM benötigt nach dem Anlegen des Services bis zu 1–2 Minuten.

Der Status lässt sich mit kubectl describe service <name> prüfen — Events enthalten in der Regel eine aussagekräftige Fehlermeldung.

Wie wird eine Floating IP dauerhaft reserviert, sodass sie beim Löschen des Services erhalten bleibt?

Über die Annotation loadbalancer.openstack.org/keep-floatingip: "true". Details und Beispiele unter LoadBalancer Services.

Pods und Scheduling

Pods bleiben im Status Pending — was sind typische Ursachen?

• Nicht genug Ressourcen: Die angefragten CPU/RAM-Ressourcen überschreiten das verfügbare Kapazität der Nodes. Lösung: Worker Pool skalieren oder Node-Autoscaler aktivieren.
• Taints ohne passende Tolerations: Node hat einen Taint, der Pod hat keine passende Toleration.
• Quota erschöpft: Die maximale Anzahl Pods pro Node oder Namespace ist erreicht (siehe Limits und Quotas).
• Kein passender Node für NodeSelector/Affinity: Die konfigurierten Node-Selektoren oder Affinity-Regeln passen auf keinen verfügbaren Node.

kubectl describe pod <name> zeigt im Abschnitt Events, warum der Scheduler den Pod nicht platzieren kann.

Wie viele Pods laufen maximal auf einer Node?

Standardmäßig sind 110 Pods pro Node möglich. Dieser Wert ist durch das Kubernetes-Standardlimit gesetzt und lässt sich nicht per Self-Service erhöhen.

Netzwerk und DNS

DNS-Auflösung innerhalb des Clusters schlägt fehl — was prüfen?

1. CoreDNS-Pods laufen? kubectl get pods -n kube-system -l k8s-app=kube-dns
2. Service-Name korrekt? Format: <service>.<namespace>.svc.cluster.local
3. NetworkPolicy blockiert DNS-Traffic (Port 53 UDP/TCP zu CoreDNS)?
4. NodeLocalDNS aktiv? Kann Probleme verursachen, wenn Pods direkt auf CoreDNS-IPs zugreifen statt auf die lokale DNSCache-IP.

Weitere Informationen zur DNS-Konfiguration unter Cluster DNS.

Warum sehe ich im Backend nicht die echte Client-IP, sondern die IP des LoadBalancers?

Das Proxy Protocol muss am LoadBalancer Service und am Ingress Controller aktiviert werden. Anleitung unter LoadBalancer Services — Proxy Protocol.

Zugriff und Authentifizierung

Die Kubeconfig funktioniert nicht mehr — Token abgelaufen?

Kubeconfigs aus dem Gardener Dashboard haben eine begrenzte Gültigkeitsdauer. Eine neue Kubeconfig kann jederzeit über das PSKE-Dashboard heruntergeladen werden. Für einen dauerhaften Zugriff empfiehlt sich die Verwendung eines Service Accounts — Details unter Permanente Kubeconfig.

Hibernation

Was passiert beim Hibernieren eines Clusters?

Während der Hibernation werden alle Worker Nodes gestoppt und die Ressourcen freigegeben. Die Control Plane wird ebenfalls heruntergefahren. Persistent Volumes bleiben erhalten. Laufende Workloads werden unterbrochen und nach dem Aufwecken neu gestartet.

Während der Hibernation fallen weiterhin Kosten für die Cluster-Fee, Storage und reservierte Floating IPs an. Details unter Cluster Hibernation.

Kann Hibernation automatisch nach einem Zeitplan aktiviert werden?

Ja, über das Shoot-Manifest oder das PSKE-Dashboard lassen sich Hibernation-Zeitpläne konfigurieren (Cron-Syntax). Details unter Cluster Hibernation.

Löschen und Ressourcenbereinigung

Werden beim Löschen eines Clusters alle OpenStack-Ressourcen entfernt?

Kubernetes-managed Ressourcen wie LoadBalancer und Cinder Volumes werden beim Cluster-Löschen automatisch bereinigt — sofern die entsprechenden Services und PVCs vor dem Löschen des Clusters noch existieren. Ressourcen, die manuell in OpenStack angelegt wurden, oder Floating IPs mit keep-floatingip: "true" bleiben erhalten und müssen manuell freigegeben werden.

Quotas und Limits

Wie kann eine Quota-Erhöhung beantragt werden?

Quota-Erhöhungen werden über ein Support-Ticket im Kundenportal beantragt. Eine Übersicht der Standard-Quotas findet sich unter Limits und Quotas.