Windows-Anwendungen in verwalteter 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 auf 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.

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

Wie im vorherigen Diagramm dargestellt, steht ein Pfeil für den Workflow zum Verwalten des Netzwerks für Windows-Anwendungen, 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.

Lernziele

  • GKE-Cluster erstellen und einrichten, um Windows-Anwendungen und Envoy-Proxys auszuführen
  • Windows-Anwendungen bereitstellen und prüfen
  • Konfigurieren Sie Cloud Service Mesh als Steuerungsebene für die Envoy-Gateways.
  • Mit der Kubernetes Gateway API den internen Application Load Balancer bereitstellen und die Envoy-Gateways verfügbar machen.
  • Informationen zu den von Ihnen erstellten Vorgängen für die kontinuierliche Bereitstellung

Kosten

Für die Bereitstellung dieser Architektur werden die folgenden kostenpflichtigen Komponenten von Google Cloud verwendet:

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. Make sure 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 Anwendung in einer freigegebenen VPC-Umgebung (Virtual Private Cloud) ausführen, folgen Sie der Anleitung zum manuellen Erstellen des Nur-Proxy-Subnetzes und der Firewallregel für die Cloud. Reaktionsfähigkeitsprüfungen für das Load-Balancing.

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 enthalten 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 Ihr Google Cloud-Projekt 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. Listen Sie alle Knoten im GKE-Cluster auf:

    kubectl get nodes

    Die Ausgabe sollte drei Linux-Knoten und drei Windows-Knoten anzeigen.

    Sobald 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 Netzwerk-Endpunktgruppen (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 in diesem Bereitstellungsleitfaden erfahren Sie, wie Sie diese NEGs als Back-Ends für Cloud Service Mesh-Dienste konfigurieren.

  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 übereinstimmenden 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 in der Anwendung drei Windows-Pods ausgeführt werden.

    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 Zone, in der 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 eine NEG erstellt wurde.

  6. Optional: Prüfen Sie mit der gcloud CLI, 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. Um die zweite Testanwendung bereitzustellen, wenden Sie die folgende YAML-Datei an:

    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-Service:

    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. Prüfen Sie die Anwendungsbereitstellung:

    kubectl get pods

    Prüfen Sie die Ausgabe und achten Sie darauf, dass drei Pods ausgeführt werden.

  10. Prüfen Sie, ob der Kubernetes-Service und 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 unterschiedliche 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 Anwendungen 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. Prüfen Sie die Reaktionsfähigkeit der ersten Anwendung:

    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-Backenddienst 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-Backenddienst 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 mit der ersten Anwendung verknüpft, die Sie als Back-End für den Cloud Service Mesh-Back-End-Dienst erstellt haben. In diesem Codebeispiel wird für jede Zone im von Ihnen 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 der zweiten Anwendung zugeordnet, die Sie als Back-End für den Cloud Service Mesh-Back-End-Dienst erstellt haben. In 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 den folgenden Schritten wird 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 Backend-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 von 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 Back-End-Dienst:

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

    export PROJECT_ID=$(gcloud config get project)

  2. Erstellen Sie die YAML-Datei HTTPRoute 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 Ressource HTTPRoute 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 HTTPRoute-Ressource 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 freigeben

Nachdem Sie die beiden Windows-basierten Testanwendungen und das 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:

  • Bootet die Envoy-Gateways.
  • Es konfiguriert die Envoy-Gateways für die Verwendung von Cloud Service Mesh als Steuerungsebene.
  • Konfiguriert die Envoy-Gateways so, dass HTTPRoutes für das Gateway mit dem Namen Gateway80 verwendet wird.

Zwei Envoy-Gateways erstellen. Dieser Ansatz trägt dazu bei, die Gateways fehlertolerant zu machen und Redundanz zu bieten. Wenn Sie die Envoy-Gateways automatisch basierend auf der Last skalieren möchten, können Sie optional ein horizontales Pod-Autoscaling konfigurieren. Wenn Sie ein horizontales Pod-Autoscaling konfigurieren möchten, 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, indem Sie den folgenden Befehl ausführen:
      gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

    Port 15005 wird verwendet, um den Envoy-Administrator-Endpunkt mit dem Namen /stats verfügbar zu machen. Außerdem wird sie für folgende Zwecke verwendet:

    • Als Reaktionsendpunkt vom internen Application Load Balancer.
    • Sie können damit Google Cloud Managed Service for Prometheus-Messwerte aus Envoy nutzen.

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

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

    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 Prüfung der Reaktionsfähigkeit wird der /stats-Endpunkt an Port 15005 verwendet, um die Reaktionsfähigkeit der Envoy-Gateways kontinuierlich zu prüfen.

  3. Erstellen Sie den Envoy-Gateway-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-Gateway-Dienst auf:

    kubectl get svc td-envoy-gateway

Kubernetes-Gateway-Ressource erstellen

Wenn Sie die Kubernetes-Gateway-Ressource erstellen, 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 diese 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.

Bei der Verwendung selbstverwalteter Zertifikate kann der interne Application Load Balancer bis zu die maximale Anzahl von Zertifikaten verwenden, um Anwendungen mit verschiedenen voll qualifizierten Domainnamen bereitzustellen.

Verwenden Sie openssl, um die Zertifikate zu erstellen.

  1. Erstellen 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 und generieren Sie das erste Zertifikat:

    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 und generieren Sie das zweite Zertifikat:

    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. Erstellen Sie eine statische IP-Adresse in der internen VPC, um den internen Anwendungs-Load-Balancer zu aktivieren:

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

  4. Erstellen Sie die YAML-Datei der 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 vom Typ „Seite nicht gefunden“ (404) zurück, wenn Anfragen an das Gateway gesendet werden.

  5. Konfigurieren Sie eine standardmäßige 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 sicherzustellen, dass die Envoy-Gateways den Traffic an die richtigen Anwendungs-Pods weiterleiten.

  6. Suchen und speichern Sie die IP-Adresse des Kubernetes-Gateways 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

    Die Ausgabe sollte win-app-1 und win-app-2 anzeigen.

Envoy-Gateways überwachen

Envoy-Gateways mit Google Cloud Managed Service for Prometheus überwachen

Google Cloud Managed Service for Prometheus sollte in dem zuvor erstellten Cluster standardmäßig aktiviert sein.

  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

    Nach dem Anwenden der YAML-Datei beginnt das System, Google Cloud Managed Service for Prometheus-Messwerte in einem Dashboard zu erfassen.

  2. So erstellen Sie das Messwert-Dashboard von Google Cloud Managed Service for Prometheus:

    1. Melden Sie sich in der Google Cloud Console an.
    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 sehen jetzt die wichtigsten Messwerte Ihrer Envoy-Gateways. Sie können Benachrichtigungen auch anhand Ihrer Kriterien konfigurieren. Senden Sie vor der Bereinigung noch einige Testanfragen an die Anwendungen und prüfen Sie, 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 | Technical Solutions Consultant

Weitere Beitragende: