Windows-Anwendungen in einer verwalteten Kubernetes-Umgebung bereitstellen

Last reviewed 2024-08-14 UTC

In diesem Dokument wird beschrieben, wie Sie die Referenzarchitektur unter Netzwerk für Windows-Anwendungen verwalten und skalieren, die in verwaltetem Kubernetes ausgeführt werden bereitstellen.

Diese Anleitung richtet sich an Cloud-Architekten, Netzwerkadministratoren und IT-Experten, die für das Design und die Verwaltung von Windows-Anwendungen verantwortlich sind, die in Google Kubernetes Engine (GKE)-Clustern ausgeführt werden.

Architektur

Das folgende Diagramm zeigt die Referenzarchitektur, die Sie beim Bereitstellen von Windows-Anwendungen verwenden, die in verwalteten GKE-Clustern ausgeführt werden.

Daten fließen über einen internen Application Load Balancer und ein Envoy-Gateway.

Wie im vorherigen Diagramm dargestellt, stellt ein Pfeil den Workflow für die Verwaltung des Netzwerks für Windows-Anwendungen dar, die in GKE mit Cloud Service Mesh und Envoy-Gateways ausgeführt werden. Der regionale GKE-Cluster enthält sowohl Windows- als auch Linux-Knotenpools. Cloud Service Mesh erstellt und verwaltet Trafficrouten zu den Windows-Pods.

Ziele

  • GKE-Cluster zum Ausführen von Windows-Anwendungen und Envoy-Proxys erstellen und einrichten
  • Windows-Anwendungen bereitstellen und überprüfen
  • Konfigurieren Sie Cloud Service Mesh als Steuerungsebene für die Envoy-Gateways.
  • Verwenden Sie die Kubernetes Gateway API, um den internen Application Load Balancer bereitzustellen und die Envoy-Gateways freizugeben.
  • Sie verstehen die von Ihnen erstellten Vorgänge für die kontinuierliche Bereitstellung.

Kosten

Für die Bereitstellung dieser Architektur werden die folgenden kostenpflichtigen Komponenten vonGoogle Cloudverwendet:

Wenn Sie diese Bereitstellung abgeschlossen haben, können Sie laufende Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweise

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. Enable the Cloud Shell, and Cloud Service Mesh APIs.

    Enable the APIs

  4. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

    Wenn Sie die Tests in einer freigegebenen VPC-Umgebung (Virtual Private Cloud) ausführen, müssen Sie auch der Anleitung zum manuellen Erstellen des reinen Proxy-Subnetzes und der Firewallregel für die Reaktionsfähigkeitstests von Cloud Load Balancing folgen.

    GKE-Cluster erstellen

    So erstellen Sie einen GKE-Cluster: Sie verwenden den GKE-Cluster, um die Windows-Anwendungen und Envoy-Proxys in dieser Bereitstellung zu hosten und auszuführen.

    1. Führen Sie in Cloud Shell den folgenden Google Cloud CLI-Befehl aus, um einen regionalen GKE-Cluster mit einem Knoten in jeder der drei Regionen zu erstellen:

      gcloud container clusters create my-cluster
    --enable-ip-alias \
    --num-nodes=1 \
    --release-channel stable \
    --enable-dataplane-v2 \
    --region us-central1 \
    --scopes=cloud-platform \
    --gateway-api=standard

    2. Fügen Sie dem GKE-Cluster den Windows-Knotenpool hinzu:

      gcloud container node-pools create win-pool \
    --cluster=my-cluster \
    --image-type=windows_ltsc_containerd \
    --no-enable-autoupgrade \
    --region=us-central1 \
    --num-nodes=1 \
    --machine-type=n1-standard-2 \
    --windows-os-version=ltsc2019

      Dieser Vorgang kann etwa 20 Minuten dauern.

    3. Speichern Sie Ihre Google Cloud Projekt-ID in einer Umgebungsvariable:

      export PROJECT_ID=$(gcloud config get project)

    4. Stellen Sie eine Verbindung zum GKE-Cluster her:

      gcloud container clusters get-credentials my-cluster --region us-central1

    5. Alle Knoten im GKE-Cluster auflisten:

      kubectl get nodes

      In der Ausgabe sollten drei Linux-Knoten und drei Windows-Knoten angezeigt werden.

      Wenn der GKE-Cluster bereit ist, können Sie zwei Windows-basierte Testanwendungen bereitstellen.

    Zwei Testanwendungen bereitstellen

    In diesem Abschnitt stellen Sie zwei Windows-basierte Testanwendungen bereit. Beide Testanwendungen geben den Hostnamen aus, auf dem die Anwendung ausgeführt wird. Außerdem erstellen Sie einen Kubernetes-Dienst, um die Anwendung über eigenständige Netzwerkendpunktgruppen (NEGs) bereitzustellen.

    Wenn Sie eine Windows-basierte Anwendung und einen Kubernetes-Dienst in einem regionalen Cluster bereitstellen, wird für jede Zone, in der die Anwendung ausgeführt wird, eine NEG erstellt. Später wird in dieser Bereitstellungsanleitung beschrieben, wie Sie diese NEGs als Back-Ends für Cloud Service Mesh-Dienste konfigurieren können.

    1. Wenden Sie in Cloud Shell die folgende YAML-Datei mit kubectl an, um die erste Testanwendung bereitzustellen. Mit diesem Befehl werden drei Instanzen der Testanwendung bereitgestellt, eine in jeder regionalen Zone.

      apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver-1
  name: win-webserver-1
