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

Last reviewed 2024-01-31 UTC

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

Sie können eine Anwendung je nach Standort des Clients für verschiedene Clients bereitstellen. In dieser Bereitstellung 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 Bereitstellung richtet sich an fortgeschrittene Fachkräfte, die Anthos Service Mesh ausführen. Sie ist aber auch für Istio in Google Kubernetes Engine hilfreich.

Architektur

Das folgende Diagramm zeigt, wie Sie mithilfe von Mesh-Ingress-Gateways Load-Balancer in ein Service Mesh einbinden können:

Hinweis:Bei Anwendungen in Anthos Service Mesh ist die Bereitstellung des externen TCP/UDP-Load-Balancers die Standard-Sichtbarkeitseinstellung. Sie stellen den Load-Balancer über den Kubernetes-Dienst bereit, der die Pods der Mesh-Ingress-Proxys auswählt.

In der Topologie des vorherigen Diagramms bezieht die Cloud-Ingress-Ebene, die über GKE Gateway programmiert wird, Traffic von außerhalb des Service Mesh und leitet diesen Traffic an die Mesh-Ingress-Ebene weiter. Die Mesh-Ingress-Ebene leitet dann den Traffic an die mit dem Mesh-Netzwerk gehosteten Anwendungs-Back-Ends weiter.

Bei der vorhergehenden Topologie gilt Folgendes:

• Cloud-Ingress: In dieser Referenzarchitektur konfigurieren Sie den Google Cloud-Load Balancer über das GKE Gateway, um den Status der Mesh-Ingress-Proxys auf den freigegebenen Systemdiagnose-Ports zu prüfen.
• 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.

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

Lernziele

• Einen Google Kubernetes Engine-Cluster (GKE) in Google Cloud bereitstellen.
• Istio-basiertes Anthos Service Mesh auf Ihrem GKE-Cluster bereitstellen.
• GKE Gateway 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.

Kostenoptimierung

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

• Google Kubernetes Engine
• Compute Engine
• Cloud Load Balancing
• Zertifikatmanager
• Anthos Service Mesh
• Google Cloud Armor
• Cloud Endpoints

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.

Hinweise

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

   Hinweis: Wenn Sie die Ressourcen, die Sie in diesem Verfahren erstellen, nicht behalten möchten, erstellen Sie ein Projekt, anstatt ein vorhandenes Projekt auszuwählen. Wenn Sie fertig sind, können Sie das Projekt löschen und dadurch alle mit dem Projekt verknüpften Ressourcen entfernen.

   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 Bereitstellung 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 Bereitstellung 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 Bereitstellung abgeschlossen haben, können Sie das Arbeitsverzeichnis löschen.

GKE-Cluster erstellen

Die in dieser Bereitstellung 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-central1
   

3. Aktivieren Sie die Google Kubernetes Engine API:

   gcloud services enable container.googleapis.com
   

4. Erstellen Sie einen GKE Autopilot-Cluster:

   gcloud container --project ${PROJECT} clusters create-auto
   ${CLUSTER_NAME} --region ${CLUSTER_LOCATION} --release-channel rapid
   

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

   gcloud container clusters list
   

   Die Ausgabe sieht in etwa so aus:

   NAME          LOCATION    MASTER_VERSION    MASTER_IP      MACHINE_TYPE   NODE_VERSION      NUM_NODES  STATUS
   edge-to-mesh  us-central1  1.27.3-gke.1700   34.122.84.52  e2-medium  1.27.3-gke.1700   3          RUNNING
   

Service Mesh installieren

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

1. Aktivieren Sie in Cloud Shell die erforderlichen APIs:

   gcloud services enable mesh.googleapis.com
   

2. Aktivieren Sie Anthos Service Mesh in der Flotte.

   gcloud container fleet mesh enable
   

3. Registrieren Sie den Cluster in der Flotte:

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

4. Wenden Sie das Label mesh_id auf den Cluster edge-to-mesh an:

   gcloud container clusters update ${CLUSTER_NAME} --project ${PROJECT} --region ${CLUSTER_LOCATION} --update-labels mesh_id=proj-${PROJECT_NUMBER}
   

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

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

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

   gcloud container fleet mesh describe
   

   Die Ausgabe sieht in etwa so aus:

   ...
   membershipSpecs:
     projects/892585880385/locations/us-central1/memberships/edge-to-mesh:
       mesh:
         management: MANAGEMENT_AUTOMATIC
   membershipStates:
     projects/892585880385/locations/us-central1/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: '2023-08-04T02:54:39.495937877Z'
   name: projects/e2m-doc-01/locations/global/features/servicemesh
   resourceState:
     state: ACTIVE
   ...
   

