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

1. Übersicht

Microsoft .NET Core ist eine Open-Source- und plattformübergreifende 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-App in 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 App mit GKE in Kubernetes bereitgestellt. Das Lab enthält die Schritte zum Erstellen eines GKE-Clusters.

Im zweiten Teil des Labs wird eine geringfügige Änderung an der App vorgenommen, die den Hostnamen des Containers anzeigt, in dem die App-Instanz 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:

Kosten

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

• Google Kubernetes Engine – Preise
• Google Container Registry-Preise

2. Einrichtung und Anforderungen

Vorbereitung

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

In diesem Lab wird Docker in Cloud Shell verwendet. Cloud Shell ist über die Google Cloud Console verfügbar und enthält viele nützliche Tools wie gcloud und Docker. Unten sehen Sie, wie Sie auf die Cloud Shell zugreifen. Klicken Sie rechts oben auf das Cloud Shell-Symbol, um es im unteren Bereich des Konsolenfensters zu öffnen.

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 GKE bieten. Mit den folgenden Befehlen können Sie beispielsweise verschiedene Maschinentypen, Zonen und sogar GPUs (Beschleuniger) identifizieren.

• Mit dem Befehl gcloud compute machine-types list können Sie Maschinentypen auflisten.
• Mit dem Befehl gcloud compute accelerator-types list können Sie GPUs auflisten.
• Mit diesem Befehl können Sie Computing-Zonen auflisten: gcloud compute zones list
• Hilfe zu einem beliebigen gcloud-Befehl erhalten gcloud container clusters --help
  • Beispiel: Hier finden Sie 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.

Kubernetes-Cluster erstellen

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

Achten Sie darauf, den Exportbefehl mit Ihrem eigenen YOUR_PROJECT_ID zu ändern. Sie können die Zone bei Bedarf auch ändern.

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}

Wenn das Zeitlimit für Ihre Cloud Shell-Sitzung überschritten wird und Sie die Verbindung wiederherstellen müssen, müssen Sie die oben genannten Befehle noch einmal ausführen. Das liegt daran, dass bei vielen anderen Befehlen in diesem Lab davon ausgegangen wird, dass diese Umgebungsvariablen und gcloud-Konfigurationseinstellungen festgelegt sind.

GKE-Cluster erstellen

Da in diesem Lab die .NET Core-App in Kubernetes bereitgestellt wird, muss ein Cluster erstellt werden. Verwenden Sie den folgenden Befehl, um einen neuen Kubernetes-Cluster in Google Cloud mit 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 Umgebungsvariable oben angegeben haben, und us-central1-b verwendet.
  • HINWEIS: Diese Liste darf keine doppelten Einträge 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 gerade erstellten neuen 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.

Sie sollten jetzt kubectl verwenden können, um 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.

• https://hub.docker.com/_/microsoft-dotnet
• https://hub.docker.com/_/microsoft-dotnet-samples

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

Prüfen Sie in Cloud Shell, ob Docker ordnungsgemäß ausgeführt wird und ob 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

Funktionalität der Webanwendung bestätigen

Eine Beispielwebanwendung kann auch in Cloud Shell validiert werden. Mit dem folgenden Docker-Befehl wird ein neuer Container erstellt, der den Port 80 freigibt und ihn dem Port 8080 auf dem Host 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 Web-App handelt, muss sie in einem Webbrowser aufgerufen und validiert werden. Im nächsten Abschnitt wird gezeigt, wie Sie das in Cloud Shell mit der Webvorschau tun können.

4. Über „Webvorschau“ auf Dienste in Cloud Shell 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.

Apps in Cloud Shell mit der „Webvorschau“ ansehen

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

Dadurch wird ein Browserfenster mit einer Adresse wie dieser geöffnet:

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

Mit der Option Port ändern können Sie den Port, auf dem der Dienst in Cloud Shell ausgeführt wird, an den Port anpassen, der von der Webvorschau verwendet wird.

.NET-Beispielanwendung mit der Webvorschau ansehen

Die im letzten Schritt gestartete Beispiel-App kann jetzt in der Webvorschau aufgerufen werden. Laden Sie dazu die angegebene URL. Die Ausgabe sollte ungefähr so aussehen:

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

Wenden Sie diese Datei jetzt mit kubectl auf Kubernetes an.

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

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

Erstellte Ressourcen ansehen