spec:
  replicas: 3
  selector:
    matchLabels:
      app: win-webserver-1
  template:
    metadata:
      labels:
        app: win-webserver-1
      name: win-webserver-1
    spec:
     containers:
      - name: windowswebserver
        image: k8s.gcr.io/e2e-test-images/agnhost:2.36
        command: ["/agnhost"]
        args: ["netexec", "--http-port", "80"]
     topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: win-webserver-1
     nodeSelector:
      kubernetes.io/os: windows

    2. Wenden Sie den entsprechenden Kubernetes-Dienst an und stellen Sie ihn mit einem NEG bereit:

      apiVersion: v1
kind: Service
metadata:
  name: win-webserver-1
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-1"}}}'
spec:
  type: ClusterIP
  selector:
    app: win-webserver-1
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

    3. Bereitstellung prüfen:

      kubectl get pods

      Die Ausgabe zeigt, dass die Anwendung drei Windows-Pods ausführt.

      NAME                               READY   STATUS    RESTARTS   AGE
win-webserver-1-7bb4c57f6d-hnpgd   1/1     Running   0          5m58s
win-webserver-1-7bb4c57f6d-rgqsb   1/1     Running   0          5m58s
win-webserver-1-7bb4c57f6d-xp7ww   1/1     Running   0          5m58s

    4. Prüfen Sie, ob der Kubernetes-Dienst erstellt wurde:

      $ kubectl get svc

      Die Ausgabe sollte so aussehen:

      NAME              TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes        ClusterIP   10.64.0.1            443/TCP   58m
win-webserver-1   ClusterIP   10.64.6.20           80/TCP    3m35s

    5. Führen Sie den Befehl describe für kubectl aus, um zu prüfen, ob für den Kubernetes-Dienst in jeder der Zonen, in denen die Anwendung ausgeführt wird, entsprechende NEGs erstellt wurden:

      $ kubectl describe service win-webserver-1

      Die Ausgabe sollte so aussehen:

      Name:              win-webserver-1
Namespace:         default
Labels:            
Annotations:       cloud.google.com/neg: {"exposed_ports": {"80":{"name": "win-webserver-1"}}}
                   cloud.google.com/neg-status: {"network_endpoint_groups":{"80":"win-webserver-1"},"zones":["us-central1-a","us-central1-b","us-central1-c"]}
