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

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

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, 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.
Erstellen Sie einen dedizierten 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, 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.

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 ausgibt, um ihre Identität und ihren Standort anzugeben. Sie stellen zwei verschiedene Versionen bereit.

Erstellen Sie die Services und Deployments:
```
kubectl apply -f whereami.yaml
```
Sobald sie ausgeführt werden, sind vier „whereami“-Pods in Ihrem Cluster aktiv.

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

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

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

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 noch einmal 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

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.