Mit der kubectl-Befehlszeile können wir die oben erstellten Ressourcen untersuchen. Sehen wir uns zuerst die Deployment-Ressourcen an und prüfen, ob das neue Deployment 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 werden.

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

Sehen Sie sich zum Schluss die Pods an. Das Deployment hat angegeben, dass es drei Instanzen geben sollte. Der folgende Befehl sollte zeigen, dass es drei Instanzen gibt. 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 überprüfen

Eine Service-Ressource in Kubernetes ist ein Load-Balancer. Die Endpunkte werden durch Labels für Pods bestimmt. Sobald der Bereitstellung über den oben genannten 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.

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 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 auf alle Instanzen (Pods) verteilt. Der Wert Endpoints oben zeigt die IPs der Pods, die derzeit für diesen Dienst verfügbar sind. Vergleichen Sie diese mit den IPs der oben ausgegebenen Pods.

Ausgeführte App überprüfen

Die Anwendung ist jetzt aktiv und kann Nutzeranfragen verarbeiten. Um darauf zuzugreifen, verwenden Sie einen Proxy. 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

Greifen Sie jetzt mit der Webvorschau in Cloud Shell auf die Webanwendung zu.

Eine Anleitung zur Webvorschau finden Sie in Schritt 4 unter Über die Webvorschau auf Dienste in Cloud Shell zugreifen.

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/

Herzlichen Glückwunsch zur Bereitstellung einer .NET Core-Anwendung in Google Kubernetes Engine. Als Nächstes nehmen wir eine Änderung an der App vor und stellen sie noch einmal 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 können Sie bestätigen, dass der Lastenausgleich 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/

App aktualisieren, damit sie den Hostnamen enthält

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 .

Neue Anwendung wie zuvor lokal testen

$ 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 auf die App über die Webvorschau zugegriffen werden. Der Parameter „Host“ sollte nun sichtbar sein, wie hier gezeigt:

Öffnen Sie einen neuen Tab in Cloud Shell und führen Sie docker ps aus, um zu sehen, dass die Container-ID mit dem oben gezeigten Host-Wert ü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 mit einem Tag versehen und per Push übertragen, damit es für Kubernetes verfügbar ist

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

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

Als Nächstes müssen Sie das Image mit einem Tag versehen und in die Google Container Registry hochladen. Mit der oben genannten BILD-ID sieht das so aus:

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

7. Aktualisierte Anwendung neu 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, damit auf das Container-Image verwiesen wird, das oben erstellt und in gcr.io übertragen wurde.

        image: gcr.io/PROJECT_ID/aspnetapp:alpine

Vergessen Sie nicht, den Code so zu ändern, dass er Ihre PROJECT_ID verwendet. Wenn Sie fertig sind, sollte es 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. Dieses Mal fügen wir jedoch -w hinzu, um alle Änderungen zu beobachten, sobald sie eintreten.

$ 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 der Ausführung. Zuerst werden neue Container gestartet. Wenn sie ausgeführt werden, werden die alten Container beendet.

Ausgeführte App überprüfen

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

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

Greifen Sie jetzt mit der Webvorschau in Cloud Shell auf die Webanwendung zu.

Eine Anleitung zur Webvorschau finden Sie in Schritt 4.

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 per Load-Balancing auf verschiedene Pods verteilt werden. Vergleichen Sie die Host-Werte mit der Liste der Pods oben, um zu sehen, dass alle Pods Traffic empfangen.

Instanzen vertikal skalieren

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

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

Mit diesem Befehl können Sie die neuen Pods und ihren aktuellen Status aufrufen.

kubectl get pod -w

Beachten Sie das -w im obigen Befehl. Das bedeutet, dass der Befehl „beobachtet“ wird. In diesem Fall ist es so einfach, die Pods zu sehen, wenn sie erstellt werden und online gehen.

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-Beispielwebanwendung in einer Entwicklungsumgebung validiert und anschließend mit GKE in Kubernetes bereitgestellt. Die App wurde dann so geändert, dass der Hostname des Containers angezeigt wird, in dem sie ausgeführt wurde. Das Kubernetes-Deployment wurde dann auf die neue Version aktualisiert und die App wurde skaliert, 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 den Erkenntnissen aus diesem Lab auf und führen Istio Service Mesh für komplexere Routing- und Resilienzmuster ein.

• https://codelabs.developers.google.com/codelabs/cloud-istio-aspnetcore-part1#0
• https://codelabs.developers.google.com/codelabs/cloud-istio-aspnetcore-part2#0

9. Bereinigen

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

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