Die Aktualisierung an das Budget anpassen

Einführung

Aster Supply liefert seinen normalen Katalog aus, während eine Winteraktualisierung blockiert ist. Der Namespace hat genügend angeforderte CPU-Ressourcen für den normalen Betrieb, aber nicht für den zusätzlichen Pod, der während einer rollierenden Aktualisierung angefordert wird. Du wählst ein Rollout-Budget, das in die feste Zuteilung passt, hältst den Referenzshop am Laufen und lieferst den aktualisierten Katalog.

Du solltest grundlegende Terminalpfade, einfaches YAML, Pods, Deployments, Services und Labels bereits kennen. Dieses Lab erklärt die Einheiten von CPU-Anforderungen, ResourceQuota und die Berechnung des Aktualisierungsbudgets. Der echte Einzelknoten-Cluster, die Anwendung, Zustandsprüfungen und Katalogdaten sind vorbereitet; weder Clusterinstallation noch Imagebau oder Anwendungsprogrammierung sind erforderlich. Die geschätzte Dauer berücksichtigt Lesen und gewöhnliche Fehler; sie ist eine Schätzung des Autors.

Die Aktualisierung an das feste Budget anpassen

In diesem Schritt schließt du die Aktualisierung des Winterkatalogs von Aster Supply ab, ohne seine CPU-Zuteilung zu erhöhen oder den Referenzshop anzuhalten.

Der Tab Shop zeigt einen funktionierenden Katalog. Öffne Stoneware tray, merke dir den Preis und kehre mit Back to collection zurück. Die aktuelle Kollektion Everyday essentials enthält drei Produkte; die angeforderte Kollektion The winter edit ergänzt Amber cup und ändert Preise. Öffne den Tab Reference: Fern Stationery ist ein separater, geschützter Service, der seinen bestehenden Katalog behalten muss. Lasse dessen Deployment, Service und ursprünglichen Pod unverändert. Wechsle dann zum Tab Workspace.

Der vorbereitete Cluster ist echtes Kubernetes mit einem einzelnen Knoten. Ein Namespace fasst die Ressourcen dieses Kurses zusammen. Eine ResourceQuota begrenzt die gesamten Ressourcen, die in diesem Namespace zugelassen werden. Hier erfasst sie ausschließlich CPU requests (CPU-Anforderungen): für die Einplanung reservierte CPU-Ressourcen, kein Ausgabenbudget und keine Obergrenze für die gemessene CPU-Nutzung. 1000m bedeutet einen CPU-Kern; 40m bedeutet 0,04 eines Kerns. Der Arbeitsspeicher ist vorbereitet und bildet in dieser Aufgabe nicht den Quotenengpass.

Lies zuerst die Quote. --context=labex-v135 wählt den vorbereiteten Cluster aus, -n shop-quota den Namespace dieses Kurses, und describe zeigt die Details eines Objekts an:

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Erwarte requests.cpu mit Used 140m und Hard 140m. Dies ist reservierte CPU und keine aktuelle Auslastung. Der ursprüngliche Shop ist weiterhin verfügbar, doch sein Aktualisierungsversuch benötigt einen weiteren Pod. Ein verfügbares Replikat hat seine Readiness-Prüfung bestanden und die vorbereitete Mindestbereitschaftszeit von drei Sekunden erfüllt; das bloße Erstellen eines Pods macht ihn noch nicht verfügbar. Lies das Deployment und seine ReplicaSets. Ein ReplicaSet hält Pods für eine Deployment-Vorlage aufrecht; rs ist sein kurzer Ressourcenname:

kubectl --context=labex-v135 -n shop-quota get deployments,rs,pods

Es gibt drei verfügbare Shop-Replikate und ein Referenzreplikat. Das neue Shop-ReplicaSet kann seinen Pod nicht erstellen. Beschreibe beide Shop-ReplicaSets; -l app=shop wählt deren Label aus:

kubectl --context=labex-v135 -n shop-quota describe rs -l app=shop

