Die meisten Kubernetes-Inhalte richten sich an diejenigen, die Cluster betreiben. Doch weit mehr Entwickler deployen einfach auf einen Cluster, den jemand anderes verwaltet: und für sie sind neunzig Prozent von Kubernetes nur Rauschen. Sie müssen nicht die Interna von etcd verstehen, um einen zuverlässigen Dienst auszuliefern. Sie müssen eine Handvoll Dinge richtig machen: Ressourcenanforderungen, Health-Probes, Konfiguration und wie Traffic Ihre Anwendung erreicht. Dieser Leitfaden konzentriert sich genau auf diesen Ausschnitt für das moderne Kubernetes der Ära 1.36: was ein Anwendungsentwickler tatsächlich wissen muss, und die beständigen Konzepte hinter den Versionsnummern.
Die entwicklerrelevanten Grundlagen
- Ressourcenanforderungen und -limits: die Einstellung, die die meisten Apps falsch machen
- Liveness-, Readiness- und Startup-Probes richtig eingesetzt
- Konfiguration und Secrets, ohne sie in Images einzubacken
- Die Gateway API als moderner Weg, wie Traffic Ihren Dienst erreicht
- Warum „Was hat sich in 1.36 geändert?“ weniger zählt, als die Grundlagen richtig zu machen
Info
Sie müssen kein Operator sein
Wenn ein Plattform-Team Ihren Cluster betreibt, ist es Ihre Aufgabe, Ihre App als guten Kubernetes-Bürger zu verpacken: Deklarieren Sie, was sie benötigt, teilen Sie dem Cluster mit, wann sie gesund ist, externalisieren Sie ihre Konfiguration und definieren Sie, wie sie Traffic empfängt. Beherrschen Sie diese Dinge, und Sie werden zuverlässig deployen, ohne jemals die Control Plane anzufassen.
Warnung
Behandeln Sie versionsspezifische Details nach dem Motto „Prüfen, dann verwenden“
Kubernetes entwickelt sich schnell, und Features reifen über Releases hinweg. Dieser Leitfaden betont die beständigen Konzepte, die jeder Anwendungsentwickler braucht; für den genauen Status eines Features in 1.36 konsultieren Sie die offiziellen Kubernetes-Release-Notes und die Version Ihres Clusters, da die Verfügbarkeit von beidem abhängt.
1. Ressourcenanforderungen und -limits
Dies ist die wirkungsvollste einzelne Sache, die Anwendungsentwickler steuern, und die am häufigsten vermasselte. Eine Anforderung ist das, was Ihrem Container garantiert wird (der Scheduler nutzt sie, um Ihren Pod zu platzieren); ein Limit ist die Obergrenze, die er nicht überschreiten darf. Setzen Sie Anforderungen zu niedrig an, wird Ihre App unter Druck ausgehungert und verdrängt; zu hoch, und Sie verschwenden Cluster-Kapazität und Geld. Ermitteln Sie CPU- und Speicheranforderungen basierend auf realer Nutzung ungefähr richtig und seien Sie besonders vorsichtig mit Speicherlimits.
resources:
requests: # guaranteed; drives scheduling
cpu: "250m"
memory: "256Mi"
limits: # ceiling; exceeding memory = OOMKilled
cpu: "1000m"
memory: "512Mi"Gefahr
Speicherlimits sind eine harte Wand
Überschreiten Sie Ihr CPU-Limit, werden Sie nur gedrosselt: ärgerlich, aber überlebbar. Überschreiten Sie Ihr Speicherlimit, tötet der Kernel Ihren Container (OOMKilled), und zwar sofort. Basieren Sie Speicherlimits auf beobachteter realer Nutzung mit Puffer und behandeln Sie plötzliche OOMKills als Zeichen, dass Ihr Limit zu niedrig ist oder Ihre App ein Leck hat.
2. Health-Probes
Kubernetes hält Ihre App nur dann verfügbar, wenn Sie ihm mitteilen, was „gesund“ bedeutet. Drei Probes erledigen unterschiedliche Aufgaben, und sie zu verwechseln verursacht Ausfälle.
Readiness-Probe
Beantwortet die Frage: „Kann dieser Pod gerade Traffic empfangen?“ Schlägt sie fehl, stoppt Kubernetes das Routing von Anfragen an den Pod, lässt ihn aber laufen. Unerlässlich, um keinen Traffic an einen Pod zu senden, der noch hochfährt oder kurzzeitig überlastet ist.
Liveness-Probe
Beantwortet die Frage: „Ist dieser Pod defekt und muss neu gestartet werden?“ Schlägt sie fehl, tötet Kubernetes den Container und startet ihn neu. Verwenden Sie sie, um sich von Deadlocks zu erholen, aber seien Sie konservativ, denn eine aggressive Liveness-Probe verursacht Neustartschleifen.
Startup-Probe
Beantwortet die Frage: „Hat diese langsam startende App das Booten abgeschlossen?“ Sie hält die anderen Probes zurück, bis der Start abgeschlossen ist, sodass Apps mit langer Initialisierung nicht getötet werden, bevor sie bereit sind.
readinessProbe:
httpGet: { path: /healthz/ready, port: 8080 }
periodSeconds: 5
livenessProbe:
httpGet: { path: /healthz/live, port: 8080 }
periodSeconds: 10
failureThreshold: 3 # be tolerant — avoid restart stormsProfi-Tipp
Gestalten Sie Ihre Readiness-Probe aussagekräftig: Sie sollte prüfen, dass Abhängigkeiten, die Ihre App wirklich braucht (wie die Datenbank), erreichbar sind, damit ein Pod, der keine echten Anfragen bedienen kann, aus der Rotation genommen wird. Halten Sie Ihre Liveness-Probe aber dumm und billig: wenn sie auch die Datenbank prüft, wird eine kurze DB-Störung jeden Pod auf einmal neu starten und ein kleines Problem in einen Ausfall verwandeln.
3. Konfiguration und Secrets
Backen Sie niemals Konfiguration oder Zugangsdaten in Ihr Container-Image ein. Dasselbe Image sollte in jeder Umgebung laufen, wobei sein Verhalten von außen gesteuert wird. Kubernetes bietet ConfigMaps für nicht sensible Konfiguration und Secrets für sensible Werte, die beide als Umgebungsvariablen oder eingehängte Dateien in Ihren Pod injiziert werden. Das hält Images portabel und Zugangsdaten aus Ihrer Registry fern.
envFrom:
- configMapRef: { name: app-config } # non-sensitive settings
- secretRef: { name: app-secrets } # credentials, tokens, keysWarnung
Kubernetes-Secrets brauchen echten Schutz
Standardmäßig sind Secrets nur base64-kodiert, nicht so verschlüsselt, dass sie vor jedem mit Cluster-Zugriff geschützt sind. Stellen Sie sicher, dass Ihre Plattform Secrets im Ruhezustand verschlüsselt und den Zugriff streng kontrolliert, und ziehen Sie für sensible Systeme einen externen Secrets-Manager in Betracht. „Es ist ein Secret-Objekt“ ist nicht dasselbe wie „Es ist sicher.“
4. Wie Traffic Ihre App erreicht: die Gateway API
Jahrelang war Ingress der Weg, wie externer Traffic zu Diensten geleitet wurde, aber es war begrenzt und drängte Anbieter in inkompatible Annotationen. Die Gateway API ist der moderne, ausdrucksstärkere Nachfolger: eine standardisierte, rollenbewusste Methode, um Routing zu definieren (Host- und Pfadregeln, Traffic-Splitting und mehr), die sich zum empfohlenen Ansatz für neue Setups entwickelt. Als Anwendungsentwickler definieren Sie typischerweise Routen, die an ein Gateway andocken, das das Plattform-Team bereitstellt.
✓ Vorteile
- Ausdrucksstärkeres Routing als klassisches Ingress (Splitting, Header-basiert usw.)
- Ein Standardmodell statt anbieterspezifischer Ingress-Annotationen
- Klare Trennung zwischen plattformverwalteten Gateways und app-eigenen Routen
- Die empfohlene Richtung für modernes Kubernetes-Networking
✕ Nachteile
- Neuer, daher setzen manche Cluster und Tools noch auf Ingress
- Mehr Konzepte zu lernen als bei einfachem Ingress
- Ihr Cluster benötigt eine installierte Gateway-API-Implementierung
- Migration von Ingress erfordert Planung in bestehenden Setups
Was hat sich in 1.36 tatsächlich geändert?
Ehrlich gesagt: für die meisten App-Entwickler weit weniger, als die Länge der Release Notes vermuten lässt. Kubernetes-Releases werden dominiert von Arbeiten an Control Plane, Sicherheit und Operator-seitigen Themen: Features werden als stabil markiert, alte APIs veraltet, der Scheduler verfeinert. Die entwicklerseitige Oberfläche (wie Sie Ressourcen anfordern, Probes definieren, Konfiguration einspielen und Traffic routen) ist von Release zu Release bemerkenswert stabil. Der richtige Schritt bei jedem Upgrade: die Notes nach veralteten APIs durchsuchen, die Ihre Manifeste verwenden, sicherstellen, dass nichts, wovon Sie abhängen, den Status geändert hat, und ansonsten die Grundlagen weiterhin gut umsetzen.
Ressourcen, Probes, Konfiguration und Routing: wer diese beherrscht, deployed zuverlässig
Die Checkliste für App-Entwickler
✓ Vorteile
- Realistische CPU- und Speicheranforderungen basierend auf beobachteter Nutzung
- Speicherlimits mit Puffer; bei zu knapper Bemessung drohen OOMKills
- Getrennte Readiness-, Liveness- und (falls nötig) Startup-Probes
- Konfiguration und Secrets werden von außerhalb des Images eingespielt
- Routen über die Gateway-API auf ein Plattform-Gateway definiert
✕ Nachteile
- Keine Konfiguration oder Zugangsdaten in Images backen
- Keine Liveness-Probe, die externe Abhängigkeiten prüft
- Keine fehlenden Ressourcenanforderungen (sonst rät der Scheduler)
- Base64-kodierte Secrets nicht als tatsächlich sicher behandeln
! Häufige Fehler, die es zu vermeiden gilt
-
✕Ressourcenanforderungen weglassen, sodass der Scheduler rät.
✓Setzen Sie realistische CPU- und Speicheranforderungen basierend auf beobachteter Nutzung; legen Sie Speicherlimits mit Puffer fest.
-
✕Eine Liveness-Probe, die externe Abhängigkeiten prüft.
✓Halten Sie Liveness-Probes günstig und in sich abgeschlossen; ein DB-Aussetzer darf nicht jeden Pod auf einmal neu starten.
-
✕Konfiguration oder Zugangsdaten ins Image backen.
✓Spielen Sie Konfiguration über ConfigMaps und Secrets über Secrets von außerhalb des Images ein.
-
✕Base64-kodierte Kubernetes-Secrets als sicher behandeln.
✓Stellen Sie sicher, dass Secrets im Ruhezustand verschlüsselt sind, mit strenger Zugriffskontrolle, oder nutzen Sie einen externen Secrets-Manager.
? Häufig gestellte Fragen
Muss ich ein Kubernetes-Experte sein, um darauf zu deployen? +
Nein. Wenn ein Plattform-Team den Cluster betreibt, müssen Sie hauptsächlich vier Dinge richtig machen: Ressourcenanforderungen/-limits, Health Probes, externalisierte Konfiguration/Secrets und Routing.
Was ist der Unterschied zwischen Liveness-, Readiness- und Startup-Probes? +
Readiness steuert, ob ein Pod Traffic erhält; Liveness entscheidet, ob ein kaputter Pod neu gestartet wird; Startup hält die anderen zurück, bis eine langsam startende App die Initialisierung abgeschlossen hat.
Warum wird mein Container ständig OOMKilled? +
Er hat sein Speicherlimit überschritten: der Kernel beendet ihn sofort (anders als bei CPU-Limits, die nur drosseln). Basieren Sie Speicherlimits auf realer beobachteter Nutzung mit Puffer und prüfen Sie auf Speicherlecks.
Was ist die Gateway-API und sollte ich sie nutzen? +
Sie ist der moderne, ausdrucksstärkere Nachfolger von Ingress und der empfohlene Ansatz für neues Routing. Als App-Entwickler definieren Sie in der Regel Routen, die an ein vom Plattform-Team bereitgestelltes Gateway angebunden werden.
Was hat sich für Entwickler in 1.36 tatsächlich geändert? +
Weniger, als die Release Notes vermuten lassen: die meiste Arbeit betrifft Control Plane und Operator-seitige Themen. Durchsuchen Sie die Notes nach veralteten APIs, die Ihre Manifeste verwenden, stellen Sie sicher, dass nichts, wovon Sie abhängen, den Status geändert hat, und setzen Sie die Grundlagen weiterhin gut um.
Erfolg
Seien Sie ein guter Cluster-Bürger
Sie müssen Kubernetes nicht meistern, um gut darauf zu deployen. Deklarieren Sie, was Ihre App benötigt, teilen Sie dem Cluster ehrlich mit, wann sie gesund ist, halten Sie Konfiguration und Secrets außerhalb Ihres Images und definieren Sie sauberes Routing. Wenn Sie diese vier Dinge konsequent umsetzen, laufen Ihre Services zuverlässig auf 1.36 und auf jeder künftigen Version, denn die Grundlagen ändern sich kaum.
Kommentare
0Noch keine Kommentare. Teile als Erste oder Erster deine Gedanken.