Selector:          app=win-webserver-1
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.64.6.20
IPs:               10.64.6.20
Port:              http  80/TCP
TargetPort:        80/TCP
Endpoints:         10.60.3.5:80,10.60.4.5:80,10.60.5.5:80
Session Affinity:  None
Events:
  Type    Reason  Age    From            Message
  ----    ------  ----   ----            -------
  Normal  Create  4m25s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-a".
  Normal  Create  4m18s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-b".
  Normal  Create  4m11s  neg-controller  Created NEG "win-webserver-1" for default/win-webserver-1-win-webserver-1-http/80-80-GCE_VM_IP_PORT-L7 in "us-central1-c".
  Normal  Attach  4m9s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-a")
  Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-c")
  Normal  Attach  4m8s   neg-controller  Attach 1 network endpoint(s) (NEG "win-webserver-1" in zone "us-central1-b")

      Die Ausgabe des vorherigen Befehls zeigt, dass für jede Zone ein NEG erstellt wurde.

    6. Optional: Mit der gcloud CLI prüfen, ob die NEGs erstellt wurden:

      gcloud compute network-endpoint-groups list

      Die Ausgabe sieht so aus:

      NAME                                                        LOCATION            ENDPOINT_TYPE     SIZE
win-webserver-1                                us-central1-a  GCE_VM_IP_PORT  1
win-webserver-1                                us-central1-b  GCE_VM_IP_PORT  1
win-webserver-1                                us-central1-c  GCE_VM_IP_PORT  1

    7. Wenden Sie die folgende YAML-Datei an, um die zweite Testanwendung bereitzustellen:

      apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: win-webserver-2
  name: win-webserver-2
spec:
  replicas: 3
  selector:
    matchLabels:
      app: win-webserver-2
  template:
    metadata:
      labels:
        app: win-webserver-2
      name: win-webserver-2
    spec:
     containers:
      - name: windowswebserver
        image: k8s.gcr.io/e2e-test-images/agnhost:2.36
        command: ["/agnhost"]
        args: ["netexec", "--http-port", "80"]
     topologySpreadConstraints:
      - maxSkew: 1
        topologyKey: kubernetes.io/hostname
        whenUnsatisfiable: DoNotSchedule
        labelSelector:
          matchLabels:
            app: win-webserver-2
     nodeSelector:
      kubernetes.io/os: windows

    8. Erstellen Sie den entsprechenden Kubernetes-Dienst:

      apiVersion: v1
kind: Service
metadata:
  name: win-webserver-2
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "win-webserver-2"}}}'
spec:
  type: ClusterIP
  selector:
    app: win-webserver-2
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

    9. Anwendungsbereitstellung prüfen:

      kubectl get pods

      Prüfen Sie die Ausgabe und vergewissern Sie sich, dass drei Pods ausgeführt werden.

    10. Prüfen Sie, ob der Kubernetes-Dienst und die drei NEGs erstellt wurden:

      kubectl describe service win-webserver-2

    Cloud Service Mesh konfigurieren

    In diesem Abschnitt wird Cloud Service Mesh als Steuerungsebene für die Envoy-Gateways konfiguriert.

    Sie ordnen die Envoy-Gateways der entsprechenden Cloud Service Mesh-Routingkonfiguration zu, indem Sie den Parameter scope_name angeben. Mit dem Parameter scope_name können Sie verschiedene Routingregeln für die verschiedenen Envoy-Gateways konfigurieren.

    1. Erstellen Sie in Cloud Shell eine Firewallregel, die eingehenden Traffic von den Google-Diensten zulässt, die die Reaktionsfähigkeit der Anwendung prüfen:

      gcloud compute firewall-rules create allow-health-checks \
  --network=default \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp \
  --source-ranges="35.191.0.0/16,130.211.0.0/22,209.85.152.0/22,209.85.204.0/22"

    2. Reaktionsfähigkeit der ersten Anwendung prüfen:

      gcloud compute health-checks create http win-app-1-health-check \
  --enable-logging \
  --request-path="/healthz" \
  --use-serving-port

    3. Prüfen Sie die Reaktionsfähigkeit der zweiten Anwendung:

      gcloud compute health-checks create http win-app-2-health-check \
  --enable-logging \
  --request-path="/healthz" \
  --use-serving-port

    4. Erstellen Sie einen Cloud Service Mesh-Backend-Dienst für die erste Anwendung:

      gcloud compute backend-services create win-app-1-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED \
 --port-name=http \
 --health-checks win-app-1-health-check

    5. Erstellen Sie einen Cloud Service Mesh-Backend-Dienst für die zweite Anwendung:

      gcloud compute backend-services create win-app-2-service \
 --global \
 --load-balancing-scheme=INTERNAL_SELF_MANAGED \
 --port-name=http \
 --health-checks win-app-2-health-check

    6. Fügen Sie die zuvor erstellten NEGs hinzu. Diese NEGs sind der ersten Anwendung zugeordnet, die Sie als Back-End für den Cloud Service Mesh-Backend-Dienst erstellt haben. Mit diesem Codebeispiel wird für jede Zone im erstellten regionalen Cluster eine NEG hinzugefügt.

      BACKEND_SERVICE=win-app-1-service
