Klassischen Application Load Balancer für Cloud Service Mesh konfigurieren

Übersicht

Dieses Dokument richtet sich an bestehende Cloud Service Mesh-Nutzer, die die verwaltete Istiod-Steuerungsebene verwenden und den klassischen Application Load Balancer als Ingress-Gateway konfigurieren möchten. Der klassische Application Load Balancer wird auch als klassischer externer Application Load Balancer bezeichnet.

Verwenden Sie dieses Dokument nicht, wenn Sie ein neuer Cloud Service Mesh-Nutzer sind. Neue Nutzer werden automatisch mit der von Cloud Service Mesh verwalteten Steuerungsebene eingerichtet. Sie können die in diesem Dokument beschriebene Konfiguration nicht mit der von Cloud Service Mesh verwalteten Steuerungsebene verwenden.

Cloud Load Balancing bietet viele cloudverwaltete Edge-Funktionen, darunter globales Anycast-Load-Balancing, von Google verwaltete Zertifikate, Identity and Access Management, Cloud Next Generation Firewall und Cloud Intrusion Detection System. Cloud Service Mesh kann diese Edge-Funktionen nahtlos in das folgende Mesh-Ingress-Modell einbinden. Das Service Mesh-Cloud-Gateway bietet eine einheitliche Möglichkeit, das Cloud Service Mesh-Ingress-Gateway mit Cloud Load Balancing gleichzeitig über die Kubernetes Gateway API zu konfigurieren.

Diagramm eines Load-Balancers mit Cloud Service Mesh

Im Vergleich zu unserer vorherigen Anleitung Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen kann dieses Modell mit Service Mesh Cloud Gateway jetzt über eine Kubernetes Gateway-Ressource bereitgestellt werden, was die Bereitstellung von Cloud- und Cluster-basiertem Load Balancing vereinfacht.

Vorschau Einschränkungen

Für die Vorabversion dieses Features gelten die folgenden Einschränkungen:

  • Multi-Cluster-Gateways werden nicht unterstützt.
  • Autopilot-Cluster werden nicht unterstützt.
  • Nur der klassische Application Load Balancer wird unterstützt. Der globale externe Application Load Balancer (manchmal auch als Advanced Load Balancer bezeichnet) und der interne Application Load Balancer werden nicht unterstützt.
  • Der Traffic zwischen dem klassischen Application Load Balancer und dem Cloud Service Mesh-Ingress-Gateway wird mit TLS verschlüsselt. Der klassische Application Load Balancer überprüft jedoch nicht das vom Cloud Service Mesh-Ingress-Gateway bereitgestellte Zertifikat. Diese Einschränkung gilt für alle Nutzer von Google Cloud HTTP(S)-Load-Balancern.
  • Wenn Cloud Service Mesh-GatewayClasses aus einem Cluster gelöscht werden, werden sie nicht automatisch neu installiert. Dies hat jedoch keine Auswirkungen auf die Benutzerfreundlichkeit der Funktion.
  • Die Logik für den Routenabgleich entspricht nicht den Gateway API-Spezifikationen, sondern dem HTTPRoute. Dies wird sich in zukünftigen Versionen ändern, um den Gateway API-Spezifikationen zu entsprechen.

Voraussetzungen

  • Managed Cloud Service Mesh ist in einem Google Kubernetes Engine-Cluster (GKE) mit Version 1.24 oder höher installiert. Andere GKE Enterprise-Cluster werden nicht unterstützt.
  • Nur Kubernetes Gateway API-Version v1beta1.

Vorbereitung

  • Aktivieren Sie die folgenden APIs in Ihrem Projekt:

    • compute.googleapis.com
    • container.googleapis.com
    • certificatemanager.googleapis.com
    • serviceusage.googleapis.com
    gcloud services enable \
       compute.googleapis.com \
       container.googleapis.com \
       certificatemanager.googleapis.com \
       serviceusage.googleapis.com
    

Service Mesh-Cloud-Gateway für ein Single-Cluster-Mesh bereitstellen

In diesem Abschnitt erfahren Sie, wie Sie eine Kubernetes Gateway-Ressource bereitstellen, mit der ein klassischer Application Load Balancer und ein Cloud Service Mesh-Ingress-Gateway bereitgestellt werden.

Gateway API mit verwaltetem Cloud Service Mesh aktivieren

  1. Aktivieren Sie die Gateway API in Ihrem Cluster. Der GKE-Cluster muss Version 1.24 oder höher haben.

  2. Installieren Sie verwaltetes Cloud Service Mesh mit rapid oder regular als Release-Channel.