Suche FailedCreate oder ReplicaFailure mit exceeded quota: shop-budget, requested: requests.cpu=40m, used: requests.cpu=140m und limited: requests.cpu=140m. Dies ist eine Ablehnung bei der Zulassung: Dieser neue Pod wurde nicht erstellt. Das unterscheidet sich von einem bereits bestehenden Pending-Pod, den ein Scheduler nicht platzieren kann. Ändere weder die Quote noch entferne die Referenz-Workload.

Der freigegebene neue Katalog und das Kandidatenmanifest sind bereits bereitgestellt. Wechsle ausdrücklich in den Arbeitsbereich. pwd gibt dein aktuelles Verzeichnis aus; ls listet seine Einträge auf:

cd /home/labex/project/shop-update

pwd

ls

Du solltest approved, starter und tools sehen. cat gibt den freigegebenen Katalog aus:

cat approved/catalogue.json

Lies den gesamten Kandidaten mit sed -n '1,180p': -n unterdrückt die normale Ausgabe und p gibt die Zeilen 1 bis 180 aus. Der Bereich in Anführungszeichen ist ein einzelnes Argument:

sed -n '1,180p' starter/shop.yaml

Der Shop benötigt drei Replikate, die jeweils 40m anfordern. Die geschützte Referenz fordert 20m an. Nur spec.strategy.rollingUpdate darf sich ändern; die bereitgestellte neue Anwendungsvorlage, Replikate, Ressourcen, Selektoren und Zustandsprüfungen müssen intakt bleiben.

Eine rollierende Aktualisierung balanciert zwei Werte aus. maxSurge erlaubt zusätzliche Pods oberhalb der gewünschten Replikatanzahl. maxUnavailable erlaubt, dass einige gewünschte Replikate nicht verfügbar sind. Die Anforderung hier lautet mindestens zwei verfügbare Shop-Replikate während der beobachteten Aktualisierung. Bei drei gewünschten Replikaten darf eines vorübergehend nicht verfügbar sein, doch kein zusätzlicher Pod passt in das Budget. Wähle maxSurge: 0 und maxUnavailable: 1. Die beiden Werte dürfen nicht gleichzeitig null sein. Recreate, das Löschen des Deployments, das Reduzieren von Anforderungen, das Herunterskalieren der gewünschten Anzahl oder das Erhöhen der Quote liegen außerhalb dieser Aufgabe.

Erstelle ein bearbeitbares Release-Verzeichnis und kopiere den bereitgestellten Kandidaten. mkdir erstellt ein Verzeichnis; cp kopiert die Datei. Die bereitgestellten Originale sind schreibgeschützt. chmod u+w ergänzt auf der Kopie die Schreibberechtigung für deinen Benutzer:

mkdir release

cp starter/shop.yaml release/shop.yaml

chmod u+w release/shop.yaml

Falls release bereits von einem früheren Versuch existiert, behalte es und fahre mit der Kopie fort, die du bearbeitest. Verwende bei einem Tippfehler im Pfad die obigen Befehle pwd, ls und das absolute cd, bevor du den fehlgeschlagenen Befehl wiederholst; ein fehlender Pfad erfordert kein Zurücksetzen der VM.

sed -i bearbeitet eine Datei direkt. Jeder Ausdruck s/old/new/ ersetzt den gezeigten Text. Die einfachen Anführungszeichen halten Leerzeichen und Satzzeichen zusammen. Ändere nur die beiden Rollout-Werte in deiner Kopie:

sed -i 's/maxSurge: 1/maxSurge: 0/' release/shop.yaml

sed -i 's/maxUnavailable: 0/maxUnavailable: 1/' release/shop.yaml

Lies vor dem Anwenden den Anfang des gespeicherten Manifests:

sed -n '1,35p' release/shop.yaml

Erwarte replicas: 3, type: "RollingUpdate", maxSurge: 0 und maxUnavailable: 1. apply -f gleicht diese Datei mit dem bestehenden Deployment ab; die Identität des Deployments bleibt erhalten. rollout status wartet mit einem endlichen --timeout auf die neuen Replikate:

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Erwarte deployment "shop" successfully rolled out. Der Controller kann ein altes Replikat entfernen, ein neues zulassen, auf dessen Verfügbarkeit warten und fortfahren. Pods, die gerade beendet werden, können kurzzeitig weiter in die Quotenabrechnung eingehen; deshalb kann sich ein vorübergehendes zusätzliches FailedCreate-Event von selbst erledigen und ist kein Grund, die Quote zu ändern. Das Rollout-Budget ist weder eine absolute Grenze für alle sich beendenden Prozesse noch eine Verfügbarkeitsgarantie.

Falls eine falsche Änderung den Abschluss verhindert, untersuche die gespeicherte Datei und korrigiere die beiden Strategiewerte. Wende zur Wiederherstellung nach einem erfolglosen Versuch oder einem fehlerhaften Beobachtungsfenster die ursprüngliche freigegebene Ausgangskonfiguration erneut an und warte, bevor du dein korrigiertes Release erneut versuchst:

kubectl --context=labex-v135 apply -f approved/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Die Option --wait-baseline des bereitgestellten Statuswerkzeugs wartet vor einem neuen Versuch auf eine aktuelle Beobachtung des fehlerfrei laufenden alten Katalogs. Sie liest ausschließlich aufgezeichnete Fakten:

./tools/update-status --wait-baseline

kubectl --context=labex-v135 apply -f release/shop.yaml

kubectl --context=labex-v135 -n shop-quota rollout status deployment/shop --timeout=180s

Diese Wiederherstellungsbefehle werden nur nach einem erfolglosen Versuch benötigt. Lasse die bereitgestellte Ausgangskonfiguration unverändert. Der nur lesende Beobachter bewahrt Versuche auf und erkennt einen neuen vollständigen Versuch von der Ausgangskonfiguration zur Aktualisierung; die Wiederherstellung löscht keine früheren Belege.

Lies abschließend die tatsächliche Workload und Quote erneut:

kubectl --context=labex-v135 -n shop-quota get deployments

kubectl --context=labex-v135 -n shop-quota describe resourcequota shop-budget

Beide Deployments sollten verfügbar sein: Shop 3/3 und Referenz 1/1. Sobald alte Pods beendet sind, kehrt die Quotennutzung bei demselben festen Höchstwert auf 140m zurück. Der nächste Schritt prüft den Katalog, den die Menschen tatsächlich erhalten.

Den aktualisierten Katalog übergeben

In diesem Schritt prüfst du das neue Kundenerlebnis und bewahrst einen echten Katalogdownload neben dem gespeicherten Release-Manifest auf.

Beginne in Workspace unter /home/labex/project/shop-update. Der bereitgestellte Befehl tools/update-status fasst tatsächliche API- und HTTP-Stichproben zusammen, die ein nur lesender Beobachter aufgezeichnet hat. Das vorangestellte ./ führt ein Programm relativ zum aktuellen Verzeichnis aus:

./tools/update-status

Er meldet die geforderte Untergrenze, die Stichprobenanzahl, die kleinste beobachtete Anzahl verfügbarer Replikate und den neuesten Aktualisierungszustand. Erwarte ein Minimum von mindestens zwei und beim Abschluss drei aktualisierte/verfügbare Replikate. Der Beobachter erfasst Stichproben ungefähr alle halbe Sekunde zuzüglich API-Zeit, prüft die ursprüngliche Quote und Referenz und zeichnet Fehler auf. Lasse diesen bereitgestellten Beobachter weiterlaufen. Er beweist nicht, was zwischen den Stichproben geschehen ist, garantiert keine Produktionsverfügbarkeit und repariert den Cluster nicht. Eine Prüfung unmittelbar nach dem Rollout-Abschluss kann eine kurze Wartezeit auf zwei abgeschlossene Stichproben benötigen. Falls ein Versuch die erforderliche Untergrenze unterschritten hat oder eine lange Beobachtungslücke aufwies, nutze vor einem korrigierten Versuch die im vorherigen Schritt erklärte Wiederherstellung der Ausgangskonfiguration.