APP1_NEG_NAME=win-webserver-1
MAX_RATE_PER_ENDPOINT=10

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-b \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-a \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP1_NEG_NAME \
  --network-endpoint-group-zone us-central1-c \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

    7. Fügen Sie weitere NEGs hinzu. Diese NEGs sind mit der zweiten Anwendung verknüpft, die Sie als Backend für den Cloud Service Mesh-Backend-Dienst erstellt haben. Mit diesem Codebeispiel wird für jede Zone im von Ihnen erstellten regionalen Cluster eine NEG hinzugefügt.

      BACKEND_SERVICE=win-app-2-service
APP2_NEG_NAME=win-webserver-2

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-b \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-a \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

gcloud compute backend-services add-backend $BACKEND_SERVICE \
  --global \
  --network-endpoint-group $APP2_NEG_NAME \
  --network-endpoint-group-zone us-central1-c \
  --balancing-mode RATE \
  --max-rate-per-endpoint $MAX_RATE_PER_ENDPOINT

    Zusätzliche Cloud Service Mesh-Ressourcen konfigurieren

    Nachdem Sie die Cloud Service Mesh-Dienste konfiguriert haben, müssen Sie zwei zusätzliche Ressourcen konfigurieren, um die Einrichtung von Cloud Service Mesh abzuschließen.

    In diesen Schritten wird zuerst gezeigt, wie Sie eine Gateway-Ressource konfigurieren. Eine Gateway-Ressource ist eine virtuelle Ressource, die zum Generieren von Cloud Service Mesh-Routingregeln verwendet wird. Cloud Service Mesh-Routingregeln werden verwendet, um Envoy-Proxys als Gateways zu konfigurieren.

    Als Nächstes wird gezeigt, wie Sie eine HTTPRoute-Ressource für jeden der Back-End-Dienste konfigurieren. Die HTTPRoute-Ressource ordnet HTTP-Anfragen dem entsprechenden Back-End-Dienst zu.

    1. Erstellen Sie in Cloud Shell eine YAML-Datei mit dem Namen gateway.yaml, die die Ressource Gateway definiert:

      cat <<EOF> gateway.yaml