Gateway-Ressource bereitstellen

Beim Bereitstellen des Service Mesh-Cloud-Gateways werden die Kubernetes-Gateway-Ressourcen verwendet, um sowohl Cloud Load Balancing als auch das Cloud Service Mesh-Ingress-Gateway in einem einzigen Schritt bereitzustellen. Kubernetes-Gateway-Ressourcen unterscheiden sich von Istio-Gateway-Ressourcen.

Weitere Informationen zu den Unterschieden finden Sie unter Kubernetes-Gateways und Istio-Gateways. Jedes Kubernetes-Gateway hat eine GatewayClass, die seinen Typ und seine inhärenten Funktionen angibt. Das Service Mesh-Cloud-Gateway hat eine GatewayClass, mit der sowohl Cloud Load Balancing- als auch Cloud Service Mesh-Ingress-Gateways bereitgestellt werden können.

  1. Speichern Sie das folgende GatewayClass-Manifest in einer Datei mit dem Namen l7-gateway-class.yaml:

    apiVersion: gateway.networking.k8s.io/v1beta1
    kind: GatewayClass
    metadata:
      name: asm-l7-gxlb
    spec:
      controllerName: mesh.cloud.google.com/gateway
    
  2. Stellen Sie die GatewayClass in Ihrem Cluster bereit:

    kubectl apply -f l7-gateway-class.yaml
    
  3. Prüfen Sie, ob die GatewayClass nach der Installation vorhanden ist:

    kubectl get gatewayclasses.gateway.networking.k8s.io
    

    Die Ausgabe sieht etwa so aus:

    NAME          CONTROLLER
    asm-l7-gxlb   mesh.cloud.google.com/gateway
    gke-l7-rilb   networking.gke.io/gateway
    gke-l7-gxlb   networking.gke.io/gateway
    

    Es kann einige Minuten dauern, bis alle Ressourcen bereitgestellt wurden. Wenn Sie nicht die erwartete Ausgabe erhalten, prüfen Sie, ob Sie die Voraussetzungen richtig erfüllt haben.

    Außerdem wird die folgende GatewayClass angezeigt:

    gke-l7-gxlb   networking.gke.io/gateway
    

    Damit wird der zugrunde liegende klassische Application Load Balancer von Google Cloud bereitgestellt.

  4. Erstellen Sie einen dedizierten Namespace für Ihr Service Mesh-Cloud-Gateway:

    kubectl create namespace istio-ingress
    
  5. Speichern Sie folgendes Gateway-Manifest in einer Datei mit dem Namen gateway.yaml.

    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    spec:
      gatewayClassName: asm-l7-gxlb
      listeners:
      - name: http
        protocol: HTTP
        port: 80
        allowedRoutes:
          namespaces:
            from: All
    
  6. Stellen Sie das Gateway in Ihrem Cluster im Namespace „istio-ingress“ bereit:

    kubectl apply -f gateway.yaml
    
  7. Prüfen Sie, ob die Kubernetes Gateway API-Objekte erstellt wurden:

    kubectl get gateways.gateway.networking.k8s.io -n istio-ingress
    

    Die Ausgabe sieht etwa so aus:

    NAME                                CLASS         ADDRESS         READY   AGE
    asm-gw-gke-servicemesh-cloud-gw     gke-l7-gxlb   34.111.114.64   True    9m40s
    asm-gw-istio-servicemesh-cloud-gw   istio                                 9m44s
    servicemesh-cloud-gw                asm-l7-gxlb                           9m44s
    

Wenn dieses Kubernetes Gateway API-Objekt bereitgestellt wird, passiert Folgendes:

  • Ein externer HTTP(S)-Load-Balancer wird bereitgestellt und konfiguriert. Es kann einige Minuten dauern, bis das Gateway angezeigt wird. Wenn es angezeigt wird, wird die IP-Adresse angegeben und mit den Namen der erstellten Compute Engine-Load-Balancer-Ressourcen versehen.
  • Ein Cloud Service Mesh-Ingress-Gateway-Deployment wird im Namespace „istio-ingress“ erstellt. Dadurch werden die Envoy-Proxy-Instanzen erstellt, die Traffic vom Load-Balancer empfangen.
  • Der Load Balancer verschlüsselt und leitet den gesamten Traffic an das Cloud Service Mesh-Ingress-Gateway weiter.