Wechsle zu Shop und lade die Seite neu. Erwarte The winter edit, vier Produkte, Stoneware tray $20.00, Linen cloth $14.00, Bud vase $24.00 und Amber cup $16.00. Öffne Amber cup, bestätige seinen Preis und den Status Available in store und kehre dann mit Back to collection zurück. Dies ist ein Katalog ohne Online-Kaufabschluss.

Die fertige Kollektion enthält vier echte Produktkarten. Vergleiche die Kollektionsüberschrift und Preise mit diesem laufenden Beispiel:

Verwende Download catalogue. Öffne die vom Browser heruntergeladene catalogue.csv; ihre vier Datenzeilen sollten mit der Kollektion, den Namen, Preisen in Cent und der auf der Website gezeigten Verfügbarkeit übereinstimmen. Browserdownload und Terminalarbeitsbereich sind unterschiedliche Speicherorte. Speichere als Nächstes denselben echten Service-Download im Arbeitsbereich für die Übergabe.

Wechsle zurück zu Workspace. curl ruft eine URL ab. --fail meldet HTTP-Fehler, --silent --show-error blendet die Fortschrittsanzeige aus und behält Fehlermeldungen bei, und --output schreibt die Antwortbytes in die benannte Datei. 127.0.0.1:8081 ist der vorbereitete lokale Zugang, der zum ursprünglichen Shop-Service weiterleitet:

curl --fail --silent --show-error http://127.0.0.1:8081/catalogue.csv --output catalogue.csv

cat catalogue.csv

Erwartete Ausgabe:

id,name,price_cents,available,collection
stone-tray,Stoneware tray,2000,true,The winter edit
linen-cloth,Linen cloth,1400,true,The winter edit
bud-vase,Bud vase,2400,true,The winter edit
amber-cup,Amber cup,1600,true,The winter edit

Ein Verbindungsfehler bedeutet, dass der lokale Zugang nicht erreicht werden konnte; ein HTTP-Fehler ist eine Antwort von einem Server. Kehre zu den erklärten Workload- und Rollout-Befehlen zurück, um den aktuellen Zustand zu untersuchen; ersetze das Ergebnis nicht durch eine statische Datei und ändere den vorbereiteten Weiterleitungsservice nicht. Falls ein Download unvollständig ist oder versehentlich überschrieben wurde, wiederhole denselben curl-Befehl, sobald der korrekte Katalog verfügbar ist.

Öffne Reference erneut und lade die Seite neu. Fern Stationery muss weiterhin Desk essentials, Field notebook $9.00 und Clay pencil cup $14.00 zeigen. Öffne ein Produkt und kehre zurück, um zu bestätigen, dass seine echten Links weiterhin funktionieren.

Deine Übergabe besteht aus release/shop.yaml und der tatsächlichen catalogue.csv, gestützt durch das vollständige neue Release, die unveränderte Quote, den ursprünglichen Referenzservice und einen gültigen beobachteten Aktualisierungsversuch. Erhalte die bereitgestellten Originale, die Anwendung, Services und den nur lesenden Beobachter.

Zusammenfassung

Du hast eine echte Quotenablehnung eines ReplicaSets mit dem vorübergehenden Ressourcenbedarf einer rollierenden Aktualisierung verknüpft, ein passendes Budget für zusätzliche und nicht verfügbare Replikate berechnet und den neuen Katalog fertiggestellt, ohne die Zuteilung zu erweitern. Außerdem hast du den geschützten Referenzservice erhalten und eine tatsächliche CSV-Datei zusammen mit einem wiederverwendbaren Release-Manifest geliefert.

CPU-Anforderungen beschreiben die Ressourcenabrechnung, keine gemessene Auslastung und kein Leistungsversprechen. Native, zeitlich begrenzte Beobachtungen stützen die Verfügbarkeitsprüfung dieses Kurses; sie belegen keine unterbrechungsfreie Produktionsverfügbarkeit. Berechne in einem anderen Namespace sowohl die freie Zuteilung als auch die Mindestanzahl verfügbarer Replikate neu, bevor du die Strategie auswählst.