Externes HTTP(S)-Load-Balancing für verwaltetes Anthos Service Mesh konfigurieren

Vorschau — service mesh cloud gateway

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Überblick

Cloud Load Balancing bietet viele von der Cloud verwaltete Edge-Funktionen, darunter globales Anycast-Load-Balancing, von Google verwaltete Zertifikate, Identitäts- und Zugriffsverwaltung sowie Cloud-Firewall oder IDS. Anthos 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 Anthos Service Mesh-Ingress-Gateway mit Cloud Load Balancing gleichzeitig über die Kubernetes Gateway API zu konfigurieren.

Im Vergleich zum vorherigen Nutzerhandbuch Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen mit einem Service Mesh-Cloud-Gateway kann dieses Modell jetzt über eine Kubernetes-Gateway-Ressource bereitgestellt werden. Dadurch wird die gemeinsame Bereitstellung von Cloud- und clustergehostetem Load-Balancing vereinfacht.

Vorschau Einschränkungen

Für die Vorabversion dieser Funktion 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 erweiterte und interne HTTP(S)-Load-Balancer werden nicht unterstützt.
• Traffic zwischen dem externen HTTP(S)-Load-Balancer und dem Anthos Service Mesh-Ingress-Gateway wird mit TLS verschlüsselt. Der externe HTTP(S)-Load-Balancer prüft jedoch nicht das vom Anthos Service Mesh-Ingress-Gateway bereitgestellte Zertifikat. Diese Einschränkung gilt für alle Nutzer des Google Cloud HTTP(S)-Load-Balancers.
• Wenn Anthos Service Mesh-GatewayClasses aus einem Cluster gelöscht werden, werden sie nicht automatisch neu installiert. Dies wirkt sich jedoch nicht auf die Nutzung der Funktion aus.
• Die Logik für den Routenabgleich entspricht nicht den Gateway API-Spezifikationen und erfolgt in der Reihenfolge der HTTPRoute. Dies wird in zukünftigen Versionen geändert, sodass die Gateway API-Spezifikationen eingehalten werden.

Voraussetzungen

• Verwaltetes Anthos Service Mesh, das in einem GKE-Cluster (Google Kubernetes Engine) mit Version 1.24 oder höher installiert ist. Andere GKE Enterprise-Cluster werden nicht unterstützt.
• Nur Kubernetes Gateway API 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 wird beschrieben, wie Sie eine Kubernetes-Gateway-Ressource bereitstellen, die einen globalen externen HTTP(S)-Load-Balancer (klassisch) und ein Anthos Service Mesh-Ingress-Gateway bereitstellt.

Gateway API mit verwaltetem Anthos Service Mesh aktivieren

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

2. Installieren Sie das verwaltete Anthos Service Mesh mit rapid oder regular als Release-Version.

Gateway-Ressource bereitstellen

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

Weitere Informationen zu den Unterschieden finden Sie unter Kubernetes-Gateways und Istio-Gateways. Jedes Kubernetes-Gateway hat eine GatewayClass, die seinen Typ und inhärente Funktionen angibt. Das Service-Mesh-Cloud-Gateway hat eine GatewayClass, die sowohl Cloud Load Balancing als auch das Anthos Service Mesh-Ingress-Gateway bereitstellen kann.

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 GatewayClass in Ihrem Cluster bereit:

   kubectl apply -f l7-gateway-class.yaml
   

3. Prüfen Sie, ob 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 sind. Wenn die erwartete Ausgabe nicht angezeigt wird, prüfen Sie, ob die Voraussetzungen korrekt erfüllt sind.

   Außerdem wird die folgende GatewayClass angezeigt:

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

   Damit wird der zugrunde liegende globale externe HTTP(S)-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 istio-Ingress-Namespace 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
   

Bei der Bereitstellung dieses Kubernetes Gateway API-Objekts geschieht Folgendes:

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

Warnung: Derzeit ist mindestens eine Arbeitslast mit Sidecar-Datei erforderlich, damit das Anthos Service Mesh-Ingress-Gateway ordnungsgemäß funktioniert.

Sie haben jetzt die vollständige Infrastruktur, die erforderlich ist, um Internet-Traffic in Ihr Mesh-Netzwerk aufzunehmen. Beachten Sie, dass dies die einfachste Gateway-Bereitstellung ist. In den folgenden Abschnitten fügen Sie zusätzliche Richtlinien und Funktionen hinzu, um das Produkt produktionsreif zu machen.

Anwendungs- und Routingbereitstellung

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

1. Fügen Sie dem Namespace default Labels 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.2.20
           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.2.20
           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 werden zwei verschiedene Versionen davon bereitstellen.

3. Erstellen Sie die Dienste und Bereitstellungen:

   kubectl apply -f whereami.yaml
   

   Sobald es betriebsbereit ist, werden vier Pods in Ihrem Cluster ausgeführt.

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 das folgende 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 HTTP-Route verweist auf servicemesh-cloud-gw. Das bedeutet, dass das Service Mesh-Cloud-Gateway so konfiguriert wird, dass das zugrunde liegende Anthos Service Mesh-Ingress-Gateway mit diesen Routingregeln konfiguriert wird. Die HTTPRoute führt dieselbe Funktion wie der Istio VirtualService aus, verwendet dazu jedoch die Kubernetes Gateway API. Da die Gateway API eine OSS-Spezifikation mit vielen zugrunde liegenden Implementierungen ist, eignet sie sich am besten für die Definition des Routings über eine Kombination verschiedener Load-Balancer (z. B. Anthos Service Mesh-Proxys und Cloud Load Balancer).

7. Rufen Sie die IP-Adresse aus dem Gateway ab, damit Sie Traffic an Ihre 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 korrekt funktioniert. Senden Sie eine Anfrage mit dem Header version: v2 und eine ohne, um festzustellen, ob das Routing über die beiden Anwendungsversionen hinweg korrekt erfolgt.

   Hinweis: Dies kann bis zu 10 Minuten dauern. Während des Wartens wird die Fehlermeldung Empty reply from server oder Connection reset by peer angezeigt.

   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 Service Mesh-Cloud-Gateway gezeigt. Die folgenden Schritte bauen auf dem einfachen Beispiel auf und zeigen eine produktionsreife Einrichtung, die die Vorteile des Delegierens eines Teils der Funktionen für das Routing von eingehendem Traffic an den Cloud-Load-Balancer veranschaulicht.

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

• Stellen Sie das Gateway mit einer statischen IP-Adresse bereit, die auch dann beibehalten wird, wenn sich die zugrunde liegende Infrastruktur ändert.
• Konvertieren Sie das Gateway so, dass es HTTPS-Traffic mit einem selbst signierten Zertifikat empfängt.

Hinweis: Dieses Beispiel baut auf der Gateway-Bereitstellung auf. Da sich jedoch der Port und das Protokoll des Gateways geändert haben, unterbrechen diese Schritte den Traffic, der an Ihr Gateway an Port 80 gesendet wird. In jedem realistischen Szenario ist es unwahrscheinlich, dass sich der Front-End-Port Ihres Gateways ändert.

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 selbst signiertes 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 in der Befehlszeile oder mit von Google verwalteten Zertifikaten generiert werden oder intern über die Public-Key-Infrastruktur (PKI) Ihres Unternehmens generiert werden. In diesem Beispiel generieren Sie manuell ein selbst signiertes Zertifikat. Selbstsignierte Zertifikate werden normalerweise nicht für öffentliche Dienste verwendet, können diese Konzepte aber leichter demonstriert werden.

   Weitere Informationen zum Erstellen eines selbst signierten Zertifikats mit 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 noch einmal in Ihrem Cluster 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, können Sie curl mit der Option "--resolve" anweisen, 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
   

   Hinweis: Dies kann bis zu 10 Minuten dauern. Während des Wartens wird der Fehler error:0A000126:SSL routines::unexpected eof while reading angezeigt.

   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, wie in der folgenden Ausgabe. Dadurch wird bestätigt, dass TLS am Gateway korrekt beendet wird und dass die Anwendung sicher auf dem Client reagiert.

Sie haben die folgende Architektur bereitgestellt:

Das servicemesh-cloud-gw und seine asm-l7-gxlb GatewayClass haben einige interne Infrastrukturkomponenten abstrahiert, um die Nutzung zu vereinfachen. Cloud Load Balancing beendet TLS-Traffic mit einem internen Zertifikat und seine Systemdiagnose auf der Proxyebene des Anthos Service Mesh-Ingress-Gateways. Die in der App- und Routing-Bereitstellung bereitgestellte whereami-route konfiguriert die Ingress-Gateway-Proxys von Anthos Service Mesh so, dass Traffic an den richtigen, vom Mesh gehosteten Dienst weitergeleitet wird.

Nächste Schritte

• Weitere Informationen zur Implementierung der Kubernetes Gateway API in der Google Kubernetes Engine (GKE).
• Optionale Features von verwaltetem Anthos Service Mesh aktivieren