GKE Gateway bereitstellen

In den folgenden Schritten stellen Sie den externen Application Load Balancer über den GKE-Gateway-Controller bereit. Die GKE-Gateway-Ressource automatisiert die Bereitstellung des Load-Balancers und der Backend-Systemdiagnose. Darüber hinaus verwenden Sie den Zertifikatmanager, um ein TLS-Zertifikat bereitzustellen und zu verwalten, und Endpoints, um automatisch einen öffentlichen DNS-Namen für die Anwendung bereitzustellen.

Service Mesh-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 in 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. Erstellen Sie ein selbst signiertes Zertifikat, das vom Ingress-Gateway verwendet wird, um TLS-Verbindungen zwischen dem Google Cloud-Load-Balancer (der später über den GKE-Gateway-Controller konfiguriert werden wird) und dem Ingress-Gateway zu beenden, und speichern Sie das selbst signierte Zertifikat als Kubernetes-Secret:

   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
   
   kubectl -n asm-ingress create secret tls edge2mesh-credential \
    --key=frontend.endpoints.${PROJECT}.cloud.goog.key \
    --cert=frontend.endpoints.${PROJECT}.cloud.goog.crt
   

   Weitere Informationen zu den Anforderungen für das Ingress-Gateway-Zertifikat finden Sie im Leitfaden zur Sicherheit von Back-End-Protokollen.

4. Führen Sie die folgenden Befehle aus, um die YAML-Datei für die Ingress-Gateway-Ressource zu erstellen:

   mkdir -p ${WORKDIR}/asm-ig/base
   cat <<EOF > ${WORKDIR}/asm-ig/base/kustomization.yaml
   resources:
     - github.com/GoogleCloudPlatform/anthos-service-mesh-samples/docs/ingress-gateway-asm-manifests/base
   EOF
   
   mkdir ${WORKDIR}/asm-ig/variant
   cat <<EOF > ${WORKDIR}/asm-ig/variant/role.yaml
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: asm-ingressgateway
     namespace: asm-ingress
   rules:
   - apiGroups: [""]
     resources: ["secrets"]
     verbs: ["get", "watch", "list"]
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/rolebinding.yaml
   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
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/service-proto-type.yaml
   apiVersion: v1
   kind: Service
   metadata:
     name: asm-ingressgateway
   spec:
     ports:
     - name: status-port
       port: 15021
       protocol: TCP
       targetPort: 15021
     - name: http
       port: 80
       targetPort: 8080
     - name: https
       port: 443
       targetPort: 8443
       appProtocol: HTTP2
     type: ClusterIP
   EOF
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/gateway.yaml
   apiVersion: networking.istio.io/v1beta1
   kind: Gateway
   metadata:
     name: asm-ingressgateway
   spec:
     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
   
   cat <<EOF > ${WORKDIR}/asm-ig/variant/kustomization.yaml
   namespace: asm-ingress
   resources:
   - ../base
   - role.yaml
   - rolebinding.yaml
   patches:
   - path: service-proto-type.yaml
     target:
       kind: Service
   - path: gateway.yaml
     target:
       kind: Gateway
   EOF
   

5. Wenden Sie die CRDs für das Ingress-Gateway an:

   kubectl apply -k ${WORKDIR}/asm-ig/variant
   

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

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

   Die Ausgabe sieht in etwa so aus:

   deployment.apps/asm-ingressgateway condition met
   

Systemdiagnose für das Service Mesh-Ingress-Gateway anwenden

Wenn Sie ein Service Mesh-Ingress-Gateway in einen Google Cloud-Anwendungs-Load-Balancer einbinden, muss der Anwendungs-Load-Balancer so konfiguriert sein, dass Systemdiagnosen für die Ingress-Gateway-Pods ausgeführt werden. Die HealthCheckPolicy-CRD bietet eine API zum Konfigurieren dieser Systemdiagnose.

1. Erstellen Sie in Cloud Shell die Datei HealthCheckPolicy.yaml:

   cat <<EOF >${WORKDIR}/ingress-gateway-healthcheck.yaml
   apiVersion: networking.gke.io/v1
   kind: HealthCheckPolicy
   metadata:
     name: ingress-gateway-healthcheck
     namespace: asm-ingress
   spec:
     default:
       checkIntervalSec: 20
       timeoutSec: 5
       #healthyThreshold: HEALTHY_THRESHOLD
       #unhealthyThreshold: UNHEALTHY_THRESHOLD
       logConfig:
         enabled: True
       config:
         type: HTTP
         httpHealthCheck:
           #portSpecification: USE_NAMED_PORT
           port: 15021
           portName: status-port
           #host: HOST
           requestPath: /healthz/ready
           #response: RESPONSE
           #proxyHeader: PROXY_HEADER
       #requestPath: /healthz/ready
       #port: 15021
     targetRef:
       group: ""
       kind: Service
       name: asm-ingressgateway
   EOF
   

2. Wenden Sie die HealthCheckPolicy: Datei an.

   kubectl apply -f ${WORKDIR}/ingress-gateway-healthcheck.yaml
   

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.

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"
   

3. Erstellen Sie die Datei GCPBackendPolicy.yaml, die an den Ingress-Gateway-Dienst angehängt werden soll:

   cat <<EOF > ${WORKDIR}/cloud-armor-backendpolicy.yaml
   apiVersion: networking.gke.io/v1
   kind: GCPBackendPolicy
   metadata:
     name: cloud-armor-backendpolicy
     namespace: asm-ingress
   spec:
     default:
       securityPolicy: edge-fw-policy
     targetRef:
       group: ""
       kind: Service
       name: asm-ingressgateway
   EOF
   

4. Wenden Sie die Datei GCPBackendPolicy.yaml an:

   kubectl apply -f ${WORKDIR}/cloud-armor-backendpolicy.yaml
   

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 compute addresses create e2m-gclb-ip --global
   

   Diese statische IP-Adresse wird von der GKE Gateway-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 e2m-gclb-ip
   --global --format "value(address)")
   echo ${GCLB_IP}
   

   Sie benötigen einen öffentlichen DNS-Eintrag, um eine stabile, nutzerfreundliche Zuordnung zur statischen IP-Adresse Ihres Anwendungs-Load-Balancers zu erstellen. Sie können einen beliebigen DNS-Anbieter und eine beliebige Automatisierung verwenden. In dieser Bereitstellung 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 > ${WORKDIR}/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 Projekt-ID ist.

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

   gcloud endpoints services deploy ${WORKDIR}/dns-spec.yaml
   

   Die Ausgabe sieht in etwa so aus:

   project [e2m-doc-01]...
   Operation "operations/acat.p2-892585880385-fb4a01ad-821d-4e22-bfa1-a0df6e0bf589" finished successfully.
   
   Service Configuration [2023-08-04r0] uploaded for service [frontend.endpoints.e2m-doc-01.cloud.goog]
   

   Nachdem die IP-Adresse und das DNS konfiguriert sind, können Sie ein öffentliches Zertifikat generieren, um das Frontend zu sichern. Für die Einbindung in GKE Gateway verwenden Sie TLS-Zertifikate von Certificate Manager.

TLS-Zertifikat bereitstellen

In diesem Abschnitt erstellen Sie ein TLS-Zertifikat mit dem Zertifikatmanager und verknüpfen es mit einer Zertifikatszuordnung durch einen Eintrag in der Zertifikatszuordnung. Der über GKE Gateway konfigurierte Anwendungs-Load-Balancer verwendet das Zertifikat, um eine sichere Kommunikation zwischen dem Client und Google Cloud zu ermöglichen. Nach der Erstellung wird von der GKE-Gateway-Ressource auf den Eintrag der Zertifikatszuordnung verwiesen.

1. Aktivieren Sie die Certificate Manager API in Cloud Shell:

   gcloud services enable certificatemanager.googleapis.com --project=${PROJECT}
   

2. Erstellen Sie das TLS-Zertifikat:

   gcloud --project=${PROJECT} certificate-manager certificates create edge2mesh-cert \
       --domains="frontend.endpoints.${PROJECT}.cloud.goog"
   

3. Erstellen Sie die Zertifikatzuordnung:

   gcloud --project=${PROJECT} certificate-manager maps create edge2mesh-cert-map
   

