Einen NGINX-Microservice bereitstellen und aktualisieren

Einführung

Sie sind bei der letzten Herausforderung dieses Einsteigerkurses angekommen. In den bisherigen Labs haben Sie Pods, Deployments, Services, Skalierung, Fehlerbehebung und Rollbacks kennengelernt. Nun verbinden Sie diese Konzepte in einer kleinen Veröffentlichungsaufgabe – ohne eine schrittweise Befehlsanleitung.

Die Umgebung enthält eine funktionierende Ausgangsversion mit dem Namen web-app. Ihre Aufgabe besteht darin, das nächste festgelegte NGINX-Image bereitzustellen und dabei drei verfügbare Replikate sowie den stabilen Service beizubehalten. Der endgültige Clusterzustand und das gespeicherte Manifest müssen übereinstimmen, damit die Veröffentlichung auch nach der Challenge reproduzierbar bleibt.

Die nächste NGINX-Version veröffentlichen

Start der Umgebung: Dieses Lab startet einen vollständigen Kubernetes-Cluster für Sie. Die Konfiguration der Steuerungsebene, des Knotens und der Netzwerkkomponenten dauert normalerweise 2–3 Minuten. Bitte warten Sie geduldig, bis die Umgebung vollständig geladen ist, bevor Sie beginnen.

Aktuelle Situation

Das Plattformteam hat eine Ausgangsversion unter /home/labex/project/final-release/web-app.yaml vorbereitet. Sie führt derzeit nginx:1.26-alpine mit drei Replikaten hinter dem Service web-app aus.

Umfang

• Arbeiten Sie mit dem vorhandenen Deployment web-app, dem Service, dem Manifest und dem Client release-check.
• Benennen Sie keine Ressourcen um, ändern Sie keine Selektoren und ersetzen Sie nicht das genehmigte Budget für Rolling Updates.
• Verwenden Sie das festgelegte Ziel-Image; veränderliche Tags wie latest sind für diese Veröffentlichung nicht zulässig.

Ihr Ziel

Veröffentlichen Sie nginx:1.27-alpine über das vorhandene Deployment und hinterlassen Sie den laufenden Cluster, den Service-Zugriffspfad und das gespeicherte Manifest in einem konsistenten, gesunden und reproduzierbaren Zustand.

Abnahmekriterien

• Das Deployment web-app verwendet genau drei gewünschte Replikate.
• Der Container nginx verwendet das festgelegte Image nginx:1.27-alpine.
• Das Budget für das Rolling Update bleibt auf maxUnavailable: 0 und maxSurge: 1 gesetzt.
• Die Annotation zum Änderungsgrund beschreibt die Veröffentlichung von NGINX 1.27.
• Der Service web-app wählt weiterhin die Pods des Deployments aus und verfügt über drei bereite Backends.
• Alle drei aktualisierten Replikate sind bereit und verfügbar, und eine HTTP-Anfrage innerhalb des Clusters an http://web-app ist erfolgreich.
• /home/labex/project/final-release/web-app.yaml enthält das endgültige Image und die Rollout-Einstellungen, sodass eine erneute Anwendung den akzeptierten Zustand beibehalten würde.

Verwenden Sie Kubernetes-Inspektions- und Rollout-Befehle, um zu entscheiden, wann die Veröffentlichung abgeschlossen ist. Wenn ein Update noch läuft, warten Sie darauf, anstatt sich nur auf die erste Ausgabe von kubectl get zu verlassen.

Hinweise

Nützliche Informationen liefern die Spalten READY, UP-TO-DATE und AVAILABLE des Deployments, die Pod-Images, die Rollout-Historie sowie die Adressen der EndpointSlices des Services.

Zusammenfassung

Sie haben den Kurs abgeschlossen, indem Sie ein festgelegtes NGINX-Image eigenständig über ein Kubernetes-Deployment veröffentlicht haben. Sie haben ein explizites Verfügbarkeitsbudget eingehalten, auf alle aktualisierten Replikate gewartet, den Service mit drei bereiten Backends verbunden gehalten, eine Anfrage innerhalb des Clusters überprüft und den akzeptierten Zustand in YAML gespeichert.

Diese Prüfungen bilden einen wiederverwendbaren Einsteiger-Workflow: den gewünschten Zustand deklarieren, ihn anwenden, den Fortschritt des Controllers beobachten, die Arbeitslast und ihren Zugriffspfad überprüfen und das Manifest mit dem Cluster synchron halten.