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 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 Traffic-Routen zu den Windows-Pods.

Ziele

  • GKE-Cluster erstellen und einrichten, um Windows-Anwendungen und Envoy-Proxys auszuführen
  • Stellen Sie die Windows-Anwendungen bereit und prüfen Sie sie.
  • 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.
  • 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 in einer freigegebenen VPC-Umgebung (Virtual Private Cloud) arbeiten, müssen Sie außerdem die Anleitung zum manuellen Erstellen des Subnetzwerks und der Firewallregel nur für den Proxy für die Cloud Load Balancing-Reaktionsschnelligkeitstests befolgen.

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 den Windows-Knotenpool dem GKE-Cluster 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- und drei Windows-Knoten enthalten.

    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 drucken 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) verfügbar zu machen.

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 für die 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: Überprü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-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 achten Sie darauf, dass drei Pods ausgeführt werden.

  10. Prüfen Sie, ob der Kubernetes-Dienst 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 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. 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 mit der zweiten Anwendung verknüpft, die Sie als Backend für den Cloud Service Mesh-Backend-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 weitere Ressourcen konfigurieren, um die Cloud Service Mesh-Einrichtung abzuschließen.

In den folgenden Schritten wird gezeigt, wie eine Gateway-Ressource konfiguriert wird. Eine Gateway-Ressource ist eine virtuelle Ressource, mit der Cloud Service Mesh-Routingregeln generiert werden. Mit Cloud Service Mesh-Routingregeln werden Envoy-Proxys als Gateways konfiguriert.

Im Folgenden wird gezeigt, wie Sie für jeden Back-End-Dienst eine HTTPRoute-Ressource 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 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 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 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. Die YAML-Bereitstellungsdatei erfüllt folgende Aufgaben:

  • Bootstrappt die Envoy-Gateways.
  • Konfiguriert die Envoy-Gateways so, dass sie Cloud Service Mesh als Steuerungsebene verwenden.
  • Konfiguriert die Envoy-Gateways so, dass HTTPRoutes für das Gateway mit dem Namen Gateway80 verwendet wird.

Stellen Sie zwei Envoy-Gateway-Repliken bereit. Dieser Ansatz trägt dazu bei, die Gateways fehlertolerant zu machen und Redundanz zu bieten. Sie können optional ein horizontales Pod-Autoscaling konfigurieren, um die Envoy-Gateways automatisch basierend auf der Last zu skalieren. Wenn Sie einen Horizontal Pod Autoscaler 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 die Projektnummer ermitteln. Führen Sie dazu den folgenden Befehl aus:
      gcloud projects describe $(gcloud config get project)
 --format="value(projectNumber)"

    Über Port 15005 wird der Envoy-Admin-Endpunkt mit dem Namen /stats freigegeben. 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 freizugeben. Außerdem müssen Sie eine YAML-Datei mit dem Namen BackendConfig erstellen. BackendConfig definiert einen nicht standardmäßigen Reaktionsfähigkeitscheck. Mit dieser Prüfung wird die Reaktionsfähigkeit der Envoy-Gateways überprüft.

  2. Wenn Sie die Backendkonfiguration mit einer nicht standardmäßigen Prüfung der Reaktionsfähigkeit 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 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

Durch das Erstellen der Kubernetes-Gateway-Ressource wird der interne Application Load Balancer bereitgestellt, um die Envoy-Gateways freizugeben.

Bevor Sie diese Ressource erstellen, müssen Sie zwei selbstsignierte Beispielzertifikate erstellen und 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 ein internes 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 interne 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 vom Typ „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 sicherzustellen, dass die Envoy-Gateways den Traffic an die richtigen Anwendungs-Pods weiterleiten.

  6. Rufen Sie die IP-Adresse des Kubernetes-Gateways ab 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

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

Envoy-Gateways überwachen

Überwachen Sie Ihre Envoy-Gateways mit Google Cloud Managed Service for Prometheus.

Google Cloud Managed Service for Prometheus sollte standardmäßig für den zuvor erstellten Cluster 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 für 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 Verwaltung > Monitoring > Dashboards.

  3. So importieren Sie das Dashboard:

    1. Klicken Sie auf dem Dashboard-Bildschirm 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 jetzt die wichtigsten Messwerte Ihrer Envoy-Gateways sehen. Sie können Benachrichtigungen auch anhand Ihrer Kriterien konfigurieren. Bevor Sie die Daten bereinigen, senden Sie noch einige weitere Testanfragen an die Anwendungen und sehen Sie sich an, wie sich das Dashboard mit den neuesten Messwerten aktualisiert.

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: