Diese Seite wurde von der Cloud Translation API übersetzt.

.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 .NET Core-Containeranwendung in Google Kubernetes Engine (GKE) bereitgestellt.

In diesem Lab werden Anwendungen nach einem typischen Entwicklungsmuster in einer lokalen Entwicklerumgebung entwickelt und dann in der Produktion bereitgestellt. 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 mit GKE auf 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 die Bereitstellung wird aktualisiert, damit die neue Version verwendet wird. Die folgende Abbildung zeigt den Ablauf der Aktivitäten in diesem Lab:

Demo-Sequenzdiagramm

Kosten

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

2. Einrichtung und Anforderungen

Vorbereitung

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

In diesem Lab wird Docker in Cloud Shell ausgeführt. Das Tool ist über die Google Cloud Console verfügbar und mit vielen nützlichen Tools wie gcloud und Docker ausgestattet. Unten sehen Sie, wie Sie auf Cloud Shell zugreifen. Klicken Sie rechts oben auf das Cloud Shell-Symbol, um es im unteren Bereich des Konsolenfensters anzuzeigen.

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 beschrieben, die alternative Konfigurationsoptionen beim Erstellen eines Kubernetes-Clusters mit GKE bereitstellen. Mit den folgenden Befehlen können beispielsweise verschiedene Maschinentypen, Zonen und sogar GPUs (Beschleuniger) identifiziert werden.

Maschinentypen mit dem Befehl gcloud compute machine-types list auflisten
GPUs mit dem Befehl gcloud compute accelerator-types list auflisten
Compute-Zonen mit dem Befehl gcloud compute zones list auflisten
Hilfe zu allen gcloud-Befehlen gcloud container clusters --help
- Dadurch erhalten Sie beispielsweise Informationen zum Erstellen eines Kubernetes-Clusters gcloud container clusters create --help.

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

Erstellen des Kubernetes-Clusters vorbereiten

In Cloud Shell müssen Sie einige Umgebungsvariablen festlegen und den gcloud-Client konfigurieren. Dies wird mit den folgenden Befehlen erreicht.

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 in diesem Lab die .NET Core-Anwendung auf Kubernetes bereitgestellt wird, müssen Sie einen Cluster erstellen. Verwenden Sie den folgenden Befehl, um mit GKE einen neuen Kubernetes-Cluster in Google Cloud 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, und 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 oben angegebenen Umgebungsvariable angegeben haben, und us-central1-b verwendet.
- HINWEIS: Diese Liste darf keine doppelten Einträge enthalten.
--workload-pool richtet Workload Identity ein, damit GKE-Arbeitslasten auf Google Cloud-Dienste zugreifen können

Während der Cluster-Erstellung wird Folgendes angezeigt:

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

kubectl konfigurieren

Die kubectl-Befehlszeile ist die primäre Art der Interaktion mit einem Kubernetes-Cluster. Damit er mit dem neu erstellten Cluster verwendet werden kann, muss er für die Authentifizierung beim Cluster konfiguriert werden. Dies geschieht mit dem 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, über kubectl mit dem Cluster zu interagieren.

$ 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 mit dem folgenden Docker-Befehl, ob Docker ordnungsgemäß ausgeführt wird und der .NET-Container wie erwartet funktioniert:

$ 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

Funktionalität der Web-App prüfen

Eine Beispiel-Webanwendung kann auch in Cloud Shell validiert werden. Mit dem folgenden Docker-Befehl zum Ausführen wird ein neuer Container erstellt, der Port 80 verfügbar macht und den Port 8080 localhost zuordnet. Denken Sie daran, dass sich localhost in diesem Fall in 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 aufgerufen und validiert werden. Im nächsten Abschnitt erfahren Sie, wie Sie dies in Cloud Shell mit der Webvorschau tun können.

4. Über Cloud Shell auf Dienste mit "Webvorschau" zugreifen

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

Option „Webvorschau“ um Anwendungen in Cloud Shell anzusehen

Klicken Sie in Cloud Shell auf die Schaltfläche „Webvorschau“ und wählen Sie Vorschau auf Port 8080 aus. bzw. der Port, für den die Webvorschau eingestellt ist.

Cloud Shell

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

https://8080-cs-754738286554-default.us-central1.cloudshell.dev/?authuser=0

.NET-Beispielanwendung mit der Webvorschau ansehen

Sie können die Beispiel-App, die im letzten Schritt gestartet wurde, jetzt ansehen, 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

Im nächsten Schritt ist eine YAML-Datei erforderlich, in der zwei Kubernetes-Ressourcen beschrieben werden: ein Deployment und ein Dienst. 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 angeben, dass die gewünschten Ressourcen erstellt wurden.

Die daraus resultierenden Ressourcen untersuchen

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

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

Als Nächstes werfen wir einen Blick auf die ReplicaSets. Es sollte ein ReplicaSet vorhanden sein, das vom obigen Deployment erstellt wurde.

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

Schließlich werfen wir einen Blick auf die Pods. Das Deployment gibt an, dass es drei Instanzen geben sollte. Der folgende Befehl sollte zeigen, dass es drei Instanzen gibt. Die Option -o wide wird hinzugefügt, sodass 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>

Dienstressource überprüfen

Eine Dienstressource in Kubernetes ist ein Load-Balancer. Die Endpunkte werden durch Labels auf Pods bestimmt. Sobald dem Deployment mit dem obigen kubectl scale deployment-Vorgang neue Pods hinzugefügt werden, stehen die resultierenden Pods sofort für Anfragen zur Verfügung, die von diesem Dienst verarbeitet werden.

Mit dem folgenden Befehl sollte die Dienstressource angezeigt werden.

$ 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 abrufen.

$ 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>

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

Ausgeführte Anwendung prüfen

Jetzt ist die Anwendung live und für Nutzeranfragen bereit. 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 übergibt.

$ 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 Ergebnis sieht dann in etwa so aus:

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

Herzlichen Glückwunsch zum Bereitstellen einer .NET Core-Anwendung in der Google Kubernetes Engine. Als Nächstes nehmen wir eine Änderung an der App vor und stellen sie erneut bereit.

6. App ändern

In diesem Abschnitt wird die Anwendung so geändert, dass der Host angezeigt wird, auf dem die Instanz ausgeführt wird. So lässt sich prüfen, ob das Load-Balancing funktioniert und die verfügbaren Pods wie erwartet antworten.

Quellcode abrufen

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

App mit Hostnamen aktualisieren

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 bisher kann über die Webvorschau auf die App zugegriffen werden. Dieses Mal sollte der Host-Parameter sichtbar sein, wie hier gezeigt:

Cloud Shell

Öffnen Sie in Cloud Shell einen neuen Tab und führen Sie docker ps aus, um zu prüfen, ob die Container-ID mit dem oben gezeigten 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 es von Kubernetes abgerufen werden 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

Taggen Sie dann das Image und übertragen Sie es per Push in Google Container Registry. Mit der IMAGE-ID 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 wieder 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

Diese muss geändert werden, damit sie auf das Container-Image verweist, das oben erstellt und in gcr.io übertragen wurde.

        image: gcr.io/PROJECT_ID/aspnetapp:alpine

Vergiss nicht, es zu ändern, um deine PROJECT_ID zu verwenden. Wenn Sie fertig sind, sollte es in etwa 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

Beachten Sie, dass die Bereitstellungsressource aktualisiert und die Dienstressource unverändert angezeigt wird. Die aktualisierten Pods können wie zuvor mit dem Befehl kubectl get pod aufgerufen werden, aber dieses Mal fügen wir den -w hinzu, wodurch alle Änderungen in Echtzeit beobachtet werden.

$ 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 in Echtzeit. Zuerst werden neue Container gestartet und bei ihrer Ausführung die alten Container beendet.

Ausgeführte Anwendung prüfen

Jetzt ist die Anwendung 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 Ergebnis sieht dann in etwa 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, wenn der Dienst das Load-Balancing der Anfragen auf verschiedene Pods verteilt. Vergleichen Sie die Hostwerte mit der Pod-Liste oben, um festzustellen, ob alle Pods Traffic empfangen.

Instanzen hochskalieren

Die Skalierung von Anwendungen in Kubernetes ist einfach. Mit dem folgenden Befehl wird das Deployment auf bis zu 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 aufgerufen werden.

kubectl get pod -w

Wenn Sie dasselbe 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 mithilfe von GKE in Kubernetes bereitgestellt. Anschließend wurde die Anwendung geändert, um den Hostnamen des Containers anzuzeigen, in dem sie ausgeführt wurde. Das Kubernetes-Deployment wurde dann auf die neue Version aktualisiert und die Anwendung wurde hochskaliert, um zu zeigen, wie die Last auf zusätzliche Instanzen verteilt wird.

In diesen Anleitungen erfahren Sie mehr über .NET und Kubernetes. Sie bauen auf dem auf, was in diesem Lab gelernt wurde, und haben Istio Service Mesh für komplexere Routing- und Ausfallsicherheitsmuster eingeführt.

9. Bereinigen

Um unbeabsichtigte Kosten zu vermeiden, löschen Sie mit den folgenden Befehlen den Cluster und das Container-Image, die in diesem Lab erstellt wurden.

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