Anthos Service Mesh und Traffic Director heißen jetzt Cloud Service Mesh. Weitere Informationen finden Sie in der Cloud Service Mesh-Übersicht.

Diese Seite wurde von der Cloud Translation API übersetzt.

Klassischen Application Load Balancer für Cloud Service Mesh konfigurieren

Übersicht

Dieses Dokument richtet sich an Nutzer von Cloud Service Mesh, die die verwaltete Istio-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 verwalteten Cloud Service Mesh-Steuerungsebene eingerichtet. Die in diesem Dokument beschriebene Konfiguration kann nicht mit der verwalteten Steuerungsebene von Cloud Service Mesh verwendet werden.

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 gleichzeitig über die Kubernetes Gateway API mit Cloud Load Balancing zu konfigurieren.

Diagramm, das einen Load Balancer mit Cloud Service Mesh zeigt

Im Vergleich zu unserer vorherigen Anleitung Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen kann dieses Modell mit dem Service Mesh Cloud Gateway jetzt über eine Kubernetes Gateway-Ressource bereitgestellt werden, was die Bereitstellung von Cloud- und clustergehostetem Load Balancing zusammen 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 globale externe Application Load Balancer (manchmal auch Advanced Load Balancer genannt) 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 prü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 Balancer.
Wenn Cloud Service Mesh GatewayClasses aus einem Cluster gelöscht werden, werden sie nicht automatisch neu installiert. Dies hat jedoch keine Auswirkungen auf die Nutzerfreundlichkeit der Funktion.
Die Logik zum Abgleichen von Routen entspricht nicht den Gateway API-Spezifikationen und erfolgt stattdessen in der Reihenfolge der HTTPRoute. In zukünftigen Versionen wird dies geändert, um den Gateway API-Spezifikationen zu entsprechen.

Voraussetzungen

Verwaltetes Cloud 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 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 Mesh mit einem Cluster bereitstellen

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

Gateway API mit verwaltetem Cloud Service Mesh aktivieren

Aktivieren Sie die Gateway API in Ihrem Cluster. Der GKE-Cluster muss Version 1.24 oder höher haben.
Installieren Sie verwaltetes Cloud Service Mesh mit rapid oder regular als Release-Kanal.

Gateway-Ressource bereitstellen

Wenn Sie ein Service Mesh Cloud-Gateway bereitstellen, 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-Gateway bereitgestellt werden können.

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

Stellen Sie die GatewayClass in Ihrem Cluster bereit:
```
kubectl apply -f l7-gateway-class.yaml
```
Prüfen Sie nach der Installation, ob die GatewayClass 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 sehen, prüfen Sie, ob Sie die Voraussetzungen 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.
Erstellen Sie einen speziellen Namespace für Ihr Service Mesh-Cloud-Gateway:
```
kubectl create namespace istio-ingress
```

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

Stellen Sie das Gateway in Ihrem Cluster im Namespace „istio-ingress“ bereit:
```
kubectl apply -f gateway.yaml
```

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, geschieht 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, enthält es die IP-Adresse und die Namen der erstellten Compute Engine-Load Balancer-Ressourcen.
Im Namespace „istio-ingress“ wird ein Cloud Service Mesh-Ingress-Gateway-Deployment 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 zum Akzeptieren von Internet-Traffic in Ihrem Mesh erforderlich ist. Beachten Sie, dass dies die einfachste mögliche Gateway-Bereitstellung ist. In den folgenden Abschnitten fügen Sie zusätzliche Richtlinien und Funktionen hinzu, damit die Anwendung für die Produktion bereit ist.

App- und Routingbereitstellung

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

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

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-Daten zur Identität und zum Standort ausgibt. Sie stellen zwei verschiedene Versionen davon bereit.

Erstellen Sie die Dienste und Deployments:
```
kubectl apply -f whereami.yaml
```
Sobald die Einrichtung abgeschlossen ist, werden in Ihrem Cluster vier „whereami“-Pods ausgeführt.

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

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

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 es das zugrunde liegende Cloud Service Mesh-Ingress-Gateway mit diesen Routingregeln konfiguriert. Die HTTPRoute erfüllt dieselbe Funktion wie der Istio VirtualService, verwendet jedoch die Kubernetes Gateway API. Da die Gateway API eine OSS-Spezifikation mit vielen zugrunde liegenden Implementierungen ist, eignet sie sich am besten, um das Routing über eine Kombination verschiedener Load Balancer (z. B. Cloud Service Mesh-Proxys und Load Balancer) zu definieren.

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

Senden Sie Traffic an die Gateway-IP-Adresse, um zu prüfen, ob diese Konfiguration ordnungsgemäß funktioniert. Senden Sie eine Anfrage mit und eine ohne version: v2-Header, um festzustellen, ob die Weiterleitung 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"
}

Produktions-Gateway-Bereitstellung

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 der Deaktivierung einiger der Ingress-Routingfunktionen an den Load Balancer veranschaulicht.

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

Das Gateway mit einer statischen IP-Adresse bereitstellen, die auch bei Änderungen an der zugrunde liegenden Infrastruktur erhalten bleibt
Konvertieren Sie das Gateway so, dass es HTTPS-Traffic mit einem selbst signierten Zertifikat empfängt.

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
```

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 ü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 selbst signierten Zertifikats über ein Kubernetes-Secret finden Sie unter Gateway sichern.

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

Stellen Sie das Gateway in Ihrem Cluster neu bereit:
```
kubectl apply -f gateway.yaml
```

Rufen Sie die IP-Adresse der statischen IP-Adresse ab:

VIP=$(gcloud compute addresses describe whereami-ip --global --format="value(address)")

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

Bei servicemesh-cloud-gw und seiner GatewayClass asm-l7-gxlb wurden einige interne Infrastrukturkomponenten abstrahiert, um die Nutzerfreundlichkeit zu verbessern. Der Cloud Load Balancer beendet TLS-Traffic mit einem internen Zertifikat und führt außerdem eine Systemdiagnose der Cloud Service Mesh-Ingress-Gateway-Proxy-Ebene durch. Mit dem whereami-route, das in App- und Routingbereitstellung bereitgestellt wird, werden die Cloud Service Mesh-Ingress-Gateway-Proxys so konfiguriert, dass der Traffic an den richtigen im Mesh gehosteten Dienst weitergeleitet wird.

Das Gateway mit einer statischen IP-Adresse bereitstellen, die auch bei Änderungen an der zugrunde liegenden Infrastruktur erhalten bleibt
Konvertieren Sie das Gateway so, dass es HTTPS-Traffic mit einem selbst signierten Zertifikat empfängt.

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
```