Bereitstellen des Containerimages in Azure Kubernetes Service
In dieser Lektion stellen Sie ein Containerimage für Azure Kubernetes Service (AKS) bereit. Mit AKS konfigurieren Sie Ihren Kubernetes-Cluster so, dass er über eine Bereitstellung in einem gewünschten Zustand ausgeführt wird. Dabei handelt es sich um die Bereitstellung deklarativer Updates für Pods und ReplicaSets. Diese Deklaration des Zustands wird in der YAML-Manifestdatei verwaltet, und der Kubernetes-Controller ändert den aktuellen Zustand in den deklarierten Zustand, wenn er angewiesen wird. Sie erstellen diese deployment.yml Manifestdatei und weisen Ihre AKS-Instanz an, in einem gewünschten Zustand mit konfigurierten Pods zu laufen, die so eingerichtet sind, dass sie das flightbookingsystemsample Containerimage aus der Azure-Containerregistrierung abrufen und ausführen, das Sie in der vorherigen Einheit hochgeladen haben. Dieses Manifest definiert deklarativ ein Deployment und einen Service. Kubernetes verwendet den Deployment-Controller, um die Pods der Anwendung zu verwalten; Sie können auch ein Deployment imperativ mit kubectl create deployment erstellen.
Hinweis
Wenn Ihre Sitzung sich im Leerlauf befindet oder Sie diesen Schritt zu einem anderen Zeitpunkt oder von einer anderen CLI ausführen, müssen Sie ihre Umgebungsvariablen möglicherweise erneut initialisieren und erneut authentifizieren, indem Sie die folgenden Befehle verwenden:
Stellen Sie die im Setup verwendeten Ressourcenvariablenwerte wieder her. Ersetzen Sie <your-subscription-ID> unten durch die ID des Abonnements, das Sie für dieses Modul verwendet haben. Wenn die Anmeldung eine Abonnementauswahl anzeigt, wählen Sie dasselbe Abonnement aus. Führen Sie die Authentifizierungsbefehle einzeln aus. Vergewissern Sie sich danach az account show, dass das aktive Abonnement mit dem Setup übereinstimmt, bevor Sie fortfahren. Wenn ein Befehl fehlschlägt, halten Sie an und beheben Sie den Fehler.
export AZ_RESOURCE_GROUP=java-containerization-demo-rg
export AZ_CONTAINER_REGISTRY=<your-container-registry>
export AZ_KUBERNETES_CLUSTER=java-containerization-demo-aks
export AZ_LOCATION=<your-Azure-region>
export AZ_KUBERNETES_CLUSTER_DNS_PREFIX=<your-unique-DNS-prefix-to-access-your-AKS-cluster>
az login
az account set --subscription "<your-subscription-ID>"
az account show --output table
az acr login --name "$AZ_CONTAINER_REGISTRY"
Bereitstellen eines Containerimages
Nun stellen Sie das Containerimage flightbookingsystemsample in Ihrem AKS-Cluster bereit. Verwenden Sie in containerize-and-deploy-Java-app-to-Azure/Project/Airlines einen installierten Text-Editor, um eine Datei mit dem Namen deployment.yml zu erstellen. Dieser Pfad ist relativ zum übergeordneten Verzeichnis, in dem Sie das Repository geklont haben. Wenn Sie sich bereits in Project/Airlines befinden, bleiben Sie dort, anstatt wieder in den vollständigen relativen Pfad zu wechseln. Erstellen Sie die Datei, und führen Sie den nachfolgenden kubectl apply -f deployment.yml-Befehl aus diesem Verzeichnis aus.
Fügen Sie den folgenden Inhalt zu deployment.yml hinzu, und speichern Sie die Datei. Ersetzen Sie den <AZ_CONTAINER_REGISTRY>-Platzhalter durch den Wert der Umgebungsvariable AZ_CONTAINER_REGISTRY, die Sie zuvor festgelegt haben.
apiVersion: apps/v1
kind: Deployment
metadata:
name: flightbookingsystemsample
spec:
replicas: 1
selector:
matchLabels:
app: flightbookingsystemsample
template:
metadata:
labels:
app: flightbookingsystemsample
spec:
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
containers:
- name: flightbookingsystemsample
image: <AZ_CONTAINER_REGISTRY>.azurecr.io/flightbookingsystemsample:latest
resources:
requests:
cpu: "1"
memory: "1Gi"
limits:
cpu: "2"
memory: "2Gi"
ports:
- containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: flightbookingsystemsample
spec:
type: LoadBalancer
ports:
- port: 8080
targetPort: 8080
selector:
app: flightbookingsystemsample
Hinweis
Wenn Sie die Datei deployment_solution.yml im Stammordner Ihres Projekts als Ausgangspunkt verwenden, aktualisieren Sie ihr Image auf dasselbe Registry-Image sowie das hier gezeigte :latest-Tag. Fügen Sie auch die gleiche Linux AMD64 nodeSelector unter dem spec.template.spec der Bereitstellung, neben containers, hinzu. Verwenden Sie die Alternative nicht unverändert weiter: Das Image und die Knotenauswahl müssen mit der Build-Plattform dieses Moduls übereinstimmen.
Im vorherigen deployment.yml enthält die Datei eine Bereitstellung und einen Dienst. Die Bereitstellung wird verwendet, um eine Gruppe von Pods zu verwalten, und der Dienst wird verwendet, um den Netzwerkzugriff auf die Pods zu ermöglichen. Die Pods sind so konfiguriert, dass ein einzelnes Image, <AZ_CONTAINER_REGISTRY>.azurecr.io/flightbookingsystemsample:latest, aus der Azure-Containerregistrierung abgerufen wird. Der Dienst ist so konfiguriert, dass eingehender HTTP-Datenverkehr von Pods auf Port 8080 zugelassen wird, ähnlich wie Sie das Container-Image lokal mit dem -p-Portargument ausgeführt haben.
Der Knotenselektor schränkt die Pods auf Linux-AMD64-Knoten ein, passend zum zuvor erstellten linux/amd64 Image. Sie gehört zum Deployment, nicht zum Service. Ein Selektor schränkt die Planung ein; er führt nicht dazu, dass ein inkompatibles Image auf einer anderen Architektur ausgeführt wird.
Stellen Sie vor dem Konfigurieren des Clusterzugriffs sicher, dass die AKS-Clustererstellung in der Setupeinheit erfolgreich abgeschlossen wurde. Überprüfen Sie den Bereitstellungsstatus und die aktuelle Kubernetes-Version:
az aks show \
--resource-group "$AZ_RESOURCE_GROUP" \
--name "$AZ_KUBERNETES_CLUSTER" \
--query '{provisioningState:provisioningState,currentKubernetesVersion:currentKubernetesVersion}' \
--output table
Fahren Sie nicht fort, wenn der Befehl fehlschlägt, provisioningState nicht Succeeded ist oder currentKubernetesVersion keine nichtleere Version im major.minor.patch-Format ist.
Die folgenden Toolanweisungen gelten für die lokale Linux-, macOS- oder WSL-Bash-Sitzung, die im Setup eingerichtet wurde, nicht für die native PowerShell oder die Eingabeaufforderung. Wenn Sie in dieser Sitzung bereits funktionsfähige kubectl- und kubelogin-Installationen haben, behalten Sie sie bei, anstatt sie erneut zu installieren. Überprüfen Sie sie mit kubectl version --client und kubelogin --version, und stellen Sie sicher, dass kubectl die unterstützte Versions-Skew-Richtlinie für den Cluster erfüllt.
Ersetzen Sie <control-plane-version> andernfalls durch die zurückgegebene currentKubernetesVersion. Installieren Sie diese übereinstimmende kubectl Version und kubelogin an vom Benutzer beschreibbaren Speicherorten:
KUBECTL_VERSION="<control-plane-version>"
if [[ "$KUBECTL_VERSION" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
mkdir -p "$HOME/.local/bin" &&
az aks install-cli \
--client-version "$KUBECTL_VERSION" \
--install-location "$HOME/.local/bin/kubectl" \
--kubelogin-install-location "$HOME/.local/bin/kubelogin" &&
export PATH="$HOME/.local/bin:$PATH" &&
kubectl version --client &&
kubelogin --version
else
printf 'Stop: set KUBECTL_VERSION to the returned major.minor.patch version.\n' >&2
false
fi
Beide Installationspfade enthalten den Namen der ausführbaren Datei. Der PATH Export gilt nur für die aktuelle Shell. Wiederholen Sie ihn in einer neuen Sitzung, oder fügen Sie ihn der entsprechenden Bash-Startkonfiguration hinzu. Beheben Sie jeden Installations- oder Versionsprüfungsfehler, bevor Sie fortfahren.
Nachdem beide Tools verfügbar und überprüft wurden, konfigurieren Sie kubectl, um eine Verbindung mit Ihrem AKS-Cluster herzustellen:
az aks get-credentials \
--resource-group $AZ_RESOURCE_GROUP \
--name $AZ_KUBERNETES_CLUSTER
Das folgende Ergebnis ist typisch:
Merged AZ_KUBERNETES_CLUSTER as current context in ~/.kube/config
Überprüfen Sie die tatsächlichen Knotenbetriebssysteme und -architekturen, bevor Sie das Manifest anwenden:
kubectl get nodes \
-o custom-columns='NAME:.metadata.name,OS:.status.nodeInfo.operatingSystem,ARCH:.status.nodeInfo.architecture'
Der Buildpfad dieses Moduls linux/amd64 erfordert Linux AMD64-Knoten. Wenn keine übereinstimmenden Knoten vorhanden sind, halten Sie an und beheben Sie die Nichtübereinstimmung, bevor Sie fortfahren. Verwenden Sie einen unterstützten AMD64-Knotenpool, oder erstellen Sie das Image für eine andere unterstützte Linux-Knotenarchitektur neu, führen Sie es aus und laden Sie es hoch, und aktualisieren Sie die Architekturauswahl der Bereitstellung entsprechend. Die Docker-Option --platform erstellt oder ändert keinen AKS-Knotenpool.
Wenden containerize-and-deploy-Java-app-to-Azure/Project/AirlinesSie deployment.yml auf Ihren Cluster an:
kubectl apply -f deployment.yml
Das folgende Ergebnis ist typisch:
deployment.apps/flightbookingsystemsample created
service/flightbookingsystemsample created
Überwachen Sie den Status der Bereitstellung mithilfe des folgenden Befehls:
kubectl get all
Das folgende Ergebnis ist typisch:
kubectl get all
NAME READY STATUS RESTARTS AGE
pod/flightbookingsystemsample-b7fd6684f-4j8vf 1/1 Running 0 37s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/flightbookingsystemsample LoadBalancer 10.0.62.153 <external-IP> 8080:30534/TCP 37s
service/kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 11h
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/flightbookingsystemsample 1/1 1 1 37s
NAME DESIRED CURRENT READY AGE
replicaset.apps/flightbookingsystemsample-b7fd6684f 1 1 1 37s
Der Status eines Pods Running bestätigt nicht, dass Tomcat die Bereitstellung der Anwendung abgeschlossen hat oder dass HTTP-Anforderungen erfolgreich sind. Warten Sie auf das Rollout der Bereitstellung, und folgen Sie dann den Anwendungsstartprotokollen:
kubectl rollout status deployment/flightbookingsystemsample --timeout=300s &&
kubectl logs deployment/flightbookingsystemsample --tail=100 --follow
Ein erfolgreicher Rollout überprüft die Verfügbarkeit von Kubernetes. Da dieses Manifest keinen Bereitschaftstest enthält, handelt es sich bei der Bereitstellung nicht um einen HTTP-Funktionsfähigkeitstest. Verfolgen Sie die Protokolle, bis Tomcat den abgeschlossenen Serverstart meldet und die Bereitstellung von AirlinesReservationSample.war ohne Fehler abgeschlossen ist. Drücken Sie dann STRG+C, um die Protokolle nicht weiter zu verfolgen. Dadurch wird nur der Protokolldatenstrom und nicht der Container beendet. Wenn der Rollout oder der Anwendungsstart fehlschlägt oder nicht abgeschlossen ist, überprüfen Sie die Protokolle und Pod-Ereignisse, anstatt die Browserüberprüfung fortzusetzen.
Die folgende historische Ausgabe veranschaulicht Startmeldungen aus einem früheren Tomcat 10.1.33-Image. Es handelt sich hierbei nicht um die Ausgabe des aktualisierten Images in diesem Modul; überprüfen Sie den Startvorgang anhand Ihrer eigenen Protokolle, anstatt davon auszugehen, dass die Versionen, Zeitstempel oder Umgebungsdetails identisch sind:
kubectl logs pod/flightbookingsystemsample-b7fd6684f-4j8vf
15-Nov-2024 12:31:51.208 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version name: Apache Tomcat/10.1.33
15-Nov-2024 12:31:51.211 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server built: Nov 7 2024 22:28:55 UTC
15-Nov-2024 12:31:51.212 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Server version number: 10.1.33.0
15-Nov-2024 12:31:51.212 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Name: Linux
15-Nov-2024 12:31:51.212 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log OS Version: 5.15.0-1074-azure
15-Nov-2024 12:31:51.212 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Architecture: amd64
15-Nov-2024 12:31:51.216 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Java Home: /usr/lib/jvm/msopenjdk-17
15-Nov-2024 12:31:51.216 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Version: 17.0.13+11-LTS
15-Nov-2024 12:31:51.216 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log JVM Vendor: Microsoft
15-Nov-2024 12:31:51.216 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_BASE: /usr/local/tomcat
15-Nov-2024 12:31:51.216 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log CATALINA_HOME: /usr/local/tomcat
15-Nov-2024 12:31:51.226 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.config.file=/usr/local/tomcat/conf/logging.properties
15-Nov-2024 12:31:51.226 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
15-Nov-2024 12:31:51.227 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djdk.tls.ephemeralDHKeySize=2048
15-Nov-2024 12:31:51.227 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
15-Nov-2024 12:31:51.227 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
15-Nov-2024 12:31:51.227 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.lang=ALL-UNNAMED
15-Nov-2024 12:31:51.228 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.io=ALL-UNNAMED
15-Nov-2024 12:31:51.228 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util=ALL-UNNAMED
15-Nov-2024 12:31:51.228 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.base/java.util.concurrent=ALL-UNNAMED
15-Nov-2024 12:31:51.229 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
15-Nov-2024 12:31:51.229 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.base=/usr/local/tomcat
15-Nov-2024 12:31:51.229 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Dcatalina.home=/usr/local/tomcat
15-Nov-2024 12:31:51.229 INFO [main] org.apache.catalina.startup.VersionLoggerListener.log Command line argument: -Djava.io.tmpdir=/usr/local/tomcat/temp
15-Nov-2024 12:31:51.231 INFO [main] org.apache.catalina.core.AprLifecycleListener.lifecycleEvent The Apache Tomcat Native library which allows using OpenSSL was not found on the java.library.path: [/usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib]
15-Nov-2024 12:31:51.565 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
15-Nov-2024 12:31:51.602 INFO [main] org.apache.catalina.startup.Catalina.load Server initialization in [616] milliseconds
15-Nov-2024 12:31:51.658 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina]
15-Nov-2024 12:31:51.659 INFO [main] org.apache.catalina.core.StandardEngine.startInternal Starting Servlet engine: [Apache Tomcat/10.1.33]
15-Nov-2024 12:31:51.689 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/usr/local/tomcat/webapps/AirlinesReservationSample.war]
15-Nov-2024 12:31:53.264 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
15-Nov-2024 12:31:55.155 INFO [main] com.sun.xml.ws.server.MonitorBase.createRoot Metro monitoring rootname successfully set to: com.sun.metro:pp=/,type=WSEndpoint,name=/AirlinesReservationSample-PriceAndSeats-PriceAndSeatsPort
15-Nov-2024 12:31:55.347 INFO [main] com.sun.xml.ws.transport.http.servlet.WSServletDelegate.<init> WSSERVLET14: XML-WS servlet initializing
WARNING:Error in the metadata of the table SEATS: table's row count in the metadata is 5 but 6 records have been found and loaded by UCanAccess. All will work fine, but it's better to repair your database.
15-Nov-2024 12:31:56.248 INFO [main] com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized WSSERVLET12: XML-WS context listener initializing
15-Nov-2024 12:31:56.249 INFO [main] com.sun.xml.ws.transport.http.servlet.WSServletContextListener.contextInitialized WSSERVLET12: XML-WS context listener initializing
15-Nov-2024 12:31:56.284 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/usr/local/tomcat/webapps/AirlinesReservationSample.war] has finished in [4,595] ms
15-Nov-2024 12:31:56.285 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/docs]
15-Nov-2024 12:31:56.315 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/docs] has finished in [30] ms
15-Nov-2024 12:31:56.316 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/examples]
15-Nov-2024 12:31:56.439 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/examples] has finished in [123] ms
15-Nov-2024 12:31:56.440 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/manager]
15-Nov-2024 12:31:56.456 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/manager] has finished in [16] ms
15-Nov-2024 12:31:56.457 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/ROOT]
15-Nov-2024 12:31:56.468 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/ROOT] has finished in [11] ms
15-Nov-2024 12:31:56.468 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deploying web application directory [/usr/local/tomcat/webapps/host-manager]
15-Nov-2024 12:31:56.481 INFO [main] org.apache.catalina.startup.HostConfig.deployDirectory Deployment of web application directory [/usr/local/tomcat/webapps/host-manager] has finished in [13] ms
15-Nov-2024 12:31:56.484 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
15-Nov-2024 12:31:56.501 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [4897] milliseconds
Überwachen Sie den Dienst auf seine externe Adresse:
kubectl get service flightbookingsystemsample --watch
Der EXTERNAL-IP Wert kann anfangs <pending> sein, während Azure den Load Balancer bereitstellt. Dies kann mehrere Minuten dauern und ist für sich genommen kein Hinweis auf eine fehlgeschlagene Bereitstellung. Wenn eine Adresse angezeigt wird, drücken Sie STRG+C , um die Überwachung zu beenden. Wenn die Bereitstellung nicht abgeschlossen wird, halten Sie die Uhr an und überprüfen Sie die Serviceereignisse mitkubectl describe service flightbookingsystemsample.
Die folgende beispielhafte Ausgabe zeigt, wo die zugewiesene Adresse angezeigt wird:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
flightbookingsystemsample LoadBalancer 10.0.62.153 <external-IP> 8080:30534/TCP 3m28s
Hinweis
Ersetzen Sie die IP-Adresse <external-IP> in der folgenden URL durch Ihren EXTERNAL-IP Wert aus dem Befehl, den Sie zuvor ausgeführt haben:
Öffnen Sie einen Browser, und besuchen Sie die Startseite des Flight Booking System Sample unter http://<external-IP>:8080/AirlinesReservationSample/. Vergewissern Sie sich, dass die Anwendungsseite antwortet; ein Running Pod oder eine zugewiesene IP allein belegt nicht die Anwendungsbereitschaft. Ihr Browser sollte dem folgenden Screenshot ähneln:
Sie können sich optional mit einem beliebigen Benutzerkonto von tomcat-users.xml anmelden, z. B. someuser@azure.com: password.
Beheben von Problemen mit Nichtübereinstimmungen zwischen Image und Plattform
Bei Pod-Startfehlern prüfen kubectl describe pods -l app=flightbookingsystemsample, kubectl logs deployment/flightbookingsystemsample --tail=100 und kubectl get events --sort-by=.metadata.creationTimestamp. Ein CrashLoopBackOff Zustand kann mehrere Ursachen haben, einschließlich Anwendungsfehlern. Gehen Sie nicht davon aus, dass jeder Fehler eine Architekturinkompatibilität ist.
Wenn Sie feststellen, dass ein bereits bereitgestelltes Image die falsche Plattform aufweist, wiederholen Sie zunächst die Schritte „Build“, „Lokale Ausführung“, „Image-Prüfung“, „Registry-Tagging“ und „Push“ mit den entsprechenden Plattformeinstellungen. Nachdem das korrigierte Image erfolgreich neu erstellt, neu getaggt und unter demselben :latest Tag gepusht wurde, ersetzen Sie die laufenden Pods explizit:
kubectl rollout restart deployment/flightbookingsystemsample &&
kubectl rollout status deployment/flightbookingsystemsample --timeout=300s
Für dieses Manifest ist :latest standardmäßig auf imagePullPolicy: Always gesetzt, sodass Ersatz-Pods den aktuellen Registry-Tag auflösen. Das erneute Anwenden eines unveränderten Manifests allein löst kein Rollout aus. Wenn Sie die Pullrichtlinie angepasst haben, verwenden Sie stattdessen ein aktualisiertes Imagetag oder einen Digest, und aktualisieren Sie stattdessen die Bereitstellung. Wiederholen Sie die Überprüfungen des Startprotokolls und der Anwendungs-URL nach dem Rollout.
Bereinigen von Ressourcen
Die ressourcen, die Sie in diesem Modul erstellt haben, können laufende Kosten verursachen. Um die Ressourcen zu bereinigen, löschen Sie die Ressourcengruppe, die sie enthält, mithilfe des folgenden Befehls:
az group delete --name $AZ_RESOURCE_GROUP