4. Hängen Sie das Zertifikat mit einem Eintrag der Zertifikatszuordnung an die Zertifikatszuordnung an:

   gcloud --project=${PROJECT} certificate-manager maps entries create edge2mesh-cert-map-entry \
       --map="edge2mesh-cert-map" \
       --certificates="edge2mesh-cert" \
       --hostname="frontend.endpoints.${PROJECT}.cloud.goog"
   

GKE-Gateway und HTTPRoute-Ressourcen bereitstellen

In diesem Abschnitt konfigurieren Sie die GKE-Gateway-Ressource, die den Google Cloud-Anwendungs-Load-Balancer über die gke-l7-global-external-managed gatewayClass bereitstellt. Außerdem konfigurieren Sie HTTPRoute-Ressourcen, die sowohl Anfragen an die Anwendung weiterleiten als auch HTTP-zu-HTTP(S)-Weiterleitungen ausführen.

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

   cat <<EOF > ${WORKDIR}/gke-gateway.yaml
   kind: Gateway
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: external-http
     namespace: asm-ingress
     annotations:
       networking.gke.io/certmap: edge2mesh-cert-map
   spec:
     gatewayClassName: gke-l7-global-external-managed # gke-l7-gxlb
     listeners:
     - name: http # list the port only so we can redirect any incoming http requests to https
       protocol: HTTP
       port: 80
     - name: https
       protocol: HTTPS
       port: 443
     addresses:
     - type: NamedAddress
       value: e2m-gclb-ip # reference the static IP created earlier
   EOF
   

2. Wenden Sie das Gateway-Manifest an, um einen Gateway mit dem Namen external-http zu erstellen:

   kubectl apply -f ${WORKDIR}/gke-gateway.yaml
   

3. Erstellen Sie die Standarddatei HTTPRoute.yaml:

   cat << EOF > ${WORKDIR}/default-httproute.yaml
   apiVersion: gateway.networking.k8s.io/v1beta1
   kind: HTTPRoute
   metadata:
     name: default-httproute
     namespace: asm-ingress
   spec:
     parentRefs:
     - name: external-http
       namespace: asm-ingress
       sectionName: https
     rules:
     - matches:
       - path:
           value: /
       backendRefs:
       - name: asm-ingressgateway
         port: 443
   EOF
   

4. Wenden Sie die Standard-HTTPRoute an:

   kubectl apply -f ${WORKDIR}/default-httproute.yaml
   

5. Erstellen Sie eine zusätzliche HTTPRoute.yaml-Datei, um HTTP-zu-HTTP(S)-Weiterleitungen durchzuführen:

   cat << EOF > ${WORKDIR}/default-httproute-redirect.yaml
   kind: HTTPRoute
   apiVersion: gateway.networking.k8s.io/v1beta1
   metadata:
     name: http-to-https-redirect-httproute
     namespace: asm-ingress
   spec:
     parentRefs:
     - name: external-http
       namespace: asm-ingress
       sectionName: http
     rules:
     - filters:
       - type: RequestRedirect
         requestRedirect:
           scheme: https
           statusCode: 301
   EOF
   

6. Wenden Sie die Weiterleitung HTTPRoute an:

   kubectl apply -f ${WORKDIR}/default-httproute-redirect.yaml
   

   Der Abgleich nimmt Zeit in Anspruch. Verwenden Sie den folgenden Befehl bis programmed=true:

   kubectl get gateway external-http -n asm-ingress -w
   

Beispiel-App "Online Boutique" installieren

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

   kubectl create namespace onlineboutique
   

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

   kubectl label namespace onlineboutique istio-injection=enabled
   

   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 Ausgabe sieht etwa so aus (einschließlich Warnungen zum Festlegen von Standardressourcenanforderungen und -limits für GKE Autopilot):

   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/emailservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/emailservice created
   service/emailservice created
   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/checkoutservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/checkoutservice created
   service/checkoutservice created
   Warning: autopilot-default-resources-mutator:Autopilot updated Deployment onlineboutique/recommendationservice: adjusted resources to meet requirements for containers [server] (see http://g.co/gke/autopilot-resources)
   deployment.apps/recommendationservice created
   service/recommendationservice created
   ...
   

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

   kubectl get pods -n onlineboutique
   

   Die Ausgabe sieht in etwa so aus:

   NAME                                     READY   STATUS    RESTARTS   AGE
   adservice-64d8dbcf59-krrj9               2/2     Running   0          2m59s
   cartservice-6b77b89c9b-9qptn             2/2     Running   0          2m59s
   checkoutservice-7668b7fc99-5bnd9         2/2     Running   0          2m58s
   ...
   

   Warten Sie einige Minuten, bis der GKE Autopilot-Cluster die erforderliche Computing-Infrastruktur zur Unterstützung der Anwendung bereitgestellt hat.

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/v1beta1
   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
   

   VirtualService wird im Anwendungs-Namespace (onlineboutique) erstellt. 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
   

8. Klicken Sie auf den folgenden Link:

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

   Ihr Online-Boutique-Frontend wird angezeigt.

   

   Hinweis: Unter Umständen erhalten Sie einen ERR_SSL_VERSION_OR_CIPHER_MISMATCH-Fehler. Dieser Fehler tritt auf, wenn Zertifikate noch nicht an alle Google-Front-Ends (GFEs) übertragen wurden. Warten Sie einige Minuten und versuchen Sie es dann noch einmal.

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 Frontend für Ihre von einem Dienst gehostete Anwendung bereitgestellt wird.

Bereinigen

Nach Abschluss der Bereitstellung 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

Achtung: Das Löschen von Projekten hat folgende Auswirkungen:
• Alle Inhalte des Projekts werden gelöscht. Wenn Sie für die Aufgaben in diesem Dokument ein bereits bestehendes Projekt verwendet haben und dieses löschen, werden auch alle anderen im Rahmen des Projekts erstellten Daten gelöscht.
• Benutzerdefinierte Projekt-IDs gehen verloren. Beim Erstellen dieses Projekts haben Sie möglicherweise eine benutzerdefinierte Projekt-ID erstellt, die Sie weiterhin verwenden möchten. Damit die URLs, die die Projekt-ID nutzen, z. B. eine appspot.com-URL, erhalten bleiben, sollten Sie ausgewählte Ressourcen innerhalb des Projekts löschen, statt das gesamte Projekt.
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 Bereitstellung verwendete Google Cloud-Projekt beibehalten möchten, löschen Sie die einzelnen Ressourcen:

1. Löschen Sie in Cloud Shell die HTTPRoute-Ressourcen:

   kubectl delete -f ${WORKDIR}/default-httproute-redirect.yaml
   kubectl delete -f ${WORKDIR}/default-httproute.yaml
   

2. Löschen Sie die GKE-Gateway-Ressource:

   kubectl delete -f ${WORKDIR}/gke-gateway.yaml
   

3. Löschen Sie die TLS-Zertifikatsressourcen (einschließlich des Eintrags der Zertifikatszuordnung und der zugehörigen übergeordneten Zertifikatszuordnung):

   gcloud --project=${PROJECT} certificate-manager maps entries delete edge2mesh-cert-map-entry --map="edge2mesh-cert-map" --quiet
   gcloud --project=${PROJECT} certificate-manager maps delete edge2mesh-cert-map --quiet
   gcloud --project=${PROJECT} certificate-manager certificates delete edge2mesh-cert --quiet
   

4. Endpoints-DNS-Eintrag löschen:

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

   Die Ausgabe sieht in 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.
   

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

   Die Ausgabe sieht in 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
   

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

   gcloud compute addresses delete ingress-ip --global
   

   Die Ausgabe sieht in etwa so aus:

   The following global addresses will be deleted:
   
    - [ingress-ip]
   

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

   Die Ausgabe sieht in etwa so aus:

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

8. Löschen Sie den GKE-Cluster:

   gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
   

   Die Ausgabe sieht in etwa so aus:

   The following clusters will be deleted.
   - [edge-to-mesh] in [us-central1]
   

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

   Nach einigen Minuten sieht die Ausgabe in etwa so aus:

   Deleting cluster edge-to-mesh...done.
   Deleted
   [https://container.googleapis.com/v1/projects/e2m-doc-01/zones/us-central1/clusters/edge-to-mesh].
   

Nächste Schritte

• Weitere Informationen zu Funktionen von GKE Ingress, die Sie mit Ihrem Service Mesh verwenden können.
• Weitere Informationen zu den verschiedenen Arten von Cloud Load Balancing für GKE.
• Weitere Informationen zu Features und Funktionen von Anthos Service Mesh.
• Weitere Informationen zur Bereitstellung von Ingress über mehrere GKE-Cluster für multiregionales Load-Balancing.
• Weitere Referenzarchitekturen, Diagramme und Best Practices finden Sie im Cloud-Architekturcenter.