name: gateway80
scope: gateway-proxy
ports:
- 8080
type: OPEN_MESH
EOF

    2. Erstellen Sie die Gateway-Ressource, indem Sie die Datei gateway.yaml aufrufen:

      gcloud network-services gateways import gateway80 \
  --source=gateway.yaml \
  --location=global

      Der Name Gateway lautet projects/$PROJECT_ID/locations/global/gateways/gateway80.

      Sie verwenden diesen Gateway-Namen, wenn Sie HTTPRoutes für jeden Backend-Dienst erstellen.

    Erstellen Sie die HTTPRoutes für jeden Backend-Dienst:

    1. Speichern Sie in Cloud Shell Ihre Google Cloud Projekt-ID in einer Umgebungsvariablen:

      export PROJECT_ID=$(gcloud config get project)

    2. Erstellen Sie die HTTPRoute-YAML-Datei für die erste Anwendung:

      cat <<EOF> win-app-1-route.yaml
name: win-app-1-http-route
hostnames:
- win-app-1
gateways:
- projects/$PROJECT_ID/locations/global/gateways/gateway80
rules:
- action:
   destinations:
   - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-1-service"
EOF

    3. Erstellen Sie die HTTPRoute-Ressource für die erste Anwendung:

      gcloud network-services http-routes import win-app-1-http-route \
  --source=win-app-1-route.yaml \
  --location=global

    4. Erstellen Sie die HTTPRoute-YAML-Datei für die zweite Anwendung:

      cat <<EOF> win-app-2-route.yaml
name: win-app-2-http-route
hostnames:
- win-app-2
gateways:
- projects/$PROJECT_ID/locations/global/gateways/gateway80
rules:
- action:
   destinations:
 - serviceName: "projects/$PROJECT_ID/locations/global/backendServices/win-app-2-service"
EOF

    5. Erstellen Sie die Ressource HTTPRoute für die zweite Anwendung:

      gcloud network-services http-routes import win-app-2-http-route \
  --source=win-app-2-route.yaml \
  --location=global

    Envoy-Gateways bereitstellen und verfügbar machen

    Nachdem Sie die beiden Windows-basierten Testanwendungen und Cloud Service Mesh erstellt haben, stellen Sie die Envoy-Gateways bereit, indem Sie eine YAML-Datei für die Bereitstellung erstellen. Mit der YAML-Bereitstellungsdatei werden die folgenden Aufgaben ausgeführt:

    • Bootstraps the Envoy gateways.
    • Konfiguriert die Envoy-Gateways für die Verwendung von Cloud Service Mesh als Steuerungsebene.
    • Konfiguriert die Envoy-Gateways für die Verwendung von HTTPRoutes für das Gateway mit dem Namen Gateway80.

    Stellen Sie zwei Envoy-Gateways mit Replikaten bereit. Dieser Ansatz trägt dazu bei, die Gateways fehlertolerant zu machen und für Redundanz zu sorgen. Wenn Sie die Envoy-Gateways automatisch anhand der Last skalieren möchten, können Sie optional ein horizontales Pod-Autoscaling konfigurieren. Wenn Sie sich für die Konfiguration eines horizontalen Pod-Autoscalers entscheiden, müssen Sie der Anleitung unter Horizontales Pod-Autoscaling konfigurieren folgen.

    1. Erstellen Sie in Cloud Shell eine YAML-Datei:

      apiVersion: apps/v1
kind: Deployment
    metadata:
  creationTimestamp: null
  labels:
    app: td-envoy-gateway
  name: td-envoy-gateway
