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.
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:
- Globales Anycast-VIP-Advertising und global verteilte TLS- und HTTP-Beendigung
- DDoS-Verteidigung und Traffic-Filterung am Netzwerkrand mit Google Cloud Armor
- API-Gateway-Funktion mit IAP
- Automatische Erstellung und Rotation von öffentlichen Zertifikaten mit von Google verwalteten Zertifikaten
- Multi-Cluster- und multiregionales Load-Balancing am Netzwerkrand mit Multi-Cluster-Ingress
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.
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.
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.
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:
- Google Kubernetes Engine
- Compute Engine
- Cloud Load Balancing
- Anthos Service Mesh
- Google Cloud Armor
- Cloud Endpoints
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
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
-
Wählen Sie in der Google Cloud Console auf der Seite der Projektauswahl ein Google Cloud-Projekt aus oder erstellen Sie eines.
-
Die Abrechnung für das Google Cloud-Projekt muss aktiviert sein.
-
Aktivieren Sie Cloud Shell in der Google Cloud Console.
Alle Terminalbefehle für diese Anleitung werden in Cloud Shell ausgeführt.
Führen Sie ein Upgrade auf die neueste Version der Google Cloud CLI durch:
gcloud components update
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.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.
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
Definieren Sie Umgebungsvariablen für den GKE-Cluster:
export CLUSTER_NAME=edge-to-mesh export CLUSTER_LOCATION=us-west1-a
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
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
undContainerNodePool
: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 UmgebungsvariablenPROJECT_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.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
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.
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
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
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
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
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.
Erstellen Sie in Cloud Shell einen dedizierten
asm-ingress
-Namespace:kubectl create namespace asm-ingress
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 Namespaceasm-ingress
weist Anthos Service Mesh an, die Sidecar-Proxys von Envoy automatisch einzufügen, wenn eine Anwendung bereitgestellt wird.Führen Sie den folgenden Befehl aus, um das Manifest
Deployment
alsingress-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 eigenesServiceAccount
mit den verknüpftenRole
undRoleBinding
, die dem Gateway den Zugriff auf Zertifikate ermöglichen.Stellen Sie
ingress-deployment.yaml
im Cluster bereit, um die RessourceDeployment
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
Führen Sie den folgenden Befehl aus, um das Manifest
Service
alsingress-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 NamenBackendConfig
. Der Ingress-Controller verwendetBackendConfig
, um Parameter für die Google Cloud-RessourceBackendService
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.
Stellen Sie
ingress-service.yaml
im Cluster bereit, um die RessourceService
zu erstellen:kubectl apply -f ingress-service.yaml
Die Ausgabe sieht etwa so aus:
service/asm-ingressgateway created
Back-End-Diensteinstellungen anwenden
Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest
BackendConfig
alsingress-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 Port15021
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 inBackendConfig
, 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.
Stellen Sie
ingress-backendconfig.yaml
im Cluster bereit, um die RessourceBackendConfig
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 undasm-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
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"
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
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.
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.
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.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
Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest
ManagedCertificate
alsmanaged-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.
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
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
Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest
Ingress
alsingress.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 Port80
des Google Cloud-Load-Balancers. Dadurch wird verhindert, dass Clients eine Verbindung mit unverschlüsseltem Traffic herstellen, da Port443
nur HTTPS beobachtet und Port80
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.
Stellen Sie
ingress.yaml
in Ihrem Cluster bereit:kubectl apply -f ingress.yaml
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-EndsHEALTHY
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.
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
Erstellen Sie
Secret
im Namespaceasm-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.
Führen Sie in Cloud Shell den folgenden Befehl aus, um das Manifest
Gateway
alsingress-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 Feldhosts
inGateway
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 vonVirtualService
-Einträgen zu treffen.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
Erstellen Sie in Cloud Shell einen dedizierten
onlineboutique
-Namespace:kubectl create namespace onlineboutique
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 Namespaceonlineboutique
weist Anthos Service Mesh an, die Sidecar-Proxys von Envoy automatisch einzufügen, wenn eine Anwendung bereitgestellt wird.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
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 ...
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 ...
Führen Sie den folgenden Befehl aus, um das Manifest
VirtualService
alsfrontend-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 Anwendungfrontend
weitergeleitet wird, damitVirtualService
vom Anwendungsinhaber bereitgestellt wird.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
Klicken Sie auf den folgenden Link:
echo "https://frontend.endpoints.${PROJECT}.cloud.goog"
Ihr Online-Boutique-Front-End wird angezeigt.
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
- Wechseln Sie in der Google Cloud Console zur Seite Ressourcen verwalten.
- Wählen Sie in der Projektliste das Projekt aus, das Sie löschen möchten, und klicken Sie dann auf Löschen.
- 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:
Ingress-Ressource löschen:
kubectl delete -f ingress.yaml
Verwaltetes Zertifikat löschen:
kubectl delete -f managed-cert.yaml
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.
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
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]
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].
Löschen Sie den GKE-Cluster:
gcloud container clusters delete $CLUSTER_NAME --zone $CLUSTER_LOCATION
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.
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center