Von Edge zu Mesh: Service Mesh-Anwendungen über GKE Ingress verfügbar machen

Last reviewed 2022-09-29 UTC

In dieser Anleitung erfahren Sie, wie Sie Anthos Service Mesh mit Cloud Load Balancing kombinieren, um Anwendungen in einem Service Mesh mit Internetclients freizugeben.

Anthos Service Mesh ist ein auf Istio basierendes verwaltetes Service Mesh mit einer sicheren, beobachtbaren und standardisierten Kommunikationsebene für Anwendungen. Es ist unerheblich, ob Sie Anthos Service Mesh, Traffic Director oder Istio verwenden: Ein Service Mesh bietet eine ganzheitliche Kommunikationsplattform für Clients, die im Mesh-Netzwerk kommunizieren. Eine Herausforderung besteht jedoch weiterhin darin, Clients, die sich außerhalb des Mesh-Netzwerks befinden, mit Anwendungen zu verbinden, die im Mesh gehostet werden.

Sie können eine Anwendung je nach Standort des Clients für verschiedene Clients bereitstellen. In dieser Anleitung erfahren Sie, wie Sie eine Anwendung für Clients verfügbar machen, indem Sie Cloud Load Balancing mit Anthos Service Mesh kombinieren, um Load-Balancing in ein Service Mesh zu integrieren. Diese Anleitung richtet sich an fortgeschrittene Fachkräfte, die Anthos Service Mesh ausführen. Sie ist aber auch für Istio in Google Kubernetes Engine hilfreich.

Mesh-Ingress-Gateway

Istio 0.8 hat das Mesh-Ingress-Gateway eingeführt. Es bietet einen dedizierten Satz von Proxys, deren Ports für Traffic von außerhalb des Service Mesh freigegeben werden. Mit diesen Mesh-Ingress-Proxys können Sie das L4-Bereitstellungsverhalten getrennt vom Routing der Anwendung steuern. Mit den Proxys können Sie außerdem Routing und Richtlinien auf externen Mesh-Traffic anwenden, bevor er am Anwendungs-Sidecar eingeht. Beim Mesh-Ingress wird die Handhabung des Traffics festgelegt, wenn er einen Knoten im Mesh-Netzwerk erreicht. Externe Komponenten müssen jedoch festlegen, wie der Traffic zuerst im Mesh-Netzwerk ankommt.

Zum Verwalten des externen Traffics benötigen Sie einen Load-Balancer außerhalb des Mesh-Netzwerks. In dieser Anleitung wird Google Cloud Load Balancing verwendet, das über GKE-Ingress-Ressourcen bereitgestellt wird, um das Deployment zu automatisieren. Das kanonische Beispiel dieser Einrichtung ist ein externer Load-Balancing-Dienst, der im Fall von Google Cloud einen öffentlichen TCP/UDP-Load-Balancer bereitstellt. Dieser Load-Balancer verweist auf die NodePorts eines GKE-Clusters. Sie stellen die Istio-Ingress-Gateway-Pods zur Verfügung, die den Traffic zu nachgeschalteten Mesh-Sidecar-Proxys leiten. Das folgende Diagramm veranschaulicht diese Topologie. Das Load-Balancing für internen privaten Traffic ähnelt dieser Architektur, mit der Ausnahme, dass Sie stattdessen einen internen TCP/UDP-Load-Balancer bereitstellen.

Ein externer Load-Balancer leitet externe Clients über Ingress-Gateway-Proxys an das Mesh weiter.

Die Verwendung des transparenten Load-Balancings L4 mit einem Mesh-Ingress-Gateway bietet folgende Vorteile:

  • Diese Einrichtung vereinfacht die Bereitstellung des Load-Balancers.
  • Dieser bietet eine stabile virtuelle IP-Adresse (VIP), Systemdiagnose und zuverlässige Traffic-Verteilung, wenn Clusteränderungen, Knotenausfälle oder Prozessausfälle auftreten.
  • Alle Routingregeln, die TLS-Beendigung und die Trafficrichtlinie werden an einem einzigen Standort am Mesh-Ingress-Gateway verwaltet.

GKE Ingress und Dienste

Sie können Zugriff auf Anwendungen für Clients außerhalb des Clusters auf verschiedene Arten bereitstellen. In der folgenden Tabelle sind die Kubernetes-Primitive aufgeführt, die für die Bereitstellung von Load-Balancern in Google Cloud verfügbar sind. Welche Art von Load-Balancer Sie verwenden, um Anwendungen für Clients freizugeben, hängt weitgehend davon ab, ob die Clients extern oder intern sind, welche Art von Protokollunterstützung erforderlich ist und ob das Service Mesh mehrere GKE-Cluster umfasst oder sich in einem einzelnen Cluster befindet.

Alle Load-Balancer-Typen in der folgenden Tabelle können abhängig vom Anwendungsfall mit dem Mesh-Netzwerk gehostete Anwendungen verfügbar machen.

GKE-Ressource Cloudbasierter Load-Balancer Merkmale
Ingress für externe HTTP(S)-Load-Balancer Externer HTTP(S)-Load-Balancer

L7-Proxys in Edge-Points of Presence (PoPs) von Google

Öffentlicher VIP

Globaler Geltungsbereich

Einzelner Cluster
Ingress für interne HTTP(S)-Load-Balancer Interner HTTP(S)-Load-Balancer

L7-Proxys in einem Virtual Private Cloud-Netzwerk (VPC)

Privater VIP

Regionaler Geltungsbereich

Einzelner Cluster
Externer LoadBalancer-Dienst Netzwerk-Load-Balancer

L4-Passthrough an Google Edge-PoPs

Öffentlicher VIP

Regionaler Geltungsbereich

Einzelner Cluster
Interner LoadBalancer-Dienst Interne TCP/UDP-Load-Balancer

L4-Passthrough im VPC-Routing-Netzwerk

Privater VIP

Regionaler Geltungsbereich

Einzelner Cluster
Multi-Cluster-Ingress (Multi-Cluster, externer Ingress) Externer HTTP(S)-Load-Balancer

L7-Proxys in Google Edge-PoPs

Öffentlicher VIP

Globaler Geltungsbereich

Multi-Cluster

Obwohl der Standard-Load-Balancer für Anthos Service Mesh der externe TCP/UDP-Load-Balancer ist, konzentriert sich diese Anleitung auf den externen HTTP(S)-Load-Balancer. Der externe HTTP(S)-Load-Balancer ermöglicht die Integration mit Edge-Diensten wie Identity-Aware Proxy (IAP), Google Cloud Armor und Cloud CDN sowie einem global verteilten Netzwerk von Edge-Proxys. Im nächsten Abschnitt werden die Architektur und die Vorteile der Verwendung von zwei Ebenen des HTTP-Load-Balancing beschrieben.

Cloud-Ingress und Mesh-Ingress

Das Bereitstellen eines externen L7-Load-Balancing außerhalb des Mesh-Netzwerks mit einer Mesh-Ingress-Ebene bietet entscheidende Vorteile, insbesondere für Internet-Traffic. Obwohl Anthos Service Mesh und Istio-Ingress-Gateways eine erweiterte Routing- und Trafficverwaltung im Mesh ermöglichen, sind einige Funktionen am Netzwerkrand besser geeignet. Die Nutzung der Vorteile eines Internet-Edge-Netzwerks durch den externen HTTP(S)-Load-Balancer von Google Cloud könnte erhebliche Vorteile in Bezug auf die Leistung, Zuverlässigkeit oder Sicherheit gegenüber dem meshbasierten Ingress bieten. Zu diesen Vorteilen gehören:

Diese externe Ebene des L7-Load-Balancing wird als Cloud-Ingress bezeichnet, da sie auf von Cloud verwalteten Load-Balancern und nicht auf selbstverwalteten Proxys basiert, die von Mesh-Ingress verwendet werden. Die Kombination aus Cloud-Ingress und Mesh-Ingress nutzt ergänzende Funktionen der Google Cloud-Infrastruktur und des Mesh-Netzwerks. Das folgende Diagramm zeigt, wie Sie Cloud-Ingress und Mesh-Ingress als zwei Load-Balancing-Ebenen für den Internet-Traffic kombinieren können.

Cloud-Ingress fungiert als Gateway für externen Traffic zum Mesh über das VPC-Netzwerk.

Bei dieser Topologie erfasst die Cloud-Ingress-Ebene Traffic von außerhalb des Service Mesh und leitet diesen Traffic an die Mesh-Ingress-Ebene. Die Mesh-Ingress-Ebene leitet dann den Traffic an die mit dem Mesh-Netzwerk gehosteten Anwendungs-Back-Ends weiter.

Cloud- und Mesh-Ingress-Topologie

In diesem Abschnitt werden die zusätzlichen Rollen beschrieben, die jede Ingress-Ebene erfüllt, wenn Sie sie gemeinsam verwenden. Diese Rollen sind keine konkreten Regeln, sondern Richtlinien, die die Vorteile der einzelnen Ebenen nutzen. Je nach Anwendungsfall sind verschiedene Varianten dieses Musters wahrscheinlich.

  • Cloud-Ingress: In Kombination mit Mesh-Ingress wird die Cloud-Ingress-Ebene am besten für Edge-Sicherheit und globales Load-Balancing verwendet. Da die Cloud-Ingress-Ebene in den DDoS-Schutz integriert ist, sind Cloud-Firewalls, Authentifizierungs- und Verschlüsselungsprodukte am Netzwerkrand sehr gut geeignet, um diese Dienste außerhalb des Mesh-Netzwerks auszuführen. Die Routinglogik ist in der Regel in dieser Ebene sehr einfach. Die Logik kann jedoch für Multi-Cluster- und Multi-Region-Umgebungen komplexer sein. Aufgrund der entscheidenden Funktion von Load-Balancern im Internet wird die Cloud-Ingress-Ebene wahrscheinlich von einem Infrastrukturteam verwaltet, das die exklusive Kontrolle darüber hat, wie Anwendungen im Internet verfügbar gemacht und geschützt werden. Durch diese Steuerung wird diese Ebene außerdem weniger flexibel und dynamisch als eine entwicklergesteuerte Infrastruktur. Dies könnte sich darauf auswirken, wer und wie Sie Administratorzugriff auf diese Ebene gewähren.
  • Mesh-Ingress: In Kombination mit Cloud-Ingress bietet die Mesh-Ingress-Ebene flexibles Routing, das sich in der Nähe der Anwendung befindet. Aufgrund dieser Flexibilität ist das Mesh-Netzwerk besser als Cloud-Ingress für komplexe Routinglogik und Sichtbarkeit auf Anwendungsebene. Durch die Trennung zwischen Ingress-Ebenen wird es außerdem für die Anwendungsinhaber einfacher, diese Ebene direkt zu steuern, ohne dass sich dies auf andere Teams auswirkt. Wenn Sie Service Mesh-Anwendungen über einen L4-Load-Balancer statt über einen L7-Load-Balancer verfügbar machen, sollten Sie Client-TLS auf der Mesh-Ingress-Ebene im Mesh-Netzwerk beenden, um Anwendungen zu sichern.

Systemdiagnose

Die Verwendung von zwei Schichten des L7-Load-Balancings ist die Systemdiagnose. Sie müssen jeden Load-Balancer so konfigurieren, dass er den Status der nächsten Ebene prüft, um sicherzustellen, dass er Traffic empfangen kann. Die Topologie im folgenden Diagramm zeigt, wie Cloud-Ingress den Status der Mesh-Ingress-Proxys prüft, und das Mesh-Netzwerk prüft die Integrität der Anwendungs-Back-Ends.

Cloud-Ingress prüft die Integrität von Mesh-Ingress und Mesh-Ingress prüft die Integrität der Anwendungs-Back-Ends.

Bei dieser Topologie gilt Folgendes:

  • Cloud-Ingress: In dieser Anleitung konfigurieren Sie den Load-Balancer für Google Cloud über Ingress, um die Integrität der Mesh-Ingress-Proxys auf den freigegebenen Systemdiagnose-Ports zu prüfen. Wenn ein Mesh-Proxy ausgefallen ist oder der Cluster, das Mesh-Netzwerk oder die Region nicht verfügbar ist, erkennt der Google Cloud-Load-Balancer diese Bedingung und sendet keinen Traffic an den Mesh-Proxy.
  • Mesh-Ingress: In der Mesh-Anwendung führen Sie Systemdiagnosen direkt auf den Back-Ends durch, damit Sie das Load-Balancing und die Trafficverwaltung lokal ausführen können.

Sicherheit

Die obige Topologie umfasst mehrere Sicherheitsaspekte. Einer der wichtigsten ist die Konfiguration beim Verschlüsseln und Bereitstellen von Zertifikaten. Ingress für externe HTTP(S)-Load-Balancer bietet eine tiefe Integration in von Google verwaltete Zertifikate. Über diese Integration werden automatisch öffentliche Zertifikate bereitgestellt, an einen Load-Balancer angehängt und die Zertifikate werden über die deklarative GKE Ingress-Schnittstelle erneuert und rotiert. Internetclients authentifizieren sich mit den öffentlichen Zertifikaten und stellen eine Verbindung zum externen Load-Balancer als erster Hop in der Virtual Private Cloud (VPC) her.

Der nächste Hop, der sich zwischen dem Google Front End (GFE) und dem Mesh-Ingress-Proxy befindet, ist standardmäßig verschlüsselt. Die Verschlüsselung auf Netzwerkebene zwischen den GFEs und ihren Back-Ends wird automatisch angewendet. Wenn Ihre Sicherheitsanforderungen ergeben, dass der Plattforminhaber jedoch die Eigentumsrechte an den Verschlüsselungsschlüsseln besitzt, können Sie HTTP/2 mit TLS-Verschlüsselung zwischen dem Cluster-Ingress (dem GFE) und dem Mesh-Ingress (der Envoy-Proxy-Instanz) aktivieren. Wenn Sie HTTP/2 mit TLS-Verschlüsselung für diesen Pfad aktivieren, können Sie ein selbstsigniertes oder öffentliches Zertifikat verwenden, um den Traffic zu verschlüsseln, da das GFE sich nicht authentifiziert. Diese zusätzliche Verschlüsselungsebene wird in dieser Anleitung erläutert. Verwenden Sie das öffentliche Zertifikat nicht für andere öffentliche Load-Balancer, um einen unsachgemäßen Umgang mit Zertifikaten zu vermeiden. Stattdessen empfehlen wir die Verwendung separater Zertifikate im Service Mesh.

Wenn das Service Mesh TLS erfordert, wird der gesamte Traffic zwischen Sidecar-Proxys und dem Mesh-Ingress verschlüsselt. Das folgende Diagramm veranschaulicht die HTTPS-Verschlüsselung vom Client zum Google Cloud-Load-Balancer, vom Load-Balancer zum Mesh-Ingress-Proxy sowie vom Ingress-Proxy zum Sidecar-Proxy.

Die Sicherheit wird mit verwalteten Zertifikaten außerhalb des Mesh-Netzwerks und internen Zertifikaten innerhalb des Mesh-Netzwerks implementiert.

Ziele

  • Einen Google Kubernetes Engine-Cluster (GKE) in Google Cloud bereitstellen.
  • Istio-basiertes Anthos Service Mesh auf Ihrem GKE-Cluster bereitstellen.
  • GKE Ingress so konfigurieren, dass öffentlicher HTTPS-Traffic beendet wird und der Traffic an von Service Mesh gehostete Anwendungen weitergeleitet wird.
  • Die Online Boutique-Anwendung auf dem GKE-Cluster bereitstellen, den Sie Clients im Internet zur Verfügung stellen.

Kosten

In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:

Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen. Neuen Google Cloud-Nutzern steht möglicherweise eine kostenlose Testversion zur Verfügung.

Nach Abschluss der in diesem Dokument beschriebenen Aufgaben können Sie weitere Kosten vermeiden, indem Sie die erstellten Ressourcen löschen. Weitere Informationen finden Sie unter Bereinigen.

Hinweis

  1. Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.

    Zur Projektauswahl

  2. Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.

  3. Aktivieren Sie Cloud Shell in der Google Cloud Console.

    Cloud Shell aktivieren

    Alle Terminalbefehle für diese Anleitung werden in Cloud Shell ausgeführt.

  4. Führen Sie ein Upgrade auf die neueste Version der Google Cloud CLI durch:

    gcloud components update

  5. Legen Sie Ihr Google Cloud-Standardprojekt fest:

    export PROJECT=PROJECT
export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT} --format="value(projectNumber)")
gcloud config set project ${PROJECT}

    Ersetzen Sie PROJECT durch die Projekt-ID, die Sie für diese Anleitung verwenden möchten.

  6. Erstellen Sie ein Arbeitsverzeichnis:

    mkdir -p ${HOME}/edge-to-mesh
cd ${HOME}/edge-to-mesh
export WORKDIR=`pwd`

    Nachdem Sie die Anleitung abgeschlossen haben, können Sie das Arbeitsverzeichnis löschen.

GKE-Cluster erstellen

Die in dieser Anleitung beschriebenen Funktionen erfordern die GKE-Clusterversion 1.16 oder höher.

  1. Erstellen Sie in Cloud Shell eine neue kubeconfig-Datei. Dieser Schritt gewährleistet, dass Sie keinen Konflikt mit Ihrer vorhandenen (Standard-)kubeconfig-Datei schaffen.

    touch edge2mesh_kubeconfig
export KUBECONFIG=${WORKDIR}/edge2mesh_kubeconfig

  2. Definieren Sie Umgebungsvariablen für den GKE-Cluster:

    export CLUSTER_NAME=edge-to-mesh
export CLUSTER_LOCATION=us-west1-a

  3. Aktivieren Sie die Google Kubernetes Engine API.

    gcloud

    gcloud services enable container.googleapis.com

    Config Connector

    Diese Anleitung enthält Config Connector-Ressourcen. Sie können diese Ressourcen verwenden, um dieselben Aufgaben auszuführen, die Sie auf dem Tab gcloud ausführen. Zur Verwendung dieser Ressourcen installieren Sie Config Connector und wenden die Ressourcen so an, wie es für Ihre Umgebung am besten ist.

    Verwenden Sie das folgende Services-Manifest:

    apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: container.googleapis.com
spec:
  resourceID: container.googleapis.com
  projectRef:
    external: PROJECT

  4. einen GKE-Cluster installieren

    gcloud

    gcloud container clusters create ${CLUSTER_NAME} \
    --machine-type=e2-standard-4 \
    --num-nodes=4 \
    --zone ${CLUSTER_LOCATION} \
    --enable-ip-alias \
    --workload-pool=${PROJECT}.svc.id.goog \
    --release-channel rapid \
    --addons HttpLoadBalancing \
    --labels mesh_id=proj-${PROJECT_NUMBER}

    Config Connector

    Verwenden Sie die folgenden Manifeste für ContainerCluster und ContainerNodePool:

    apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerNodePool
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  clusterRef:
    name: edge-to-mesh
  location: us-west1-a
  nodeConfig:
    machineType: e2-standard-4
  nodeCount: 4
---
apiVersion: container.cnrm.cloud.google.com/v1beta1
kind: ContainerCluster
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
    cnrm.cloud.google.com/remove-default-node-pool: "true"
  labels:
    mesh_id: proj-PROJECT_NUMBER
  name: edge-to-mesh
spec:
  addonsConfig:
    httpLoadBalancing:
      disabled: false
  location: us-west1-a
  initialNodeCount: 1
  releaseChannel:
    channel: RAPID
  workloadIdentityConfig:
    workloadPool: PROJECT.svc.id.goog

    Ersetzen Sie PROJECT_NUMBER durch den Wert der zuvor abgerufenen Umgebungsvariablen PROJECT_NUMBER.

    Wenn Sie einen Cloud-Ingress verwenden möchten, muss das HTTP-Load-Balancing-Add-on aktiviert sein. Für GKE-Cluster ist das HTTP-Load-Balancing standardmäßig aktiviert. Sie dürfen es nicht deaktivieren.

    Wenn Sie das verwaltete Anthos Service Mesh verwenden möchten, müssen Sie das Label mesh_id auf den Cluster anwenden.

  5. Prüfen Sie, ob der Cluster ausgeführt wird:

    gcloud container clusters list

    Die Ausgabe sieht etwa so aus:

    NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
edge-to-mesh  us-west1-a  v1.22.6-gke.300   35.233.195.59  e2-standard-4  v1.22.6-gke.300   4          RUNNING

  6. Als Nächstes stellen Sie die Verbindung zum Cluster her:

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --zone ${CLUSTER_LOCATION} \
    --project ${PROJECT}

Service Mesh installieren

In diesem Abschnitt konfigurieren Sie das verwaltete Anthos Service Mesh mit Fleet-API.

  1. Aktivieren Sie die erforderlichen APIs:

    gcloud

    gcloud services enable mesh.googleapis.com

    Config Connector

    Verwenden Sie das folgende Services-Manifest:

    apiVersion: serviceusage.cnrm.cloud.google.com/v1beta1
kind: Service
metadata:
  annotations:
    cnrm.cloud.google.com/deletion-policy: "abandon"
    cnrm.cloud.google.com/disable-dependent-services: "false"
  name: mesh.googleapis.com
spec:
  resourceID: mesh.googleapis.com
  projectRef:
    external: PROJECT

  2. Aktivieren Sie Anthos Service Mesh in der Flotte.

    gcloud

    gcloud container fleet mesh enable

    Config Connector

    Verwenden Sie das folgende GKEHubFeature-Manifest:

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeature
metadata:
  name: servicemesh
spec:
  projectRef:
    external: PROJECT
  location: global
  resourceID: servicemesh

  3. Registrieren Sie den Cluster in der Flotte:

    gcloud

    gcloud container fleet memberships register ${CLUSTER_NAME} \
    --gke-cluster ${CLUSTER_LOCATION}/${CLUSTER_NAME} \
    --enable-workload-identity

    Config Connector

    Verwenden Sie das folgende GKEHubMembership-Manifest:

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubMembership
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT
  name: edge-to-mesh
spec:
  location: global
  authority:
    issuer: https://container.googleapis.com/v1/projects/PROJECT/locations/us-west1-a/clusters/edge-to-mesh
  endpoint:
    gkeCluster:
      resourceRef:
        name: edge-to-mesh

  4. Aktivieren Sie die automatische Verwaltung der Steuerungsebene und der verwalteten Datenebene:

    gcloud

    gcloud container fleet mesh update \
    --management automatic \
    --memberships ${CLUSTER_NAME}

    Config Connector

    Verwenden Sie das folgende GKEHubFeatureMembership-Manifest:

    apiVersion: gkehub.cnrm.cloud.google.com/v1beta1
kind: GKEHubFeatureMembership
metadata:
  name: servicemesh-membership
spec:
  projectRef:
    external: PROJECT_ID
  location: global
  membershipRef:
    name: edge-to-mesh
  featureRef:
    name: servicemesh
  mesh:
    management: MANAGEMENT_AUTOMATIC

  5. Prüfen Sie nach einigen Minuten, ob der Status der Steuerungsebene ACTIVE lautet:

    gcloud container fleet mesh describe

    Die Ausgabe sieht etwa so aus:

    ...
membershipSpecs:
  projects/841956571429/locations/global/memberships/edge-to-mesh:
    mesh:
      management: MANAGEMENT_AUTOMATIC
membershipStates:
  projects/841956571429/locations/global/memberships/edge-to-mesh:
    servicemesh:
      controlPlaneManagement:
        details:
        - code: REVISION_READY
          details: 'Ready: asm-managed-rapid'
        state: ACTIVE
      dataPlaneManagement:
        details:
        - code: OK
          details: Service is running.
        state: ACTIVE
    state:
      code: OK
      description: 'Revision(s) ready for use: asm-managed-rapid.'
      updateTime: '2022-09-29T05:30:28.320896186Z'
name: projects/your-project/locations/global/features/servicemesh
resourceState:
  state: ACTIVE
...

GKE Ingress bereitstellen

In den folgenden Schritten stellen Sie den externen HTTP(S)-Load-Balancer über den Ingress-Controller von GKE bereit. Die Ingress-Ressource automatisiert die Bereitstellung des Load-Balancers, seiner TLS-Zertifikate und der Back-End-Systemdiagnose. Außerdem verwenden Sie Cloud Endpoints für die automatische Bereitstellung eines öffentlichen DNS-Namens für die Anwendung.

Ingress-Gateway installieren

Als Best Practice für die Sicherheit empfehlen wir, das Ingress-Gateway in einem anderen Namespace als die Steuerungsebene bereitzustellen.

  1. Erstellen Sie in Cloud Shell einen dedizierten asm-ingress-Namespace:

    kubectl create namespace asm-ingress

  2. Fügen Sie dem Namespace asm-ingress ein Namespace-Label hinzu:

    kubectl label namespace asm-ingress istio-injection=enabled

    Die Ausgabe sieht etwa so aus:

    namespace/asm-ingress labeled

    Das Hinzufügen des Labels istio-injection=enabled zum Namespace asm-ingress weist Anthos Service Mesh an, die Sidecar-Proxys von Envoy automatisch einzufügen, wenn eine Anwendung bereitgestellt wird.

  3. Führen Sie den folgenden Befehl aus, um das Manifest Deployment als ingress-deployment.yaml zu erstellen:

    cat <<EOF > ingress-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  selector:
    matchLabels:
      asm: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Anthos Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        asm: ingressgateway
    spec:
      securityContext:
        fsGroup: 1337
        runAsGroup: 1337
        runAsNonRoot: true
        runAsUser: 1337
      containers:
      - name: istio-proxy
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - all
          privileged: false
          readOnlyRootFilesystem: true
        image: auto # The image will automatically update each time the pod starts.
        resources:
          limits:
            cpu: 2000m
            memory: 1024Mi
          requests:
            cpu: 100m
            memory: 128Mi
      serviceAccountName: asm-ingressgateway
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
spec:
  maxReplicas: 5
  minReplicas: 3
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: asm-ingressgateway
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: asm-ingressgateway
subjects:
  - kind: ServiceAccount
    name: asm-ingressgateway
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
EOF

    Dieses Deployment hat ein eigenes ServiceAccount mit den verknüpften Role und RoleBinding, die dem Gateway den Zugriff auf Zertifikate ermöglichen.

  4. Stellen Sie ingress-deployment.yaml im Cluster bereit, um die Ressource Deployment zu erstellen:

    kubectl apply -f ingress-deployment.yaml

    Die Ausgabe sieht etwa so aus:

    deployment.apps/asm-ingressgateway configured
role.rbac.authorization.k8s.io/asm-ingressgateway configured
rolebinding.rbac.authorization.k8s.io/asm-ingressgateway configured
serviceaccount/asm-ingressgateway created

    Prüfen Sie, ob alle Bereitstellungen ausgeführt werden:

    kubectl wait --for=condition=available --timeout=600s deployment --all -n asm-ingress

    Die Ausgabe sieht etwa so aus:

    deployment.apps/asm-ingressgateway condition met

  5. Führen Sie den folgenden Befehl aus, um das Manifest Service als ingress-service.yaml zu erstellen:

    cat <<EOF > ingress-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: asm-ingressgateway
  namespace: asm-ingress
  annotations:
    cloud.google.com/neg: '{"ingress": true}'
    cloud.google.com/backend-config: '{"default": "ingress-backendconfig"}'
    cloud.google.com/app-protocols: '{"https":"HTTP2"}' # HTTP/2 with TLS encryption
  labels:
    asm: ingressgateway
spec:
  ports:
  # status-port exposes a /healthz/ready endpoint that can be used with GKE Ingress health checks
  - name: status-port
    port: 15021
    protocol: TCP
    targetPort: 15021
  # Any ports exposed in Gateway resources should be exposed here.
  - name: http2
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8443
  selector:
    asm: ingressgateway
  type: ClusterIP
EOF

    Dieser Service hat die folgenden Annotationen, die Parameter für den Ingress-Load-Balancer festlegen, wenn er bereitgestellt wird:

    • cloud.google.com/backend-config bezieht sich auf den Namen einer benutzerdefinierten Ressource mit dem Namen BackendConfig. Der Ingress-Controller verwendet BackendConfig, um Parameter für die Google Cloud-Ressource BackendService festzulegen. Sie verwenden diese Ressource im nächsten Schritt, um benutzerdefinierte Parameter der Google Cloud-Systemdiagnose zu definieren.
    • cloud.google.com/neg: '{"ingress": true}' aktiviert die Ingress-Back-Ends (in diesem Fall die Mesh-Ingress-Proxys) für containernatives Load-Balancing. Für ein effizienteres und stabiles Load-Balancing nutzen diese Back-Ends Netzwerk-Endpunktgruppen (NEGs) anstelle von Instanzgruppen.
    • cloud.google.com/app-protocols: '{"https":"HTTP2"}' weist das GFE an, eine Verbindung zum Ingress-Gateway des Service Mesh mithilfe von HTTP2 mit TLS herzustellen, wie unter Ingress für externes HTTP(S)-Load-Balancing und Übersicht über externes HTTP(S)-Load-Balancing beschrieben. Dadurch entsteht eine zusätzliche Verschlüsselungsebene.

  6. Stellen Sie ingress-service.yaml im Cluster bereit, um die Ressource Service zu erstellen:

    kubectl apply -f ingress-service.yaml

    Die Ausgabe sieht etwa so aus:

    service/asm-ingressgateway created

Back-End-Diensteinstellungen anwenden

  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest BackendConfig als ingress-backendconfig.yaml zu erstellen:

    cat <<EOF > ingress-backendconfig.yaml
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
  name: ingress-backendconfig
  namespace: asm-ingress
spec:
  healthCheck:
    requestPath: /healthz/ready
    port: 15021
    type: HTTP
  securityPolicy:
    name: edge-fw-policy
EOF

    BackendConfig ist eine benutzerdefinierte Ressourcendefinition (Custom Resource Definition, CRD), die Back-End-Parameter für das Ingress-Load-Balancing definiert. Eine vollständige Liste der Back-End- und Front-End-Parameter, die Sie über GKE Ingress konfigurieren können, finden Sie unter Ingress-Features.

    In dieser Anleitung gibt das Manifest BackendConfig benutzerdefinierte Systemdiagnosen für die Mesh-Ingress-Proxys an. Anthos Service Mesh und Istio stellen ihre Sidecar-Proxy-Systemdiagnosen an Port 15021 im Pfad /healthz/ready bereit. Benutzerdefinierte Systemdiagnoseparameter sind erforderlich, da der Bereitstellungsport (443) der Mesh-Ingress-Proxys von ihrem Systemdiagnose-Port (15021) abweicht. GKE Ingress verwendet die folgenden Systemdiagnoseparameter in BackendConfig, um Systemdiagnosen des Google Cloud-Load-Balancers zu konfigurieren. Auf eine Sicherheitsrichtlinie zum Schutz des Load-Balancing-Traffics verschiedener Arten von Netzwerkangriffen wird ebenfalls verwiesen.

    • healthCheck.port definiert den Port, der vom Google Cloud-Load-Balancer über die IP-Adresse jedes Pods eine Systemdiagnose erhält.
    • healthCheck.requestPath definiert den HTTP-Pfad, der eine Systemdiagnose für den angegebenen Port empfängt.
    • type definiert das Protokoll der Systemdiagnose (in diesem Fall HTTP).
    • securityPolicy.name bezieht sich auf den Namen einer Cloud Armor-Sicherheitsrichtlinie.

  2. Stellen Sie ingress-backendconfig.yaml im Cluster bereit, um die Ressource BackendConfig zu erstellen:

    kubectl apply -f ingress-backendconfig.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    backendconfig.cloud.google.com/ingress-backendconfig created

    Die BackendConfig-Parameter und asm-ingressgateway-Dienstannotationen werden erst dann auf einen Google Cloud-Load-Balancer angewendet, wenn die Ingress-Ressource bereitgestellt wurde. Das Ingress-Deployment verknüpft alle diese Ressourcen.

Sicherheitsrichtlinien festlegen