Sie haben jetzt die gesamte Infrastruktur, die erforderlich ist, um Internettraffic in Ihrem Mesh zu empfangen. Dies ist die einfachste Gateway-Bereitstellung. In den folgenden Abschnitten fügen Sie zusätzliche Richtlinien und Funktionen hinzu, um die Anwendung produktionsreif zu machen.

Bereitstellung von Apps und Routing

Um die Funktionen vollständig zu demonstrieren, stellen Sie eine Anwendung in Cloud Service Mesh bereit und empfangen Internet-Traffic über Ihr Gateway.

  1. Fügen Sie dem Namespace default ein Label hinzu, um die Sidecar-Injektion zu aktivieren.

    kubectl label namespace default istio-injection=enabled istio.io/rev- --overwrite
    
  2. Speichern Sie folgendes Gateway-Manifest in einer Datei mit dem Namen whereami.yaml.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: whereami-v1
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: whereami-v1
      template:
        metadata:
          labels:
            app: whereami-v1
        spec:
          containers:
          - name: whereami
            image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
            ports:
              - containerPort: 8080
            env:
            - name: METADATA
              value: "whereami-v1"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: whereami-v1
    spec:
      selector:
        app: whereami-v1
      ports:
      - port: 8080
        targetPort: 8080
    ---
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: whereami-v2
    spec:
      replicas: 2
      selector:
        matchLabels:
          app: whereami-v2
      template:
        metadata:
          labels:
            app: whereami-v2
        spec:
          containers:
          - name: whereami
            image: us-docker.pkg.dev/google-samples/containers/gke/whereami:v1
            ports:
              - containerPort: 8080
            env:
            - name: METADATA
              value: "whereami-v2"
    ---
    apiVersion: v1
    kind: Service
    metadata:
      name: whereami-v2
    spec:
      selector:
        app: whereami-v2
      ports:
      - port: 8080
        targetPort: 8080
    

    Dieses Manifest erstellt Service/whereami-v1, Service/whereami-v2, Deployment/whereami-v1 und Deployment/whereami-v2 für „whereami“, eine einfache Anwendung, die JSON ausgibt, um ihre Identität und ihren Standort anzugeben. Sie stellen zwei verschiedene Versionen bereit.

  3. Erstellen Sie die Services und Deployments:

    kubectl apply -f whereami.yaml
    

    Sobald sie ausgeführt werden, sind vier „whereami“-Pods in Ihrem Cluster aktiv.

  4. Prüfen Sie, ob alle vier Pods ausgeführt werden:

    kubectl get pods
    

    Die Ausgabe sieht etwa so aus:

    whereami-v1-7c76d89d55-qg6vs       2/2     Running   0          28s
    whereami-v1-7c76d89d55-vx9nm       2/2     Running   0          28s
    whereami-v2-67f6b9c987-p9kqm       2/2     Running   0          27s
    whereami-v2-67f6b9c987-qhj76       2/2     Running   0          27s
    
  5. Speichern Sie folgendes HTTPRoute-Manifest in einer Datei mit dem Namen http-route.yaml.

    kind: HTTPRoute
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: where-route
    spec:
     parentRefs:
     - kind: Gateway
       name: servicemesh-cloud-gw
       namespace: istio-ingress
     hostnames:
     - "where.example.com"
     rules:
     - matches:
       - headers:
         - name: version
           value: v2
       backendRefs:
       - name: whereami-v2
         port: 8080
     - backendRefs:
       - name: whereami-v1
         port: 8080
    
  6. Stellen Sie http-route.yaml in Ihrem Cluster bereit:

    kubectl apply -f http-route.yaml
    

    Diese HTTPRoute verweist auf servicemesh-cloud-gw. Das bedeutet, dass das Service Mesh-Cloud-Gateway so konfiguriert wird, dass das zugrunde liegende Cloud Service Mesh-Ingress-Gateway mit diesen Routingregeln konfiguriert wird. Die HTTPRoute hat dieselbe Funktion wie der Istio VirtualService, verwendet dazu aber die Kubernetes Gateway API. Da die Gateway API eine OSS-Spezifikation mit vielen zugrunde liegenden Implementierungen ist, ist sie die beste API, um das Routing über eine Kombination verschiedener Load Balancer (z. B. Cloud Service Mesh-Proxys und Load Balancer) hinweg zu definieren.

  7. Rufen Sie die IP-Adresse aus dem Gateway ab, damit Sie Traffic an die Anwendung senden können:

    VIP=$(kubectl get gateways.gateway.networking.k8s.io asm-gw-gke-servicemesh-cloud-gw -o=jsonpath="{.status.addresses[0].value}" -n istio-ingress)
    

    Die Ausgabe ist eine IP-Adresse.

    echo $VIP
    
    34.111.61.135
    
  8. Senden Sie Traffic an die Gateway-IP-Adresse, um zu prüfen, ob diese Einrichtung ordnungsgemäß funktioniert. Senden Sie eine Anfrage mit dem version: v2-Header und eine ohne, um zu prüfen, ob das Routing zwischen den beiden Anwendungsversionen korrekt erfolgt.

    curl ${VIP} -H "host: where.example.com"
    
    {
      "cluster_name": "gke1",
      "host_header": "where.example.com",
      "metadata": "whereami-v1",
      "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
      "pod_name": "whereami-v1-67d9c5d48b-zhr4l",
      "pod_name_emoji": "⚒",
      "project_id": "church-243723",
      "timestamp": "2021-02-08T18:55:01",
      "zone": "us-central1-a"
    }
    
    curl ${VIP} -H "host: where.example.com" -H "version: v2"
    
    {
      "cluster_name": "gke1",
      "host_header": "where.example.com",
      "metadata": "whereami-v2",
      "node_name": "gke-gke1-default-pool-9b3b5b18-hw5z.c.church-243723.internal",
      "pod_name": "whereami-v2-67d9c5d48b-zhr4l",
      "pod_name_emoji": "⚒",
      "project_id": "church-243723",
      "timestamp": "2021-02-08T18:55:01",
      "zone": "us-central1-a"
    }
    

Bereitstellung des Produktionsgateways

Im vorherigen Abschnitt wurde ein sehr einfaches Beispiel für ein Cloud-Gateway für Service Mesh gezeigt. Die folgenden Schritte bauen auf dem einfachen Beispiel auf und zeigen eine produktionsreife Einrichtung, die die Vorteile der Delegierung einiger Ingress-Routingfunktionen an den Load Balancer veranschaulicht.

Im folgenden Beispiel nehmen Sie das servicemesh-cloud-gw aus dem vorherigen Abschnitt und fügen die folgenden Funktionen hinzu, um ein sichereres und besser verwaltbares Gateway zu erstellen:

  • Stellen Sie das Gateway mit einer statischen IP-Adresse bereit, die auch bei Änderungen an der zugrunde liegenden Infrastruktur beibehalten wird.
  • Konvertieren Sie das Gateway, um HTTPS-Traffic mit einem selbst signierten Zertifikat zu empfangen.
  1. Erstellen Sie eine statische externe IP-Adresse. Eine statische IP-Adresse ist nützlich, da sich die zugrunde liegende Infrastruktur in Zukunft ändern kann, die IP-Adresse jedoch beibehalten werden kann.

    gcloud compute addresses create whereami-ip \
        --global \
        --project PROJECT_ID
    
  2. Erstellen Sie ein selbstsigniertes Zertifikat für die Domain where-example-com:

    openssl genrsa -out key.pem 2048
    cat <<EOF >ca.conf
    [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                = where.example.com
    [sans_list]
    DNS.1                     = where.example.com
    EOF
    
    openssl req -new -key key.pem \
        -out csr.pem \
        -config ca.conf
    
    openssl x509 -req \
        -signkey key.pem \
        -in csr.pem \
        -out cert.pem \
        -extfile ca.conf \
        -extensions extension_requirements \
        -days 365
    
    gcloud compute ssl-certificates create where-example-com \
        --certificate=cert.pem \
        --private-key=key.pem \
        --global \
        --project PROJECT_ID
    

    Es gibt viele Möglichkeiten, TLS-Zertifikate zu generieren. Sie können manuell über die Befehlszeile oder mit von Google verwalteten Zertifikaten generiert werden. Sie können auch intern mit dem PKI-System (Public-Key-Infrastructure) Ihres Unternehmens generiert werden. In diesem Beispiel wird manuell ein selbst signiertes Zertifikat generiert. Selbstsignierte Zertifikate werden in der Regel nicht für öffentliche Dienste verwendet, aber sie zeigen diese Konzepte leichter.

    Weitere Informationen zum Erstellen eines selbstsignierten Zertifikats über ein Kubernetes-Secret finden Sie unter Gateway sichern.

  3. Aktualisieren Sie gateway.yaml mit dem folgenden Manifest:

    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    spec:
      gatewayClassName: asm-l7-gxlb
      listeners:
      - name: http
        protocol: HTTP
        port: 80
        allowedRoutes:
          namespaces:
            from: All
      - name: https
        protocol: HTTPS
        port: 443
        allowedRoutes:
          namespaces:
            from: All
        tls:
          mode: Terminate
          options:
            networking.gke.io/pre-shared-certs: where-example-com
      addresses:
      - type: NamedAddress
        value: whereami-ip
    
  4. Stellen Sie das Gateway in Ihrem Cluster noch einmal bereit:

    kubectl apply -f gateway.yaml
    
  5. Rufen Sie die IP-Adresse der statischen IP-Adresse ab:

    VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")
    
  6. Verwenden Sie curl, um auf die Domain des Gateways zuzugreifen. Da DNS für diese Domain nicht konfiguriert ist, verwenden Sie die Option „--resolve“, um curl anzuweisen, den Domainnamen in die IP-Adresse des Gateways aufzulösen:

    curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v
    

    Nach Abschluss sieht die Ausgabe in etwa so aus:

    ...
    * TLSv1.2 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: O=example; CN=where.example.com
    *  start date: Apr 19 15:54:50 2021 GMT
    *  expire date: Apr 19 15:54:50 2022 GMT
    *  common name: where.example.com (matched)
    *  issuer: O=example; CN=where.example.com
    *  SSL certificate verify ok.
    ...
    {
      "cluster_name": "gke1",
      "host_header": "where.example.com",
      "metadata": "where-v1",
      "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
      "pod_name": "where-v1-84b47c7f58-tj5mn",
      "pod_name_emoji": "😍",
      "project_id": "agmsb-k8s",
      "timestamp": "2021-04-19T16:30:08",
      "zone": "us-west1-a"
    }
    

Die ausführliche Ausgabe enthält einen erfolgreichen TLS-Handshake, gefolgt von einer Antwort der Anwendung ähnlich der folgenden Ausgabe. So wird bestätigt, dass TLS am Gateway ordnungsgemäß beendet wird und die Anwendung sicher auf den Client antwortet.

Sie haben die folgende Architektur erfolgreich bereitgestellt:

ASM-Architektur

Die servicemesh-cloud-gw und ihre asm-l7-gxlb-GatewayClass haben einige interne Infrastrukturkomponenten abstrahiert, um die Nutzerfreundlichkeit zu verbessern. Cloud Load Balancing beendet TLS-Traffic mit einem internen Zertifikat und führt auch Systemdiagnosen für die Proxyebene des Cloud Service Mesh-Ingress-Gateways durch. Die in App & Routing Deployment bereitgestellte whereami-route konfiguriert die Cloud Service Mesh-Ingress-Gateway-Proxys, um Traffic an den richtigen im Mesh gehosteten Dienst weiterzuleiten.

Im folgenden Beispiel nehmen Sie das servicemesh-cloud-gw aus dem vorherigen Abschnitt und fügen die folgenden Funktionen hinzu, um ein sichereres und besser verwaltbares Gateway zu erstellen:

  • Stellen Sie das Gateway mit einer statischen IP-Adresse bereit, die auch bei Änderungen an der zugrunde liegenden Infrastruktur beibehalten wird.
  • Konvertieren Sie das Gateway, um HTTPS-Traffic mit einem selbst signierten Zertifikat zu empfangen.
  1. Erstellen Sie eine statische externe IP-Adresse. Eine statische IP-Adresse ist nützlich, da sich die zugrunde liegende Infrastruktur in Zukunft ändern kann, die IP-Adresse jedoch beibehalten werden kann.

    gcloud compute addresses create whereami-ip \
        --global \
        --project PROJECT_ID
    
  2. Erstellen Sie ein selbstsigniertes Zertifikat für die Domain where-example-com:

    openssl genrsa -out key.pem 2048
    cat <<EOF >ca.conf
    [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                = where.example.com
    [sans_list]
    DNS.1                     = where.example.com
    EOF
    
    openssl req -new -key key.pem \
        -out csr.pem \
        -config ca.conf
    
    openssl x509 -req \
        -signkey key.pem \
        -in csr.pem \
        -out cert.pem \
        -extfile ca.conf \
        -extensions extension_requirements \
        -days 365
    
    gcloud compute ssl-certificates create where-example-com \
        --certificate=cert.pem \
        --private-key=key.pem \
        --global \
        --project PROJECT_ID
    

    Es gibt viele Möglichkeiten, TLS-Zertifikate zu generieren. Sie können manuell über die Befehlszeile oder mit von Google verwalteten Zertifikaten generiert werden. Sie können auch intern mit dem PKI-System (Public-Key-Infrastructure) Ihres Unternehmens generiert werden. In diesem Beispiel wird manuell ein selbst signiertes Zertifikat generiert. Selbstsignierte Zertifikate werden in der Regel nicht für öffentliche Dienste verwendet, aber sie zeigen diese Konzepte leichter.

    Weitere Informationen zum Erstellen eines selbstsignierten Zertifikats über ein Kubernetes-Secret finden Sie unter Gateway sichern.

  3. Aktualisieren Sie gateway.yaml mit dem folgenden Manifest:

    kind: Gateway
    apiVersion: gateway.networking.k8s.io/v1beta1
    metadata:
      name: servicemesh-cloud-gw
      namespace: istio-ingress
    spec:
      gatewayClassName: asm-l7-gxlb
      listeners:
      - name: http
        protocol: HTTP
        port: 80
        allowedRoutes:
          namespaces:
            from: All
      - name: https
        protocol: HTTPS
        port: 443
        allowedRoutes:
          namespaces:
            from: All
        tls:
          mode: Terminate
          options:
            networking.gke.io/pre-shared-certs: where-example-com
      addresses:
      - type: NamedAddress
        value: whereami-ip
    
  4. Stellen Sie das Gateway in Ihrem Cluster noch einmal bereit:

    kubectl apply -f gateway.yaml
    
  5. Rufen Sie die IP-Adresse der statischen IP-Adresse ab:

    VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")
    
  6. Verwenden Sie curl, um auf die Domain des Gateways zuzugreifen. Da DNS für diese Domain nicht konfiguriert ist, verwenden Sie die Option „--resolve“, um curl anzuweisen, den Domainnamen in die IP-Adresse des Gateways aufzulösen:

    curl https://where.example.com --resolve where.example.com:443:${VIP} --cacert cert.pem -v
    

    Nach Abschluss sieht die Ausgabe in etwa so aus:

    ...
    * TLSv1.2 (OUT), TLS handshake, Client hello (1):
    * TLSv1.2 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (IN), TLS handshake, Finished (20):
    * SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
    * ALPN, server accepted to use h2
    * Server certificate:
    *  subject: O=example; CN=where.example.com
    *  start date: Apr 19 15:54:50 2021 GMT
    *  expire date: Apr 19 15:54:50 2022 GMT
    *  common name: where.example.com (matched)
    *  issuer: O=example; CN=where.example.com
    *  SSL certificate verify ok.
    ...
    {
      "cluster_name": "gke1",
      "host_header": "where.example.com",
      "metadata": "where-v1",
      "node_name": "gke-gw-default-pool-51ccbf30-yya8.c.agmsb-k8s.internal",
      "pod_name": "where-v1-84b47c7f58-tj5mn",
      "pod_name_emoji": "😍",
      "project_id": "agmsb-k8s",
      "timestamp": "2021-04-19T16:30:08",
      "zone": "us-west1-a"
    }
    

Die ausführliche Ausgabe enthält einen erfolgreichen TLS-Handshake, gefolgt von einer Antwort der Anwendung ähnlich der folgenden Ausgabe. So wird bestätigt, dass TLS am Gateway ordnungsgemäß beendet wird und die Anwendung sicher auf den Client antwortet.

Sie haben die folgende Architektur erfolgreich bereitgestellt:

ASM-Architektur

Die servicemesh-cloud-gw und ihre asm-l7-gxlb-GatewayClass haben einige interne Infrastrukturkomponenten abstrahiert, um die Nutzerfreundlichkeit zu verbessern. Cloud Load Balancing beendet TLS-Traffic mit einem internen Zertifikat und führt auch Systemdiagnosen für die Proxyebene des Cloud Service Mesh-Ingress-Gateways durch. Die in App & Routing Deployment bereitgestellte whereami-route konfiguriert die Cloud Service Mesh-Ingress-Gateway-Proxys, um Traffic an den richtigen im Mesh gehosteten Dienst weiterzuleiten.

Nächste Schritte