Klassischen Application Load Balancer für Cloud Service Mesh konfigurieren

Übersicht

Dieses Dokument richtet sich an Sie, wenn Sie Cloud Service Mesh-Nutzer sind und der verwalteten Istiod-Steuerungsebene und Sie möchten den klassischen Application Load Balancer als Gateway für eingehenden Traffic. Der klassische Application Load Balancer auch als klassischer externer Application Load Balancer bezeichnet.

Verwenden Sie dieses Dokument nicht, wenn Sie ein neuer Cloud Service Mesh-Nutzer sind. Neu -Nutzer werden automatisch mit der von Cloud Service Mesh verwalteten Steuerungsebene eingerichtet. Ich kann die in diesem Dokument beschriebene Konfiguration nicht mit dem Von Cloud Service Mesh verwaltete Steuerungsebene

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 Mesh-Ingress-Modell. Das Service Mesh-Cloud-Gateway bietet eine einheitliche Möglichkeit, Cloud Service Mesh-Ingress-Gateway mit Cloud Load Balancing konfigurieren gleichzeitig über die Kubernetes Gateway API.

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 clusterbasiertem 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 sind nicht unterstützt.
  • Nur der klassische Application Load Balancer wird unterstützt. Globalen externen Application Load Balancer (auch Advanced Load Balancer genannt) und interner 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 das vom Cloud Service Mesh-Ingress-Gateway bereitgestellte Zertifikat nicht verifiziert. Dieses Einschränkung gilt für alle Nutzer des Google Cloud HTTP(S)-Load-Balancers.
  • 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 installiert in einem GKE-Cluster (Google Kubernetes Engine) mit Version 1.24 oder höher. Sonstiges GKE Enterprise-Cluster werden nicht unterstützt.
  • Nur Version v1beta1 der Kubernetes Gateway API.

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 Bereitgestellte Kubernetes Gateway-Ressource einen klassischen Application Load Balancer und ein Cloud Service Mesh-Ingress-Gateway.

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 verwaltetes Cloud Service Mesh mit rapid oder regular als Release-Version.

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. Beachten Sie, dass Kubernetes Gateway-Ressourcen sind anders als 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 inhärente Funktionen. Service Mesh Cloud Gateway hat eine GatewayClass mit Cloud Load Balancing und das Cloud Service Mesh-Ingress-Gateway bereitstellen.

  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 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 sind. Wenn Sie nicht die erwartete Ausgabe sehen, prüfen Sie, ob Sie die Voraussetzungen erfüllt haben.

    Außerdem sehen Sie die folgende GatewayClass:

    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, geschieht Folgendes:

  • Ein externer HTTP(S)-Load-Balancer wird bereitgestellt und konfiguriert. Es kann einige Minuten dauern, aber wenn dies der Fall ist, zeigt das Gateway die IP-Adresse und wird mit den Namen des Compute Engine-Load-Balancers annotiert die erstellten Ressourcen.
  • Ein Cloud Service Mesh-Ingress-Gateway-Deployment wird in istio-ingress erstellt -Namespace auf sie zugegriffen werden. Dadurch werden die Envoy-Proxy-Instanzen erstellt, die Traffic vom Load Balancer empfangen.
  • Der Load-Balancer verschlüsselt und leitet den gesamten Traffic Cloud Service Mesh-Ingress-Gateway.

Sie verfügen jetzt über die komplette Infrastruktur, die erforderlich ist, um Internet-Traffic in Ihre Mesh-Netzwerk. Dies ist die die einfachste Möglichkeit zur Gateway-Bereitstellung. In den folgenden Abschnitten zusätzliche Richtlinien und Funktionen, die es für die Produktion bereit machen.

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.

  1. Fügen Sie dem default-Namespace 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.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-Daten zur Identität und zum Standort ausgibt. Sie stellen zwei verschiedene Versionen davon bereit.

  3. Erstellen Sie die Dienste und Deployments:

    kubectl apply -f whereami.yaml

    Sobald er ausgeführt wird, werden vier Woami-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 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 es das zugrunde liegende Cloud Service Mesh-Ingress-Gateway mit diesen Routingregeln konfiguriert. Die HTTP-Route hat dieselbe Leistung, funktioniert als Istio VirtualService, verwendet jedoch die Kubernetes Gateway API, tun Sie dies. Da es sich bei der Gateway API um eine OSS-Spezifikation mit vielen zugrunde liegenden eignet sich diese API am besten zum Definieren des Routings Kombination verschiedener Load-Balancer (z. B. Cloud Service Mesh-Proxys und Load-Balancer).

  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 Konfiguration ordnungsgemäß funktioniert. Senden Sie eine Anfrage mit dem version: v2-Header und eine ohne ob das Routing in den beiden Anwendungsversionen korrekt durchgeführt wird.

    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. dem die Vorteile des Delegierens eines Teils des Ingress-Routings des klassischen Application Load Balancers.

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. Ich kann die in diesem Dokument beschriebene Konfiguration nicht mit dem Von Cloud Service Mesh verwaltete Steuerungsebene

Cloud Load Balancing bietet viele in der Cloud verwaltete Edge-Geräte einschließlich globalem Anycast-Load-Balancing, von Google verwaltet 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 clusterbasiertem 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. Globalen externen Application Load Balancer (auch Advanced Load Balancer genannt) und interner Application Load Balancer werden nicht unterstützt.
  • Traffic zwischen dem klassischen Application Load Balancer und dem eingehenden Cloud Service Mesh-Traffic Gateway 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 Balancern.
  • Wenn Cloud Service Mesh GatewayClasses aus einem Cluster gelöscht wird, gilt Folgendes: werden 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 Google Kubernetes Engine (GKE)-Cluster mit Version 1.24 oder höher installiert ist. Sonstiges GKE Enterprise-Cluster werden nicht unterstützt.
  • Nur Version v1beta1 der Kubernetes Gateway API.

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

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

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

Gateway-Ressource bereitstellen

Beim Bereitstellen des Service Mesh-Cloud-Gateways Gateway-Ressourcen werden zum Bereitstellen von Cloud Load Balancing und Cloud Service Mesh verwendet Ingress-Gateway in einem Schritt auszuführen. Beachten Sie, dass Kubernetes Gateway-Ressourcen sind anders als 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 inhärente Funktionen. Service Mesh Cloud Gateway hat eine GatewayClass mit Cloud Load Balancing und das Cloud Service Mesh-Ingress-Gateway bereitstellen.

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

  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, geschieht Folgendes:

  • Ein externer HTTP(S)-Load-Balancer wird bereitgestellt und konfiguriert. Es kann einige Minuten dauern, aber wenn dies der Fall ist, zeigt das Gateway die IP-Adresse und wird mit den Namen des Compute Engine-Load-Balancers annotiert die erstellten Ressourcen.
  • Ein Cloud Service Mesh-Ingress-Gateway-Deployment wird in istio-ingress erstellt -Namespace auf sie zugegriffen werden. Dadurch werden die Envoy-Proxy-Instanzen erstellt, die Traffic vom Load Balancer empfangen.
  • Der Load-Balancer verschlüsselt und leitet den gesamten Traffic Cloud Service Mesh-Ingress-Gateway.

Sie verfügen jetzt über die komplette Infrastruktur, die erforderlich ist, um Internet-Traffic in Ihre Mesh-Netzwerk. Dies ist die die einfachste Möglichkeit zur Gateway-Bereitstellung. In den folgenden Abschnitten zusätzliche Richtlinien und Funktionen, die es für die Produktion bereit machen.

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.

  1. Fügen Sie dem default-Namespace 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.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-Daten zur Identität und zum Standort ausgibt. Sie stellen zwei verschiedene Versionen davon bereit.

  3. Erstellen Sie die Dienste und Deployments:

    kubectl apply -f whereami.yaml

    Sobald er ausgeführt wird, werden vier Woami-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 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 es das zugrunde liegende Cloud Service Mesh-Ingress-Gateway mit diesen Routingregeln konfiguriert. Die HTTP-Route hat dieselbe Leistung, funktioniert als Istio VirtualService, verwendet jedoch die Kubernetes Gateway API, tun Sie dies. Da es sich bei der Gateway API um eine OSS-Spezifikation mit vielen zugrunde liegenden eignet sich diese API am besten zum Definieren des Routings Kombination verschiedener Load-Balancer (z. B. Cloud Service Mesh-Proxys und Load-Balancer).

  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 Konfiguration ordnungsgemäß funktioniert. Senden Sie eine Anfrage mit dem version: v2-Header und eine ohne ob das Routing in den beiden Anwendungsversionen korrekt durchgeführt wird.

    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. dem die Vorteile des Delegierens eines Teils des Ingress-Routings Funktionalität für den Load-Balancer.

Im folgenden Beispiel nehmen Sie den servicemesh-cloud-gw aus der vorherigen Abschnitt und fügen die folgenden Funktionen hinzu, um eine sicherere und verwaltbares Gateway:

  • Stellen Sie das Gateway mit einer statischen IP-Adresse bereit, die beibehalten wird, selbst wenn das Änderungen an der zugrunde liegenden Infrastruktur.
  • 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-Infrastruktur) Ihres Unternehmens generiert werden. In diesem Beispiel generieren Sie manuell ein selbst signiertes Zertifikat. 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 finden Sie über Kubernetes-Secret, siehe 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 im Cluster bereit:

    kubectl apply -f gateway.yaml

  5. Rufen Sie die IP-Adresse der statischen IP 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

    Anschließend 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. Cloud Load Balancing beendet TLS-Traffic mit einem internen Zertifikat und die Systemdiagnose der Proxy-Ebene des Cloud Service Mesh-Ingress-Gateways. Die whereami-route bereitgestellt in App- und Routingbereitstellung konfiguriert die Ingress-Gateway-Proxys von Cloud Service Mesh, um Traffic an die richtige einem Mesh-gehosteten Dienst.

Im folgenden Beispiel nehmen Sie den servicemesh-cloud-gw aus der vorherigen Abschnitt und fügen die folgenden Funktionen hinzu, um eine sicherere und verwaltbares Gateway:

  • Stellen Sie das Gateway mit einer statischen IP-Adresse bereit, die beibehalten wird, selbst wenn das Änderungen an der zugrunde liegenden Infrastruktur.
  • 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-Infrastruktur) Ihres Unternehmens generiert werden. In diesem Beispiel wird manuell ein selbst signiertes Zertifikat generiert. Selbstsignierte Zertifikate werden für öffentliche Dienste können diese Konzepte leichter veranschaulicht werden.

    Weitere Informationen zum Erstellen eines selbst signierten 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 noch einmal im Cluster bereit:

    kubectl apply -f gateway.yaml

  5. Rufen Sie die IP-Adresse der statischen IP 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

Das servicemesh-cloud-gw und seine GatewayClass asm-l7-gxlb wurden abstrahiert. einige interne Infrastrukturkomponenten entfernt, um die Nutzung zu vereinfachen. 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.

Nächste Schritte