spec:
  replicas: 2
  selector:
    matchLabels:
      app: td-envoy-gateway
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: td-envoy-gateway
    spec:
      containers:
      - name: envoy
        image: envoyproxy/envoy:v1.21.6
        imagePullPolicy: Always
        resources:
          limits:
            cpu: "2"
            memory: 1Gi
          requests:
            cpu: 100m
            memory: 128Mi
        env:
        - name: ENVOY_UID
          value: "1337"
        volumeMounts:
          - mountPath: /etc/envoy
            name: envoy-bootstrap
      initContainers:
      - name: td-bootstrap-writer
        image: gcr.io/trafficdirector-prod/xds-client-bootstrap-generator
        imagePullPolicy: Always
        args:
          - --project_number='my_project_number'
          - --scope_name='gateway-proxy'
          - --envoy_port=8080
          - --bootstrap_file_output_path=/var/lib/data/envoy.yaml
          - --traffic_director_url=trafficdirector.googleapis.com:443
          - --expose_stats_port=15005
        volumeMounts:
          - mountPath: /var/lib/data
            name: envoy-bootstrap
      volumes:
        - name: envoy-bootstrap
          emptyDir: {}

      • Ersetzen Sie my_project_number durch die Projekt-ID.

        • Sie können Ihre Projektnummer ermitteln. Führen Sie dazu den folgenden Befehl aus:
        gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

      Port 15005 wird verwendet, um den Envoy-Admin-Endpunkt mit dem Namen /stats verfügbar zu machen. Es wird auch für die folgenden Zwecke verwendet:

      • Als Reaktionsfähigkeits-Endpunkt des internen Application Load Balancer.
      • Als Möglichkeit, Google Cloud Managed Service for Prometheus-Messwerte aus Envoy zu nutzen.

      Wenn die beiden Envoy Gateway-Pods ausgeführt werden, erstellen Sie einen Dienst vom Typ ClusterIP, um sie verfügbar zu machen. Sie müssen auch eine YAML-Datei mit dem Namen BackendConfig erstellen. BackendConfig definiert einen nicht standardmäßigen Reaktionsfähigkeitstest. Mit dieser Prüfung wird die Reaktionsfähigkeit der Envoy-Gateways überprüft.

    2. Wenn Sie die Backend-Konfiguration mit einer nicht standardmäßigen Reaktionsfähigkeitsprüfung erstellen möchten, erstellen Sie eine YAML-Datei mit dem Namen envoy-backendconfig:

      apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: envoy-backendconfig
spec:
  healthCheck:
    checkIntervalSec: 5
    timeoutSec: 5
    healthyThreshold: 2
    unhealthyThreshold: 3
    type: HTTP
    requestPath: /stats
    port: 15005

      Bei der Reaktionsfähigkeitsprüfung wird der /stats-Endpunkt auf Port 15005 verwendet, um die Reaktionsfähigkeit der Envoy-Gateways kontinuierlich zu prüfen.

    3. Erstellen Sie den Envoy-Gateways-Dienst:

      apiVersion: v1
kind: Service
metadata:
  name: td-envoy-gateway
  annotations:
    cloud.google.com/backend-config: '{"default": "envoy-backendconfig"}'
spec:
  type: ClusterIP
  selector:
    app: td-envoy-gateway
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
  - name: stats
    protocol: TCP
    port: 15005
    targetPort: 15005

    4. Rufen Sie den von Ihnen erstellten Envoy-Gateways-Dienst auf:

      kubectl get svc td-envoy-gateway

    Kubernetes-Gateway-Ressource erstellen

    Durch das Erstellen der Kubernetes-Gateway-Ressource wird der interne Application Load Balancer bereitgestellt, um die Envoy-Gateways verfügbar zu machen.

    Bevor Sie diese Ressource erstellen, müssen Sie zwei selbstsignierte Beispielzertifikate erstellen und sie dann als Kubernetes-Secrets in den GKE-Cluster importieren. Die Zertifikate ermöglichen die folgende Gateway-Architektur:

    • Jede Anwendung wird über HTTPS bereitgestellt.
    • Jede Anwendung verwendet ein eigenes Zertifikat.

    Wenn Sie selbstverwaltete Zertifikate verwenden, kann der interne Application Load Balancer bis zum maximalen Zertifikatslimit verwenden, um Anwendungen mit verschiedenen voll qualifizierten Domainnamen bereitzustellen.

    Verwenden Sie openssl, um die Zertifikate zu erstellen.

    1. Generieren Sie in Cloud Shell eine Konfigurationsdatei für das erste Zertifikat:

      cat <<EOF >CONFIG_FILE
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = win-webserver-1.example.com
[sans_list]
DNS.1                     = win-webserver-1.example.com
EOF

    2. Generieren Sie einen privaten Schlüssel für das erste Zertifikat:

      openssl genrsa -out sample_private_key 2048

    3. Zertifikatsanfrage generieren:

      openssl req -new -key sample_private_key -out CSR_FILE -config CONFIG_FILE

    4. Signieren Sie das erste Zertifikat und generieren Sie es:

      openssl x509 -req -signkey sample_private_key -in CSR_FILE -out sample.crt     -extfile CONFIG_FILE -extensions extension_requirements -days 90

    5. Generieren Sie eine Konfigurationsdatei für das zweite Zertifikat:

      cat <<EOF >CONFIG_FILE2
[req]
default_bits              = 2048
req_extensions            = extension_requirements
distinguished_name        = dn_requirements
prompt                    = no
[extension_requirements]
basicConstraints          = CA:FALSE
keyUsage                  = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName            = @sans_list
[dn_requirements]
0.organizationName        = example
commonName                = win-webserver-2.example.com
[sans_list]
DNS.1                     = win-webserver-2.example.com
EOF

    6. Generieren Sie einen privaten Schlüssel für das zweite Zertifikat:

      openssl genrsa -out sample_private_key2 2048

    7. Zertifikatsanfrage generieren:

      openssl req -new -key sample_private_key2 -out CSR_FILE2 -config CONFIG_FILE2

    8. Signieren Sie das zweite Zertifikat und generieren Sie es:

      openssl x509 -req -signkey sample_private_key2 -in CSR_FILE2 -out sample2.crt     -extfile CONFIG_FILE2 -extensions extension_requirements -days 90

    Zertifikate als Kubernetes-Secrets importieren

    In diesem Abschnitt führen Sie die folgenden Aufgaben aus:

    • Importieren Sie die selbst signierten Zertifikate als Kubernetes-Secrets in den GKE-Cluster.
    • Erstellen Sie eine statische IP-Adresse für eine interne VPC.
    • Erstellen Sie die Kubernetes Gateway API-Ressource.
    • Prüfen Sie, ob die Zertifikate funktionieren.

    1. Importieren Sie in Cloud Shell das erste Zertifikat als Kubernetes-Secret:

      kubectl create secret tls sample-cert --cert sample.crt --key sample_private_key

    2. Importieren Sie das zweite Zertifikat als Kubernetes-Secret:

      kubectl create secret tls sample-cert-2 --cert sample2.crt --key sample_private_key2

    3. Wenn Sie den internen Application Load Balancer aktivieren möchten, erstellen Sie eine statische IP-Adresse in der internen VPC:

      gcloud compute addresses create sample-ingress-ip --region us-central1 --subnet default

    4. Erstellen Sie die YAML-Datei für die Kubernetes Gateway API-Ressource:

      kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: internal-https
spec:
  gatewayClassName: gke-l7-rilb
  addresses:
    - type: NamedAddress
      value: sample-ingress-ip
  listeners:
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      mode: Terminate
      certificateRefs:
      - name: sample-cert
      - name: sample-cert-2

      Standardmäßig hat ein Kubernetes-Gateway keine Standardrouten. Das Gateway gibt einen Fehler der Kategorie „Seite nicht gefunden“ (404) zurück, wenn Anfragen an das Gateway gesendet werden.

    5. Konfigurieren Sie eine Standard-YAML-Datei route für das Kubernetes-Gateway, die alle eingehenden Anfragen an die Envoy-Gateways weiterleitet:

        kind: HTTPRoute
  apiVersion: gateway.networking.k8s.io/v1beta1
  metadata:
    name: envoy-default-backend
  spec:
    parentRefs:
    - kind: Gateway
      name: internal-https
    rules:
    - backendRefs:
      - name: td-envoy-gateway
        port: 8080

      Prüfen Sie den gesamten Ablauf, indem Sie HTTP-Anfragen an beide Anwendungen senden. Prüfen Sie den HTTP-Host-Header, um zu bestätigen, dass die Envoy-Gateways Traffic an die richtigen Anwendungs-Pods weiterleiten.

    6. Suchen Sie die Kubernetes Gateway-IP-Adresse und speichern Sie sie in einer Umgebungsvariablen:

      export EXTERNAL_IP=$(kubectl get gateway internal-https -o json | jq .status.addresses[0].value -r)

    7. Senden Sie eine Anfrage an die erste Anwendung:

      curl --insecure -H "Host: win-app-1" https://$EXTERNAL_IP/hostName

    8. Senden Sie eine Anfrage an die zweite Anwendung:

      curl --insecure -H "Host: win-app-2" https://$EXTERNAL_IP/hostName

    9. Prüfen Sie, ob der von der Anfrage zurückgegebene Hostname mit den Pods übereinstimmt, auf denen win-app-1 und win-app-2 ausgeführt werden:

      kubectl get pods

      In der Ausgabe sollten win-app-1 und win-app-2 angezeigt werden.

    Envoy-Gateways überwachen

    Sie können Ihre Envoy-Gateways mit Google Cloud Managed Service for Prometheus überwachen.

    Google Cloud Managed Service for Prometheus sollte standardmäßig für den Cluster aktiviert sein, den Sie zuvor erstellt haben.

    1. Erstellen Sie in Cloud Shell eine PodMonitoring-Ressource, indem Sie die folgende YAML-Datei anwenden:

      apiVersion: monitoring.googleapis.com/v1
kind: PodMonitoring
metadata:
  name: prom-envoy
spec:
  selector:
    matchLabels:
      app: td-envoy-gateway
  endpoints:
  - port: 15005
    interval: 30s
    path: /stats/prometheus

      Nachdem Sie die YAML-Datei angewendet haben, beginnt das System, Messwerte für Google Cloud Managed Service for Prometheus in einem Dashboard zu erfassen.

    2. So erstellen Sie das Dashboard für Google Cloud Managed Service for Prometheus-Messwerte:

      1. In der Google Cloud Console anmelden
      2. Öffnen Sie das Menü .
      3. Klicken Sie auf Vorgänge > Monitoring > Dashboards.

    3. So importieren Sie das Dashboard:

      1. Klicken Sie auf dem Bildschirm „Dashboards“ auf Beispielbibliothek.
      2. Geben Sie „envoy“ in das Filterfeld ein.
      3. Klicken Sie auf Istio Envoy Prometheus – Übersicht.
      4. Klicken Sie das Kästchen an.
      5. Klicken Sie auf Importieren und dann auf Bestätigen, um das Dashboard zu importieren.

    4. So rufen Sie das Dashboard auf:

      1. Klicken Sie auf Dashboard-Liste.
      2. Wählen Sie Integrationen aus.
      3. Klicken Sie auf Istio Envoy Prometheus – Übersicht, um das Dashboard aufzurufen.

    Sie können sich jetzt die wichtigsten Messwerte Ihrer Envoy-Gateways ansehen. Sie können auch Benachrichtigungen basierend auf Ihren Kriterien konfigurieren. Bevor Sie die Bereinigung durchführen, senden Sie einige weitere Testanfragen an die Anwendungen und sehen Sie sich an, wie das Dashboard mit den neuesten Messwerten aktualisiert wird.

    Bereinigen

    Damit Ihrem Google Cloud -Konto die in dieser Bereitstellung verwendeten Ressourcen nicht in Rechnung gestellt werden, löschen Sie entweder das Projekt, das die Ressourcen enthält, oder behalten Sie das Projekt bei und löschen Sie die einzelnen Ressourcen.

    Projekt löschen

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

    Nächste Schritte

    Beitragende

    Autor: Eitan Eibschutz | Staff Technical Solutions Consultant

    Weitere Beitragende: