Einführung
Juniper Café ist bereit für seine Herbstkarte. Die Website funktioniert, zeigt jedoch noch das reguläre Angebot. Du veröffentlichst die neue Karte über Kubernetes, hältst die alte Konfiguration verfügbar und lädst die tatsächliche Speisekarte für das Thekenteam herunter.
Du solltest Pods, Deployments, Services, Labels und einfaches YAML bereits kennen. Cluster, Anwendungsimage und Website sind vorbereitet; du brauchst weder Anwendungscode zu schreiben noch ein Cloud-Konto. Dieses Lab führt den kleinen Teil von Kustomize ein, mit dem jede Konfiguration einen eigenen, aus ihrem Inhalt abgeleiteten Namen erhält.
Verwende Workspace für Befehle, Café Menu für Juniper und Reference Menu für das separate Lesecafé. Alle Zugänge teilen sich eine Trainings-VM. Lasse das Referenzcafé, den Anwendungscode, den Service, die Anzahl der Replikate und den bereitgestellten Release-Verlauf unverändert. Die vom Autor geschätzten 40 Minuten berücksichtigen Lesen und gewöhnliche Fehler.
Ein separates Menü-Release vorbereiten
In diesem Schritt stellst du den Zusammenhang zwischen der aktuellen Website und ihrer Konfiguration her und bereitest ein Release-Verzeichnis vor, ohne die veröffentlichte Karte zu ändern.
Öffne Café Menu, wähle Explore the menu und suche Maple Latte. Er kostet derzeit $4.20 und trägt den Hinweis Not available today. Cold Brew ist verfügbar. Öffne About this drink für Oat Latte und kehre dann mit Back to the menu zurück. Dies sind echte Seiten, die von der vorbereiteten Anwendung ausgeliefert werden.
Wechsle zu Reference Menu und wähle Our menu. Das ist Willow Reading Room, ein separater Service, der weiter funktionieren muss. Wechsle zu Workspace. Das Startverzeichnis ist /home/labex/project/cafe-menu; bestätige es mit pwd, das das aktuelle Verzeichnis ausgibt:
pwd
Erwartete Ausgabe:
/home/labex/project/cafe-menu
Eine Kubernetes-ConfigMap speichert Konfiguration getrennt von einem Anwendungsimage. Ein Pod verweist über den Namen auf diese ConfigMap. Der Prozess dieses Cafés liest seine eingebundene Menüdatei einmal beim Start. Das Bearbeiten der Konfiguration führt nicht dazu, dass der bereits laufende Prozess seine Karte automatisch neu lädt.
Das vorbereitete Verzeichnis starter enthält drei kleine Dateien. ls listet sie auf:
ls starter
deployment.json kustomization.yaml menu.json
JSON ist auch eine gültige Eingabe für Kubernetes-Manifeste; deployment.json ist die vorbereitete Deployment-Definition. Du behältst deren Anwendungseinstellungen bei und änderst die separaten Menüdaten.
Erstelle mit cp -r dein eigenes Verzeichnis: cp kopiert, und -r schließt den Inhalt eines Verzeichnisses ein. Das Ziel release existiert noch nicht:
cp -r starter release
Wenn du diesen Befehl versehentlich zweimal ausführst, kann cp ein verschachteltes release/starter anlegen. Die drei erforderlichen Dateien gehören weiterhin direkt nach release; entferne nur diese versehentlich angelegte, verschachtelte Kopie mit rm -r release/starter. Entferne weder release noch versions oder approved.
Lies die Konfiguration mit cat, das eine Datei ausgibt:
cat release/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: cafe-menu
resources:
- deployment.json
configMapGenerator:
- name: cafe-menu
files:
- menu.json
resources bindet das Deployment ein. configMapGenerator wandelt menu.json in ConfigMap-Daten um. Kustomize fügt ein aus dem Inhalt abgeleitetes Suffix hinzu und aktualisiert den Verweis des Deployments auf diesen generierten Namen. Geänderte Daten können dadurch eine neue Pod-Vorlage und einen neuen Rollout auslösen, während die vorherige ConfigMap verfügbar bleibt. Das Suffix kennzeichnet den Inhalt; es sagt dir nicht, ob die Preise stimmen.
Die freigegebene Herbstkarte schreiben
In diesem Schritt bereitest du die vollständige Herbstkarte vor, bevor du Änderungen auf Kubernetes anwendest.
Bleibe in Workspace. Die Freigabe des Thekenteams ist als approved/menu.csv gespeichert. CSV bedeutet „comma-separated values“, also durch Kommas getrennte Werte: Die erste Zeile benennt die Spalten, und jede folgende Zeile beschreibt ein Getränk. price_cents ist eine ganzzahlige Cent-Angabe; 450 bedeutet also $4.50. true und false geben an, ob das Getränk verfügbar ist.
cat approved/menu.csv
id,name,price_cents,available
espresso,Espresso,250,true
oat-latte,Oat Latte,350,true
cold-brew,Cold Brew,390,false
maple-latte,Maple Latte,450,true
Lasse Espresso und Oat Latte unverändert. Cold Brew entfällt aus dem heutigen Angebot, und Maple Latte wird für $4.50 verfügbar. Die Saisonbezeichnung muss Autumn at Juniper lauten; Name, Standort und Öffnungszeiten des Cafés sowie Identitäten und Beschreibungen der Einträge bleiben unverändert.
Schreibe das vollständige JSON unten. JSON verwendet Eigenschaftsnamen in Anführungszeichen, Kommas zwischen den Einträgen und kleingeschriebene boolesche Werte ohne Anführungszeichen. Der Shell-Ausdruck cat > release/menu.json <<'EOF' schreibt den eingeschlossenen Text in diese Datei. > ersetzt ihren bisherigen Inhalt; das in Anführungszeichen gesetzte EOF sorgt dafür, dass der Text wörtlich übernommen wird. Füge den Text bis einschließlich der abschließenden Zeile EOF ein, die allein in ihrer Zeile stehen muss:
cat > release/menu.json <<'EOF'
{
"name": "Juniper Café",
"season": "Autumn at Juniper",
"hours": "Mon–Sat · 08:00–17:00",
"address": "14 Willow Lane",
"items": [
{"id": "espresso", "name": "Espresso", "price_cents": 250, "available": true, "description": "A small, rich cup with a golden crema."},
{"id": "oat-latte", "name": "Oat Latte", "price_cents": 350, "available": true, "description": "Our espresso with smooth oat milk."},
{"id": "cold-brew", "name": "Cold Brew", "price_cents": 390, "available": false, "description": "Slow-steeped coffee, served over ice."},
{"id": "maple-latte", "name": "Maple Latte", "price_cents": 450, "available": true, "description": "Espresso, oat milk, and a little maple sweetness."}
]
}
EOF
Prüfe das JSON, bevor du es verwendest. python3 -m json.tool liest JSON und gibt eine eingerückte Fassung aus; die Datei wird dabei nicht verändert:
python3 -m json.tool release/menu.json
Bei erfolgreicher Prüfung enthält die Ausgabe alle vier Getränke. Das Werkzeug zeigt möglicherweise \u00e9 anstelle von é an; das ist eine JSON-Escape-Sequenz und kein geänderter Caféname. Bei einem fehlenden Komma oder Anführungszeichen erscheint ein Parse-Fehler mit Zeilen- und Spaltenangabe. Schreibe zur Korrektur den vollständigen Block oben erneut und wiederhole dann die Prüfung. Ein falscher Pfad führt zu einem Fehler wegen einer nicht gefundenen Datei; führe pwd aus und kehre mit cd /home/labex/project/cafe-menu zurück, bevor du es erneut versuchst.
Die Website zeigt weiterhin die reguläre Karte, weil du nur deine Release-Quelldatei geändert hast. Das ist zu erwarten.
Eine neue Konfigurationsversion veröffentlichen
In diesem Schritt renderst du das Release, wendest es an und wartest, bis beide Café-Replikate die neue Konfiguration verwenden.
Bleibe in Workspace. kubectl kustomize rendert ein Verzeichnis, ohne es anzuwenden. Prüfe den generierten ConfigMap-Namen und den passenden Verweis im Deployment:
kubectl kustomize release
Die Ausgabe enthält einen Namen nach dem Muster cafe-menu-... und denselben Namen im Deployment unter dem volumes-Eintrag namens menu. Das genaue Suffix hängt von den Daten ab. Dies ist ein anderes Konfigurationsobjekt als das der regulären Karte.
Wende das Verzeichnis mit kubectl apply -k an. Die Option -k weist kubectl an, ein Kustomize-Verzeichnis zu rendern, anstatt mit -f ein einzelnes Manifest zu lesen:
kubectl apply -k release
Die erwartete Ausgabe enthält:
configmap/cafe-menu-... created
deployment.apps/cafe configured
Eine angelegte ConfigMap allein beweist nicht, dass sich die laufende Anwendung geändert hat. rollout status wartet darauf, dass der Deployment-Controller die Pods ersetzt. -n cafe-menu wählt den Namespace dieser Lektion aus; --timeout=120s begrenzt die Wartezeit:
kubectl rollout status deployment/cafe -n cafe-menu --timeout=120s
deployment "cafe" successfully rolled out
Wenn die Wartezeit überschritten wird, erhalte die bestehende Umgebung und untersuche sie mit den folgenden Befehlen. Ein Image- oder Containerfehler erscheint im Pod-Status und in den Events; führe das Setup nicht erneut aus und lösche den Namespace nicht:
kubectl get pods -n cafe-menu
kubectl describe deployment cafe -n cafe-menu
Untersuche nach einem normalen Rollout das aktuelle Deployment und seine ReplicaSets. Ein ReplicaSet hält eine bestimmte Pod-Vorlage aufrecht; das Deployment bewahrt ältere ReplicaSets als Rollout-Verlauf auf:
kubectl get replicasets -n cafe-menu -l app=cafe
Untersuche das Deployment selbst anhand seines Namens:
kubectl get deployment cafe -n cafe-menu
Es sollte 2/2 bereite Replikate anzeigen. Mehrere Konfigurationsobjekte bleiben bestehen; das Anwenden eines neuen Releases hat die alte Karte nicht überschrieben. Liste sie auf:
kubectl get configmaps -n cafe-menu
Lösche diese älteren Konfigurationen nicht. Ein älteres ReplicaSet benötigt genau den Konfigurationsnamen, auf den es verweist, wenn diese Version später wiederhergestellt wird.
Die Website prüfen und ihre Speisekarte übergeben
In diesem Schritt prüfst du die tatsächliche Kundenerfahrung und speicherst die Speisekarte, die das Thekenteam verwenden wird.
Wechsle zu Café Menu, wähle Our menu und aktualisiere die Seite, falls sie bereits geöffnet ist. Maple Latte muss für $4.50 als Available today erscheinen. Cold Brew muss als Not available today erscheinen. Öffne die Detailseite von Maple Latte, kehre mit Back to the menu zurück und prüfe anschließend über Visit us, ob Standort und Öffnungszeiten weiterhin funktionieren.
Achte auf die Verfügbarkeitsanzeigen und Preise: Cold Brew ist nicht verfügbar, und Maple Latte ist für $4.50 verfügbar.
Lade mit Download menu die tatsächliche vollständige CSV-Datei herunter. Öffne sie und vergleiche alle vier Getränke mit der freigegebenen Tabelle aus Schritt 2. Der Download enthält auch nicht verfügbare Getränke mit false, damit das Team diese von versehentlich fehlenden Einträgen unterscheiden kann.
Wechsle zu Reference Menu und bestätige, dass die reguläre Karte von Willow Reading Room weiterhin funktioniert. Kehre dann zu Workspace zurück.
Du kannst den echten Juniper-Download auch in deinem Arbeitsbereich speichern. curl ruft den lokalen Browserzugang auf, der an den tatsächlichen Kubernetes-Service weiterleitet. --fail meldet HTTP-Fehler; --silent blendet die Fortschrittsanzeige aus; --show-error hält Fehlermeldungen sichtbar; -o wählt den Namen der Ausgabedatei:
curl --fail --silent --show-error http://127.0.0.1:8081/menu.csv -o menu-handover.csv
Vergleiche die empfangene Datei mit der Freigabe mithilfe von diff -u. Die Option -u zeigt bei Unterschieden auch die umliegenden Zeilen an:
diff -u approved/menu.csv menu-handover.csv
Keine Ausgabe bedeutet, dass die Dateien übereinstimmen. Ein Unterschied ist ein hilfreicher Hinweis: Kehre zur Menüquelle und zum laufenden Rollout zurück, behebe die Ursache, wiederhole den Download und vergleiche erneut. Bearbeite die empfangene CSV-Datei nicht, um eine fehlerhafte Website zu verbergen.
Du hast jetzt eine nutzbare Speisekarte, ihren tatsächlichen Download für das Team und ein Release-Verzeichnis, das die laufende Konfiguration reproduziert. Lasse versions und die alten ConfigMaps in dieser Umgebung als Wiederherstellungsmaterial intakt. Die nächste Lektion bereitet ihre eigene, unabhängige Umgebung vor.
Zusammenfassung
Du hast ein vollständiges Menü-Release vorbereitet, eine nach ihrem Inhalt benannte ConfigMap generiert und den Rollout des Deployments bis zu beiden Anwendungsreplikaten verfolgt. Du hast echte Seiten und Downloads geprüft, das Referenzcafé und frühere Konfigurationen erhalten und die tatsächliche CSV-Datei für das Team übergeben.
Das nächste Lab beginnt in einer separaten Umgebung. Es verwendet diese Konzepte erneut, um eine Speisekarte wiederherzustellen, deren Anwendung fehlerfrei läuft, deren Preise jedoch falsch sind.
