Google verwendet KI-Technologie, um Inhalte in Ihre bevorzugte Sprache zu übersetzen. KI-Übersetzungen können Fehler enthalten.

.NET Core-Anwendung in Google Kubernetes Engine bereitstellen und aktualisieren

1. Übersicht

Microsoft .NET Core ist eine plattformübergreifende Open-Source-Version von .NET, die nativ in Containern ausgeführt werden kann. .NET Core ist auf GitHub verfügbar und wird von Microsoft und der .NET-Community verwaltet. In diesem Lab wird eine containerisierte .NET Core-Anwendung in der Google Kubernetes Engine (GKE) bereitgestellt.

In diesem Lab wird ein typisches Entwicklungsmuster verwendet, bei dem Anwendungen in der lokalen Umgebung eines Entwicklers entwickelt und dann in der Produktion bereitgestellt werden. Im ersten Teil des Labs wird eine .NET Core-Beispielanwendung mit einem Container validiert, der in Cloud Shell ausgeführt wird. Nach der Validierung wird die Anwendung mithilfe von GKE in Kubernetes bereitgestellt. Das Lab enthält die Schritte zum Erstellen eines GKE-Clusters.

Im zweiten Teil des Labs wird eine kleine Änderung an der Anwendung vorgenommen, die den Hostnamen des Containers anzeigt, in dem die Anwendungsinstanz ausgeführt wird. Die aktualisierte Anwendung wird dann in Cloud Shell validiert und das Deployment wird aktualisiert, um die neue Version zu verwenden. Die folgende Abbildung zeigt die Abfolge der Aktivitäten in diesem Lab:

Sequenzdiagramm für die Demo

Kosten

Wenn Sie dieses Lab genau wie beschrieben ausführen, fallen die normalen Kosten für die folgenden Dienste an:

2. Einrichtung und Anforderungen

Vorbereitung

Für dieses Lab sind ein Google Cloud-Konto und ein Google Cloud-Projekt erforderlich. Eine detaillierte Anleitung zum Erstellen eines neuen Projekts finden Sie in diesem Codelab.

In diesem Lab wird Docker in der Cloud Shell verwendet, die über die Google Cloud Console verfügbar ist und mit vielen nützlichen Tools wie gcloud und Docker vorkonfiguriert ist. Unten sehen Sie, wie Sie auf die Cloud Shell zugreifen können. Klicken Sie rechts oben auf das Cloud Shell-Symbol, um die Cloud Shell im unteren Bereich des Console-Fensters einzublenden.

Cloud Shell

Alternative Konfigurationsoptionen für GKE-Cluster (optional)

Für dieses Lab ist ein Kubernetes-Cluster erforderlich. Im nächsten Abschnitt wird ein GKE-Cluster mit einer einfachen Konfiguration erstellt. In diesem Abschnitt werden einige gcloud-Befehle gezeigt, die alternative Konfigurationsoptionen für das Erstellen eines Kubernetes-Clusters mit der GKE bieten. Mit den folgenden Befehlen können Sie beispielsweise verschiedene Maschinentypen, Zonen und sogar GPUs (Beschleuniger) identifizieren.

Listen Sie die Maschinentypen mit diesem Befehl auf: gcloud compute machine-types list
Listen Sie GPUs mit diesem Befehl auf: gcloud compute accelerator-types list
Listen Sie die Computing-Zonen mit diesem Befehl auf: gcloud compute zones list
Hilfe zu einem beliebigen gcloud-Befehl erhalten gcloud container clusters --help
- Hier finden Sie beispielsweise Details zum Erstellen eines Kubernetes-Clusters gcloud container clusters create --help.

Eine vollständige Liste der Konfigurationsoptionen für GKE finden Sie in diesem Dokument.

Erstellung des Kubernetes-Clusters vorbereiten

In Cloud Shell müssen Sie einige Umgebungsvariablen festlegen und den gcloud-Client konfigurieren. Dazu können Sie die folgenden Befehle verwenden.

export PROJECT_ID=YOUR_PROJECT_ID
export DEFAULT_ZONE=us-central1-c