Google Cloud Armor bietet DDoS-Abwehr und anpassbare Sicherheitsrichtlinien, die Sie über Ingress-Ressourcen an einen Load-Balancer anhängen können. In den folgenden Schritten erstellen Sie eine Sicherheitsrichtlinie, die vorkonfigurierte Regeln verwendet, um Cross-Site-Scripting-Angriffe (XSS) zu blockieren. Diese Regel blockiert den Traffic, der mit bekannten Angriffssignaturen übereinstimmt, lässt aber den gesamten anderen Traffic zu. Ihre Umgebung verwendet je nach Arbeitslast unterschiedliche Regeln.

gcloud

  1. Erstellen Sie in Cloud Shell eine Sicherheitsrichtlinie mit dem Namen edge-fw-policy:

    gcloud compute security-policies create edge-fw-policy \
    --description "Block XSS attacks"

  2. Erstellen Sie eine Sicherheitsrichtlinienregel mit den vorkonfigurierten XSS-Filtern:

    gcloud compute security-policies rules create 1000 \
    --security-policy edge-fw-policy \
    --expression "evaluatePreconfiguredExpr('xss-stable')" \
    --action "deny-403" \
    --description "XSS attack filtering"

Config Connector

Verwenden Sie das folgende ComputeSecurityPolicy-Manifest:

apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSecurityPolicy
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: edge-fw-policy
spec:
  rule:
  - action: allow
    description: "Default rule"
    match:
      versionedExpr: SRC_IPS_V1
      config:
        srcIpRanges:
        - "*"
    priority: 2147483647
  - action: deny-403
    description: "XSS attack filtering"
    match:
      expr:
        expression: "evaluatePreconfiguredExpr('xss-stable')"
    priority: 1000

Im vorherigen Abschnitt wurde von edge-fw-policy auf ingress-backendconfig verwiesen. Wenn die Ingress-Ressource bereitgestellt wird, bindet sie diese Sicherheitsrichtlinie an den Load-Balancer, um Back-Ends des Dienstes asm-ingressgateway zu schützen.

IP-Adressierung und DNS konfigurieren

  1. Erstellen Sie in Cloud Shell eine globale statische IP-Adresse für den Load-Balancer von Google Cloud:

    gcloud

    gcloud compute addresses create ingress-ip --global

    Config Connector

    Verwenden Sie das folgende ComputeAddress-Manifest:

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeAddress
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: PROJECT_ID
  name: ingress-ip
spec:
  location: global

    Diese statische IP-Adresse wird von der Ingress-Ressource verwendet und ermöglicht, dass die IP unverändert bleibt, auch wenn sich der externe Load-Balancer ändert.

  2. Rufen Sie die statische IP-Adresse ab:

    export GCLB_IP=$(gcloud compute addresses describe ingress-ip --global --format "value(address)")
echo ${GCLB_IP}

    Sie benötigen einen öffentlichen DNS-Eintrag, um eine stabile, nutzerfreundliche Zuordnung zu Ihrer Ingress-IP-Adresse zu erstellen. Sie können einen beliebigen DNS-Anbieter und eine beliebige Automatisierung verwenden. In dieser Anleitung wird Endpoints verwendet, anstatt eine verwaltete DNS-Zone zu erstellen. Endpoints bietet einen kostenlosen von Google verwalteten DNS-Eintrag für eine öffentliche IP-Adresse.

  3. Führen Sie den folgenden Befehl aus, um die YAML-Spezifikationsdatei mit dem Namen dns-spec.yaml zu erstellen:

    cat <<EOF > dns-spec.yaml
swagger: "2.0"
info:
  description: "Cloud Endpoints DNS"
  title: "Cloud Endpoints DNS"
  version: "1.0.0"
paths: {}
host: "frontend.endpoints.${PROJECT}.cloud.goog"
x-google-endpoints:
- name: "frontend.endpoints.${PROJECT}.cloud.goog"
  target: "${GCLB_IP}"
EOF

    In der YAML-Spezifikation wird der öffentliche DNS-Eintrag in Form von frontend.endpoints.${PROJECT}.cloud.goog definiert, wobei ${PROJECT} Ihre eindeutige Projektnummer ist.

  4. Stellen Sie die Datei dns-spec.yaml in Ihrem Google Cloud-Projekt bereit:

    gcloud endpoints services deploy dns-spec.yaml

    Die Ausgabe sieht in etwa so aus:

    Operation finished successfully. The following command can describe the Operation details:
 gcloud endpoints operations describe operations/rollouts.frontend.endpoints.edge2mesh.cloud.goog:442b2b38-4aee-4c60-b9fc-28731657ee08

Service Configuration [2021-11-14r0] uploaded for service [frontend.endpoints.edge2mesh.cloud.goog]

    Nachdem die IP und das DNS konfiguriert sind, können Sie ein öffentliches Zertifikat generieren, um das Ingress-Front-End zu sichern. GKE Ingress unterstützt von Google verwaltete Zertifikate als Kubernetes-Ressourcen, sodass Sie diese über deklarative Mittel bereitstellen können.

TLS-Zertifikat bereitstellen

  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest ManagedCertificate als managed-cert.yaml zu erstellen:

    cat <<EOF > managed-cert.yaml
apiVersion: networking.gke.io/v1
kind: ManagedCertificate
metadata:
  name: gke-ingress-cert
  namespace: asm-ingress
spec:
  domains:
    - "frontend.endpoints.${PROJECT}.cloud.goog"
EOF

    Diese YAML-Datei gibt an, dass der über Endpoints erstellte DNS-Name verwendet wird, um ein öffentliches Zertifikat bereitzustellen. Da Google den Lebenszyklus dieser öffentlichen Zertifikate vollständig verwaltet, werden sie automatisch generiert und regelmäßig ohne direkten Nutzereingriff rotiert.

  2. Stellen Sie die Datei managed-cert.yaml in Ihrem GKE-Cluster bereit:

    kubectl apply -f managed-cert.yaml

    Die entsprechende Ausgabe sieht etwa so aus:

    managedcertificate.networking.gke.io/gke-ingress-cert created

  3. Prüfen Sie die Ressource ManagedCertificate, um den Fortschritt der Zertifikatgenerierung zu prüfen:

    kubectl describe managedcertificate gke-ingress-cert -n asm-ingress

    Die entsprechende Ausgabe sieht etwa so aus:

    Name:         gke-ingress-cert
Namespace:    asm-ingress
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"networking.gke.io/v1","kind":"ManagedCertificate","metadata":{"annotations":{},"name":"gke-ingress-cert","namespace":"...
API Version:  networking.gke.io/v1
Kind:         ManagedCertificate
Metadata:
  Creation Timestamp:  2020-08-05T20:44:49Z
  Generation:          2
  Resource Version:    1389781
  Self Link:           /apis/networking.gke.io/v1/namespaces/asm-ingress/managedcertificates/gke-ingress-cert
  UID:                 d74ec346-ced9-47a8-988a-6e6e9ddc4019
Spec:
  Domains:
    frontend.endpoints.edge2mesh.cloud.goog
Status:
  Certificate Name:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  Certificate Status:  Provisioning
  Domain Status:
    Domain:  frontend.endpoints.edge2mesh.cloud.goog
    Status:  Provisioning
Events:
  Type    Reason  Age   From                            Message
  ----    ------  ----  ----                            -------
  Normal  Create  44s   managed-certificate-controller  Create SslCertificate mcrt-306c779e-8439-408a-9634-163664ca6ced

    Wenn das Zertifikat bereit ist, lautet der Certificate Status Active.

Ingress-Ressource bereitstellen

  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest Ingress als ingress.yaml zu erstellen:

    cat <<EOF > ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: gke-ingress
  namespace: asm-ingress
  annotations:
    kubernetes.io/ingress.allow-http: "false"
    kubernetes.io/ingress.global-static-ip-name: "ingress-ip"
    networking.gke.io/managed-certificates: "gke-ingress-cert"
    kubernetes.io/ingress.class: "gce"
spec:
  defaultBackend:
    service:
      name: asm-ingressgateway
      port:
        number: 443
  rules:
  - http:
      paths:
      - path: /*
        pathType: ImplementationSpecific
        backend:
          service:
            name: asm-ingressgateway
            port:
              number: 443
EOF

    Mit diesem Manifest wird eine Ingress-Ressource definiert, die alle vorherigen Ressourcen miteinander verknüpft. Das Manifest gibt die folgenden Felder an:

    • kubernetes.io/ingress.allow-http: "false" deaktiviert HTTP-Traffic an Port 80 des Google Cloud-Load-Balancers. Dadurch wird verhindert, dass Clients eine Verbindung mit unverschlüsseltem Traffic herstellen, da Port 443 nur HTTPS beobachtet und Port 80 deaktiviert ist.
    • kubernetes.io/ingress.global-static-ip-name: "ingress-ip" verknüpft die zuvor erstellte IP-Adresse mit dem Load-Balancer. Durch diesen Link kann die IP-Adresse getrennt vom Load-Balancer erstellt werden, sodass sie getrennt vom Lebenszyklus des Load-Balancers wiederverwendet werden kann.
    • networking.gke.io/managed-certificates: "gke-ingress-cert" verknüpft diesen Load-Balancer mit der zuvor erstellten von Google verwalteten SSL-Zertifikatsressource.

  2. Stellen Sie ingress.yaml in Ihrem Cluster bereit:

    kubectl apply -f ingress.yaml

  3. Prüfen Sie die Ingress-Ressource, um den Fortschritt der Bereitstellung des Load-Balancers zu prüfen:

    kubectl describe ingress gke-ingress -n asm-ingress

    Die entsprechende Ausgabe sieht etwa so aus:

    ...
Annotations:
  ingress.kubernetes.io/https-forwarding-rule:       k8s2-fs-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/ssl-cert:                    mcrt-306c779e-8439-408a-9634-163664ca6ced
  networking.gke.io/managed-certificates:            gke-ingress-cert
  kubernetes.io/ingress.global-static-ip-name:  ingress-ip
  ingress.gcp.kubernetes.io/pre-shared-cert:    mcrt-306c779e-8439-408a-9634-163664ca6ced
  ingress.kubernetes.io/backends:               {"k8s-be-31610--07bdde06b914144a":"HEALTHY","k8s1-07bdde06-asm-ingress-asm-ingressgateway-443-228c1881":"HEALTHY"}
  ingress.kubernetes.io/forwarding-rule:        k8s2-fr-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/https-target-proxy:     k8s2-ts-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/target-proxy:           k8s2-tp-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
  ingress.kubernetes.io/url-map:                k8s2-um-fq3ng2uk-asm-ingress-gke-ingress-qm3qqdor
...

    Die Ingress-Ressource ist bereit, wenn die ingress.kubernetes.io/backends-Annotationen anzeigen, dass die Back-Ends HEALTHY sind. Die Annotationen enthalten auch die Namen verschiedener bereitgestellter Google Cloud-Ressourcen, einschließlich Back-End-Diensten, SSL-Zertifikaten und HTTPS-Ziel-Proxys.

Selbst signiertes Ingress-Gateway-Zertifikat installieren

In den folgenden Schritten generieren und installieren Sie ein Zertifikat (als Kubernetes-secret-Ressource), mit dem das GFE eine TLS-Verbindung zum Ingress-Gateway des Service Mesh herstellen kann. Weitere Informationen zu den Anforderungen des Ingress-Gateway-Zertifikats finden Sie im Leitfaden zur Sicherheit von Back-End-Protokollen.

  1. Erstellen Sie in Cloud Shell mit openssl den privaten Schlüssel und das Zertifikat:

    openssl req -new -newkey rsa:4096 -days 365 -nodes -x509 \
 -subj "/CN=frontend.endpoints.${PROJECT}.cloud.goog/O=Edge2Mesh Inc" \
 -keyout frontend.endpoints.${PROJECT}.cloud.goog.key \
 -out frontend.endpoints.${PROJECT}.cloud.goog.crt

  2. Erstellen Sie Secret im Namespace asm-ingress:

    kubectl -n asm-ingress create secret tls edge2mesh-credential \
 --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
 --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt

Ingress-Gateway für externes Load-Balancing konfigurieren

In den folgenden Schritten erstellen Sie eine gemeinsam genutzte Gateway-Ressource im Namespace asm-ingress. Gateways gehören im Allgemeinen dem Plattformadministrator oder dem Netzwerkadministrator-Team. Daher wird die Ressource Gateway im Namespace asm-ingress erstellt, der dem Plattformadministrator gehört, und kann in anderen Namespaces über ihre eigenen VirtualService-Einträge verwendet werden.

  1. Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest Gateway als ingress-gateway.yaml zu erstellen:

    cat <<EOF > ingress-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
    name: asm-ingressgateway
    namespace: asm-ingress
spec:
  selector:
    asm: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    hosts:
    - "*" # IMPORTANT: Must use wildcard here when using SSL, see note below
    tls:
      mode: SIMPLE
      credentialName: edge2mesh-credential
EOF

    Beachten Sie, dass Sie den Platzhalter * im Feld hosts in Gateway verwenden müssen. GCLB verwendet keine SNI-Erweiterung für die Back-Ends. Mit dem Platzhaltereintrag wird das verschlüsselte Paket (aus GCLB) an das ASM-Ingress-Gateway gesendet. Das ASM-Ingress-Gateway entschlüsselt das Paket und verwendet den HTTP-Host-Header (im entschlüsselten Paket), um Routingentscheidungen anhand von VirtualService-Einträgen zu treffen.

  2. Stellen Sie ingress-gateway.yaml in Ihrem Cluster bereit:

    kubectl apply -f ingress-gateway.yaml

    Die Ausgabe sieht etwa so aus:

    gateway.networking.istio.io/asm-ingressgateway created

Beispiel-App "Onlineshop" installieren

  1. Erstellen Sie in Cloud Shell einen dedizierten onlineboutique-Namespace:

    kubectl create namespace onlineboutique

  2. Fügen Sie dem Namespace onlineboutique ein Namespace-Label hinzu:

    kubectl label namespace onlineboutique istio-injection=enabled

    Die Ausgabe sieht etwa so aus:

    namespace/onlineboutique labeled

    Das Hinzufügen des Labels istio-injection=enabled zum Namespace onlineboutique weist Anthos Service Mesh an, die Sidecar-Proxys von Envoy automatisch einzufügen, wenn eine Anwendung bereitgestellt wird.

  3. Laden Sie die Kubernetes-YAML-Dateien für die Beispielanwendung „Online Boutique“ herunter:

    curl -LO \
    https://raw.githubusercontent.com/GoogleCloudPlatform/microservices-demo/main/release/kubernetes-manifests.yaml

  4. Stellen Sie die Online Boutique-Anwendung bereit:

    kubectl apply -f kubernetes-manifests.yaml -n onlineboutique

    Die entsprechende Ausgabe sieht etwa so aus:

    deployment.apps/frontend created
service/frontend created
service/frontend-external created
...

  5. Prüfen Sie, ob alle Bereitstellungen ausgeführt werden:

    kubectl get pods -n onlineboutique

    Die Ausgabe sieht etwa so aus:

    NAME                                     READY   STATUS    RESTARTS   AGE
adservice-d854d8786-fjb7q                2/2     Running   0          3m
cartservice-85b5d5b4ff-8qn7g             2/2     Running   0          2m59s
checkoutservice-5f9bf659b8-sxhsq         2/2     Running   0          3m1s
...

  6. Führen Sie den folgenden Befehl aus, um das Manifest VirtualService als frontend-virtualservice.yaml zu erstellen:

    cat <<EOF > frontend-virtualservice.yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: frontend-ingress
  namespace: onlineboutique
spec:
  hosts:
  - "frontend.endpoints.${PROJECT}.cloud.goog"
  gateways:
  - asm-ingress/asm-ingressgateway
  http:
  - route:
    - destination:
        host: frontend
        port:
          number: 80
EOF

    Beachten Sie, dass VirtualService im Anwendungs-Namespace (onlineboutique) erstellt wird. In der Regel entscheidet der Anwendungsinhaber und konfiguriert, wie und welcher Traffic an die Anwendung frontend weitergeleitet wird, damit VirtualService vom Anwendungsinhaber bereitgestellt wird.

  7. Stellen Sie frontend-virtualservice.yaml in Ihrem Cluster bereit:

    kubectl apply -f frontend-virtualservice.yaml

    Die Ausgabe sieht etwa so aus:

    virtualservice.networking.istio.io/frontend-virtualservice created

  8. Klicken Sie auf den folgenden Link:

    echo "https://frontend.endpoints.${PROJECT}.cloud.goog"

    Ihr Online-Boutique-Front-End wird angezeigt.

    Produkte auf der Startseite der Online-Boutique.

  9. Klicken Sie zum Aufrufen der Details Ihres Zertifikats in der Adressleiste des Browsers auf Websiteinformationen anzeigen und dann auf Zertifikat (gültig).

    In der Zertifikatsansicht werden Details zum verwalteten Zertifikat angezeigt, einschließlich des Ablaufdatums und des Ausstellers des Zertifikats.

Sie haben jetzt einen globalen HTTPS-Load-Balancer, der als Front-End für Ihre von einem Dienst gehostete Anwendung bereitgestellt wird.

Bereinigen

Nach Abschluss der Anleitung können Sie die von Ihnen in Google Cloud erstellten Ressourcen entfernen, damit Ihnen diese nicht weiter in Rechnung gestellt werden. Sie können entweder das Projekt komplett löschen oder die Clusterressourcen löschen und anschließend den Cluster entfernen.

Projekt löschen

  1. Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.

    Zur Seite „Ressourcen verwalten“

  2. Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
  3. Geben Sie im Dialogfeld die Projekt-ID ein und klicken Sie auf Shut down (Beenden), um das Projekt zu löschen.

Einzelne Ressourcen löschen

Wenn Sie das in dieser Anleitung verwendete Google Cloud-Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen:

  1. Ingress-Ressource löschen:

    kubectl delete -f ingress.yaml

  2. Verwaltetes Zertifikat löschen:

    kubectl delete -f managed-cert.yaml

  3. Endpoints-DNS-Eintrag löschen:

    gcloud endpoints services delete "frontend.endpoints.${PROJECT}.cloud.goog"

    Die entsprechende Ausgabe sieht etwa so aus:

    Are you sure? This will set the service configuration to be deleted, along
with all of the associated consumer information. Note: This does not
immediately delete the service configuration or data and can be undone using
the undelete command for 30 days. Only after 30 days will the service be
purged from the system.

  4. Wenn Sie zum Fortfahren aufgefordert werden, geben Sie Y ein.

    Die entsprechende Ausgabe sieht etwa so aus:

    Waiting for async operation operations/services.frontend.endpoints.edge2mesh.cloud.goog-5 to complete...
Operation finished successfully. The following command can describe the Operation details:
 gcloud endpoints operations describe operations/services.frontend.endpoints.edge2mesh.cloud.goog-5

  5. Löschen Sie die statische IP-Adresse:

    gcloud compute addresses delete ingress-ip --global

    Die entsprechende Ausgabe sieht etwa so aus:

    The following global addresses will be deleted:

 - [ingress-ip]

  6. Wenn Sie zum Fortfahren aufgefordert werden, geben Sie Y ein.

    Die entsprechende Ausgabe sieht etwa so aus:

    Deleted
[https://www.googleapis.com/compute/v1/projects/edge2mesh/global/addresses/ingress-ip].

  7. Löschen Sie den GKE-Cluster:

    gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION

Nächste Schritte