gcloud config set project ${PROJECT_ID}
gcloud config set compute/zone ${DEFAULT_ZONE}

GKE-Cluster erstellen

Da die .NET Core-Anwendung in diesem Lab in Kubernetes bereitgestellt wird, müssen Sie einen Cluster erstellen. Verwenden Sie den folgenden Befehl, um einen neuen Kubernetes-Cluster in Google Cloud mit der GKE zu erstellen.

gcloud container clusters create dotnet-cluster \
  --zone ${DEFAULT_ZONE} \
  --num-nodes=1 \
  --node-locations=${DEFAULT_ZONE},us-central1-b \
  --enable-stackdriver-kubernetes \
  --machine-type=n1-standard-1 \
  --workload-pool=${PROJECT_ID}.svc.id.goog \
  --enable-ip-alias

--num-nodes ist die Anzahl der Knoten, die pro Zone hinzugefügt werden sollen. Sie kann später skaliert werden.
--node-locations ist eine durch Kommas getrennte Liste von Zonen. In diesem Fall werden die Zone, die Sie in der Umgebungsvariablen oben angeben, und us-central1-b verwendet.
- HINWEIS: Diese Liste darf keine Duplikate enthalten
--workload-pool richtet eine Workload Identity ein, damit GKE-Arbeitslasten auf Google Cloud-Dienste zugreifen können.

Während der Cluster erstellt wird, wird Folgendes angezeigt:

Creating cluster dotnet-cluster in us-central1-b... Cluster is being deployed...⠼

kubectl konfigurieren

Die kubectl-Befehlszeile ist die primäre Methode für die Interaktion mit einem Kubernetes-Cluster. Damit Sie es mit dem neu erstellten Cluster verwenden können, muss es für die Authentifizierung beim Cluster konfiguriert werden. Dazu verwenden Sie den folgenden Befehl.

$ gcloud container clusters get-credentials dotnet-cluster --zone ${DEFAULT_ZONE}
Fetching cluster endpoint and auth data.
kubeconfig entry generated for dotnet-cluster.

Es sollte jetzt möglich sein, kubectl für die Interaktion mit dem Cluster zu verwenden.

$ kubectl get nodes
NAME                                            STATUS   ROLES    AGE     VERSION
gke-dotnet-cluster-default-pool-02c9dcb9-fgxj   Ready    <none>   2m15s   v1.16.13-gke.401
gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   Ready    <none>   2m24s   v1.16.13-gke.401

3. Lokal testen und gewünschte Funktionalität bestätigen

In diesem Lab werden die folgenden Container-Images aus dem offiziellen .NET-Repository auf Docker Hub verwendet.

Container lokal ausführen, um die Funktionalität zu prüfen

Prüfen Sie in Cloud Shell, ob Docker ordnungsgemäß ausgeführt wird und der .NET-Container wie erwartet funktioniert. Führen Sie dazu den folgenden Docker-Befehl aus:

$ docker run --rm mcr.microsoft.com/dotnet/samples

      Hello from .NET!
      __________________
                        \
                        \
                            ....
                            ....'
                            ....
                          ..........
                      .............'..'..
                  ................'..'.....
                .......'..........'..'..'....
                ........'..........'..'..'.....
              .'....'..'..........'..'.......'.
              .'..................'...   ......
              .  ......'.........         .....
              .                           ......
              ..    .            ..        ......
            ....       .                 .......
            ......  .......          ............
              ................  ......................
              ........................'................
            ......................'..'......    .......
          .........................'..'.....       .......
      ........    ..'.............'..'....      ..........
    ..'..'...      ...............'.......      ..........
    ...'......     ...... ..........  ......         .......
  ...........   .......              ........        ......
  .......        '...'.'.              '.'.'.'         ....
  .......       .....'..               ..'.....
    ..       ..........               ..'........
            ............               ..............
          .............               '..............
          ...........'..              .'.'............
        ...............              .'.'.............
        .............'..               ..'..'...........
        ...............                 .'..............
        .........                        ..............
          .....
  
Environment:
.NET 5.0.1-servicing.20575.16
Linux 5.4.58-07649-ge120df5deade #1 SMP PREEMPT Wed Aug 26 04:56:33 PDT 2020

Funktion der Webanwendung bestätigen

Eine Beispiel-Webanwendung kann auch in Cloud Shell validiert werden. Mit dem folgenden Docker-Ausführungsbefehl wird ein neuer Container erstellt, der den Port 80 verfügbar macht und ihn dem Port 8080 von localhost zuordnet. Denken Sie daran, dass sich localhost in diesem Fall in der Cloud Shell befindet.

$ docker run -it --rm -p 8080:80 --name aspnetcore_sample mcr.microsoft.com/dotnet/samples:aspnetapp
warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {64a3ed06-35f7-4d95-9554-8efd38f8b5d3} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app

Da es sich um eine Webanwendung handelt, muss sie in einem Webbrowser angezeigt und validiert werden. Im nächsten Abschnitt wird gezeigt, wie Sie das in Cloud Shell mit der Webvorschau tun können.

4. Über die „Webvorschau“ in Cloud Shell auf Dienste zugreifen

Cloud Shell bietet die Webvorschau, eine Funktion, mit der Sie über einen Browser mit Prozessen interagieren können, die in der Cloud Shell-Instanz ausgeführt werden.

Mit „Webvorschau“ Anwendungen in Cloud Shell ansehen

Klicken Sie in Cloud Shell auf den Button „Webvorschau“ und wählen Sie Vorschau auf Port 8080 aus (oder den Port, der für die Webvorschau festgelegt ist).

Cloud Shell

Daraufhin wird ein Browserfenster mit einer Adresse wie der folgenden geöffnet:

https://8080-cs-754738286554-default.us-central1.cloudshell.dev/

.NET-Beispielanwendung mit der Webvorschau ansehen

Die Beispiel-App, die im letzten Schritt gestartet wurde, kann jetzt aufgerufen werden, indem Sie die Webvorschau starten und die angegebene URL laden. Die Ausgabe sollte ungefähr so aussehen:

Screenshot der .NET-Anwendung V1

5. In Kubernetes bereitstellen

YAML-Datei erstellen und anwenden

Für den nächsten Schritt ist eine YAML-Datei erforderlich, die zwei Kubernetes-Ressourcen beschreibt: ein Deployment und einen Service. Erstellen Sie in Cloud Shell eine Datei mit dem Namen dotnet-app.yaml und fügen Sie ihr den folgenden Inhalt hinzu.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: dotnet-deployment
  labels:
    app: dotnetapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: dotnetapp
  template:
    metadata:
      labels:
        app: dotnetapp
    spec:
      containers:
      - name: dotnet
        image: mcr.microsoft.com/dotnet/samples:aspnetapp
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: dotnet-service
spec:
    selector:
      app: dotnetapp
    ports:
      - protocol: TCP
        port: 8080
        targetPort: 80

Verwenden Sie jetzt kubectl, um diese Datei auf Kubernetes anzuwenden.

$ kubectl apply -f dotnet-app.yaml
deployment.apps/dotnet-deployment created
service/dotnet-service created

Beachten Sie die Meldungen, die darauf hinweisen, dass die gewünschten Ressourcen erstellt wurden.

Ressourcen ansehen

Mit der kubectl-Befehlszeile können wir die oben erstellten Ressourcen prüfen. Sehen wir uns zuerst die Bereitstellungsressourcen an und prüfen, ob die neue Bereitstellung vorhanden ist.

$ kubectl get deployment
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
dotnet-deployment   3/3     3            3           80s

Sehen Sie sich als Nächstes die ReplicaSets an. Durch das obige Deployment sollte ein ReplicaSet erstellt worden sein.

$ kubectl get replicaset
NAME                           DESIRED   CURRENT   READY   AGE
dotnet-deployment-5c9d4cc4b9   3         3         3       111s

Sehen Sie sich schließlich die Pods an. Im Deployment wurde angegeben, dass drei Instanzen vorhanden sein sollten. Der folgende Befehl sollte zeigen, dass drei Instanzen vorhanden sind. Die Option -o wide wird hinzugefügt, damit die Knoten angezeigt werden, auf denen diese Instanzen ausgeführt werden.

$ kubectl get pod -o wide
NAME                                 READY   STATUS    RESTARTS   AGE     IP          NODE                                            NOMINATED NODE   READINESS GATES
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Running   0          2m25s   10.16.0.8   gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   <none>           <none>
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Running   0          2m25s   10.16.1.7   gke-dotnet-cluster-default-pool-02c9dcb9-fgxj   <none>           <none>
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Running   0          2m25s   10.16.0.7   gke-dotnet-cluster-default-pool-ed09d7b7-xdx9   <none>           <none>

Serviceressource prüfen

Eine Dienstressource in Kubernetes ist ein Load Balancer. Die Endpunkte werden durch Labels auf Pods bestimmt. Sobald der Bereitstellung über den obigen kubectl scale deployment-Vorgang neue Pods hinzugefügt werden, sind die resultierenden Pods sofort für Anfragen verfügbar, die von diesem Dienst verarbeitet werden.

Der folgende Befehl sollte die Dienstressource anzeigen.

$ kubectl get svc
NAME             TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)    AGE
dotnet-service   ClusterIP   10.20.9.124   <none>        8080/TCP   2m50s
...

Mit dem folgenden Befehl können Sie weitere Details zum Dienst aufrufen.

$ kubectl describe svc dotnet-service
Name:              dotnet-service
Namespace:         default
Labels:            <none>
Annotations:       <none>
Selector:          app=dotnetapp
Type:              ClusterIP
IP:                10.20.9.124
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         10.16.0.7:80,10.16.0.8:80,10.16.1.7:80
Session Affinity:  None
Events:            <none>

Der Dienst ist vom Typ ClusterIP. Das bedeutet, dass jeder Pod im Cluster den Dienstnamen dotnet-service in seine IP-Adresse auflösen kann. An den Dienst gesendete Anfragen werden per Load-Balancing über alle Instanzen (Pods) verteilt. Der Wert Endpoints oben zeigt die IP-Adressen der Pods, die derzeit für diesen Dienst verfügbar sind. Vergleichen Sie diese mit den IP-Adressen der Pods, die oben ausgegeben wurden.

Ausgeführte Anwendung prüfen

Die Anwendung ist jetzt live und bereit für Nutzeranfragen. Verwenden Sie einen Proxy, um darauf zuzugreifen. Mit dem folgenden Befehl wird ein lokaler Proxy erstellt, der Anfragen an Port 8080 akzeptiert und an den Kubernetes-Cluster weiterleitet.

$ kubectl proxy --port 8080
Starting to serve on 127.0.0.1:8080

Verwenden Sie jetzt die Webvorschau in Cloud Shell, um auf die Webanwendung zuzugreifen.

Fügen Sie der von der Webvorschau generierten URL Folgendes hinzu: /api/v1/namespaces/default/services/dotnet-service:8080/proxy/. Das sieht dann ungefähr so aus:

https://8080-cs-473655782854-default.us-central1.cloudshell.dev/api/v1/namespaces/default/services/dotnet-service:8080/proxy/

Sie haben eine .NET Core-Anwendung in der Google Kubernetes Engine bereitgestellt. Als Nächstes nehmen wir eine Änderung an der Anwendung vor und stellen sie noch einmal bereit.

6. Anwendung anpassen

In diesem Abschnitt wird die Anwendung so geändert, dass der Host angezeigt wird, auf dem die Instanz ausgeführt wird. So können Sie prüfen, ob das Load Balancing funktioniert und die verfügbaren Pods wie erwartet reagieren.

Quellcode abrufen

git clone https://github.com/dotnet/dotnet-docker.git
cd dotnet-docker/samples/aspnetapp/

Anwendung aktualisieren, um den Hostnamen einzufügen

vi aspnetapp/Pages/Index.cshtml

    <tr>
        <td>Host</td>
        <td>@Environment.MachineName</td>
    </tr>

Neues Container-Image erstellen und lokal testen

Erstellen Sie das neue Container-Image mit dem aktualisierten Code.

docker build --pull -t aspnetapp:alpine -f Dockerfile.alpine-x64 .

Testen Sie die neue Anwendung wie zuvor lokal.

$ docker run --rm -it -p 8080:80 aspnetapp:alpine
warn: Microsoft.AspNetCore.DataProtection.Repositories.FileSystemXmlRepository[60]
      Storing keys in a directory '/root/.aspnet/DataProtection-Keys' that may not be persisted outside of the container. Protected data will be unavailable when container is destroyed.
warn: Microsoft.AspNetCore.DataProtection.KeyManagement.XmlKeyManager[35]
      No XML encryptor configured. Key {f71feb13-8eae-4552-b4f2-654435fff7f8} may be persisted to storage in unencrypted form.
info: Microsoft.Hosting.Lifetime[0]
      Now listening on: http://[::]:80
info: Microsoft.Hosting.Lifetime[0]
      Application started. Press Ctrl+C to shut down.
info: Microsoft.Hosting.Lifetime[0]
      Hosting environment: Production
info: Microsoft.Hosting.Lifetime[0]
      Content root path: /app

Wie zuvor kann die Anwendung über die Webvorschau aufgerufen werden. Dieses Mal sollte der Parameter „Host“ sichtbar sein, wie hier gezeigt:

Cloud Shell

Öffnen Sie einen neuen Tab in Cloud Shell und führen Sie docker ps aus, um zu prüfen, ob die Container-ID mit dem oben angezeigten Hostwert übereinstimmt.

$ docker ps
CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS                  NAMES
ab85ce11aecd        aspnetapp:alpine    "./aspnetapp"       2 minutes ago       Up 2 minutes        0.0.0.0:8080->80/tcp   relaxed_northcutt

Image taggen und per Push übertragen, damit es für Kubernetes verfügbar ist

Das Image muss getaggt und per Push übertragen werden, damit Kubernetes es abrufen kann. Listen Sie zuerst die Container-Images auf und identifizieren Sie das gewünschte Image.

$ docker image list
REPOSITORY                                         TAG                 IMAGE ID            CREATED             SIZE
aspnetapp                                          alpine              95b4267bb6d0        6 days ago          110MB

Als Nächstes taggen Sie das Image und übertragen es per Push in die Google Container Registry. Mit der IMAGE ID von oben sieht das so aus:

docker tag 95b4267bb6d0 gcr.io/${PROJECT_ID}/aspnetapp:alpine
docker push gcr.io/${PROJECT_ID}/aspnetapp:alpine

7. Aktualisierte Anwendung noch einmal bereitstellen

YAML-Datei bearbeiten

Wechseln Sie zurück in das Verzeichnis, in dem die Datei dotnet-app.yaml gespeichert ist. Suchen Sie in der YAML-Datei nach der folgenden Zeile:

        image: mcr.microsoft.com/dotnet/core/samples:aspnetapp

Dies muss geändert werden, um auf das Container-Image zu verweisen, das oben erstellt und per Push an gcr.io übertragen wurde.

        image: gcr.io/PROJECT_ID/aspnetapp:alpine

Vergessen Sie nicht, sie so zu ändern, dass Ihre PROJECT_ID verwendet wird. Wenn Sie fertig sind, sollte es ungefähr so aussehen:

        image: gcr.io/myproject/aspnetapp:alpine

Aktualisierte YAML-Datei anwenden

$ kubectl apply -f dotnet-app.yaml
deployment.apps/dotnet-deployment configured
service/dotnet-service unchanged

Die Deployment-Ressource wird als aktualisiert und die Service-Ressource als unverändert angezeigt. Die aktualisierten Pods können wie zuvor mit dem Befehl kubectl get pod angezeigt werden. Dieses Mal fügen wir jedoch -w hinzu, um alle Änderungen zu beobachten, während sie stattfinden.

$ kubectl get pod -w
NAME                                 READY   STATUS              RESTARTS   AGE
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Running             0          34m
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Running             0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Running             0          34m
dotnet-deployment-85f6446977-tmbdq   0/1     ContainerCreating   0          4s
dotnet-deployment-85f6446977-tmbdq   1/1     Running             0          5s
dotnet-deployment-5c9d4cc4b9-vvdln   1/1     Terminating         0          34m
dotnet-deployment-85f6446977-lcc58   0/1     Pending             0          0s
dotnet-deployment-85f6446977-lcc58   0/1     Pending             0          0s
dotnet-deployment-85f6446977-lcc58   0/1     ContainerCreating   0          0s
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-lcc58   1/1     Running             0          6s
dotnet-deployment-5c9d4cc4b9-cspqd   1/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          0s
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          0s
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-vvdln   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   0/1     Pending             0          2s
dotnet-deployment-85f6446977-hw24v   0/1     ContainerCreating   0          2s
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-cspqd   0/1     Terminating         0          34m
dotnet-deployment-85f6446977-hw24v   1/1     Running             0          3s
dotnet-deployment-5c9d4cc4b9-httw6   1/1     Terminating         0          34m
dotnet-deployment-5c9d4cc4b9-httw6   0/1     Terminating         0          34m

Die obige Ausgabe zeigt das Rolling Update, während es ausgeführt wird. Zuerst werden neue Container gestartet. Wenn sie ausgeführt werden, werden die alten Container beendet.

Ausgeführte Anwendung prüfen

Die Anwendung ist jetzt aktualisiert und bereit für Nutzeranfragen. Wie zuvor kann über einen Proxy darauf zugegriffen werden.

$ kubectl proxy --port 8080
Starting to serve on 127.0.0.1:8080

Verwenden Sie jetzt die Webvorschau in Cloud Shell, um auf die Webanwendung zuzugreifen.

Fügen Sie der von der Webvorschau generierten URL Folgendes hinzu: /api/v1/namespaces/default/services/dotnet-service:8080/proxy/. Das sieht dann ungefähr so aus:

https://8080-cs-473655782854-default.us-central1.cloudshell.dev/api/v1/namespaces/default/services/dotnet-service:8080/proxy/

Prüfen, ob der Kubernetes-Dienst die Last verteilt

Aktualisieren Sie diese URL mehrmals. Sie werden feststellen, dass sich der Host ändert, da die Anfragen vom Dienst über das Load Balancing auf verschiedene Pods verteilt werden. Vergleichen Sie die Hostwerte mit der Liste der Pods oben, um zu sehen, dass alle Pods Traffic empfangen.

Instanzen hochskalieren

Das Skalieren von Anwendungen in Kubernetes ist einfach. Mit dem folgenden Befehl wird das Deployment auf 6 Instanzen der Anwendung skaliert.

$ kubectl scale deployment dotnet-deployment --replicas 6
deployment.apps/dotnet-deployment scaled

Die neuen Pods und ihr aktueller Status können mit diesem Befehl angezeigt werden:

kubectl get pod -w

Wenn Sie das Browserfenster aktualisieren, sehen Sie, dass der Traffic jetzt auf alle neuen Pods verteilt wird.

8. Glückwunsch!

In diesem Lab wurde eine .NET Core-Beispiel-Webanwendung in einer Entwicklungsumgebung validiert und anschließend mit GKE in Kubernetes bereitgestellt. Die Anwendung wurde dann so geändert, dass der Hostname des Containers angezeigt wird, in dem sie ausgeführt wird. Anschließend wurde das Kubernetes-Deployment auf die neue Version aktualisiert und die Anwendung wurde hochskaliert, um zu zeigen, wie die Last auf zusätzliche Instanzen verteilt wird.

Weitere Informationen zu .NET und Kubernetes finden Sie in diesen Anleitungen. Diese bauen auf dem auf, was Sie in diesem Lab gelernt haben, und führen Istio Service Mesh für komplexere Routing- und Ausfallsicherheitsmuster ein.

9. Bereinigen

Verwenden Sie die folgenden Befehle, um den Cluster und das Container-Image zu löschen, die in diesem Lab erstellt wurden, und so unbeabsichtigte Kosten zu vermeiden.

gcloud container clusters delete dotnet-cluster --zone ${DEFAULT_ZONE}
gcloud container images delete gcr.io/${PROJECT_ID}/aspnetapp:alpine