Google Kubernetes Engine-Pods mit automatischer Envoy-Injektion einrichten
Übersicht
In einem Service Mesh muss Ihr Anwendungscode Ihre Netzwerkkonfiguration nicht kennen. Stattdessen kommunizieren Ihre Anwendungen über eine Datenebene. Diese wird von einer Steuerungsebene konfiguriert, die das Dienstnetzwerk verwaltet. In dieser Anleitung ist Cloud Service Mesh Ihre Steuerungsebene und die Envoy-Sidecar-Datei. Proxys sind Ihre Datenebene.
Der von Google verwaltete Envoy-Sidecar-Injektor fügt Ihren Google Kubernetes Engine-Pods Envoy-Sidecar-Proxys hinzu. Wenn der Envoy-Sidecar-Injektor einen Proxy hinzufügt, wird der Proxy auch so eingestellt, dass er Anwendungstraffic verarbeitet Cloud Service Mesh für die Konfiguration.
Dieser Leitfaden führt Sie durch die einfache Einrichtung von Cloud Service Mesh mit Google Kubernetes Engine Diese Schritte sind die Grundlage, die Sie auf komplexere Anwendungsfälle erweitern können, z. B. ein Service Mesh, das sich über mehrere Google Kubernetes Engine-Cluster und potenziell auch Compute Engine-VMs erstreckt. Sie können auch diese Anleitung verwenden, wenn Sie Cloud Service Mesh mit freigegebene VPC konfigurieren.
Die Einrichtung umfasst Folgendes:
- GKE-Cluster für Arbeitslasten erstellen
- Envoy-Sidecar-Injektor installieren und Injektion aktivieren
- Beispielclient bereitstellen und Injektion prüfen
- Kubernetes-Dienst zum Testen bereitstellen
- Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren, um Traffic an den Testdienst weiterzuleiten
- Konfiguration durch Senden einer Anfrage vom Beispielclient an den Testdienst prüfen
Vorbereitung
Bevor Sie den Anleitungen in diesem Leitfaden folgen, führen Sie die unter Einrichtung von Service Routing APIs mit Envoy und proxylosen Workloads vorbereiten beschriebenen vorbereitenden Aufgaben aus.
Informationen zur unterstützten Envoy-Version finden Sie in den Versionshinweisen zu Cloud Service Mesh.
Zusätzliche Voraussetzungen für freigegebene VPCs
Wenn Sie Cloud Service Mesh in einer freigegebene VPC-Umgebung einrichten, stellen Sie Folgendes sicher.
- Sie haben die richtigen Berechtigungen und Rollen für die freigegebene VPC.
- Sie haben die richtigen Projekte und die Abrechnung eingerichtet.
- Sie haben die Abrechnung in den Projekten aktiviert.
- Sie haben die Cloud Service Mesh und die GKE API jeweils aktiviert einschließlich des Hostprojekts.
- Sie haben für jedes Projekt die richtigen Dienstkonten eingerichtet.
- Sie haben ein VPC-Netzwerk und Subnetze erstellt.
- Sie haben die freigegebene VPC aktiviert.
Weitere Informationen finden Sie unter Freigegebene VPC.
IAM-Rollen konfigurieren
In diesem Beispiel für die Konfiguration von IAM-Rollen wird davon ausgegangen, dass das Hostprojekt für die freigegebene VPC zwei Subnetze und dass es in der freigegebenen VPC zwei Dienstprojekte gibt.
Erstellen Sie in Cloud Shell einen Arbeitsordner (
WORKDIR)
, in dem Sie die mit diesem Abschnitt verknüpften Dateien erstellen:mkdir -p ~/td-shared-vpc cd ~/td-shared-vpc export WORKDIR=$(pwd)
Konfigurieren Sie IAM-Berechtigungen im Hostprojekt, damit Dienstprojekte die Ressourcen in der freigegebenen VPC verwenden können.
In diesem Schritt konfigurieren Sie die IAM-Berechtigungen, sodass Dienstprojekt 1 auf
subnet-1
und Dienstprojekt 2 aufsubnet-2
zugreifen kann. Sie weisen die IAM-Rolle „Compute-Netzwerknutzer“ (roles/compute.networkUser
) in jedem Dienstprojekt für jedes Subnetz sowohl dem Compute Engine-Standarddienstkonto als auch dem Google Cloud API-Dienstkonto zu.Konfigurieren Sie für Dienstprojekt 1 IAM-Berechtigungen für
subnet-1
:export SUBNET_1_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-1 --project ${HOST_PROJECT} --region ${REGION_1} --format=json | jq -r '.etag') cat > subnet-1-policy.yaml <<EOF bindings: - members: - serviceAccount:${SVC_PROJECT_1_API_SA} - serviceAccount:${SVC_PROJECT_1_GKE_SA} role: roles/compute.networkUser etag: ${SUBNET_1_ETAG} EOF gcloud beta compute networks subnets set-iam-policy subnet-1 \ subnet-1-policy.yaml \ --project ${HOST_PROJECT} \ --region ${REGION_1}
Konfigurieren Sie für Dienstprojekt 2 IAM-Berechtigungen für
subnet-2
:export SUBNET_2_ETAG=$(gcloud beta compute networks subnets get-iam-policy subnet-2 --project ${HOST_PROJECT} --region ${REGION_2} --format=json | jq -r '.etag') cat > subnet-2-policy.yaml <<EOF bindings: - members: - serviceAccount:${SVC_PROJECT_2_API_SA} - serviceAccount:${SVC_PROJECT_2_GKE_SA} role: roles/compute.networkUser etag: ${SUBNET_2_ETAG} EOF gcloud beta compute networks subnets set-iam-policy subnet-2 \ subnet-2-policy.yaml \ --project ${HOST_PROJECT} \ --region ${REGION_2}
Für jedes Dienstprojekt müssen Sie dem GKE-Dienstkonto im Hostprojekt die IAM-Rolle „Nutzer des Dienst-Agents für Kubernetes Engine-Host“ (
roles/container.hostServiceAgentUser
) zuweisen:gcloud projects add-iam-policy-binding ${HOST_PROJECT} \ --member serviceAccount:${SVC_PROJECT_1_GKE_SA} \ --role roles/container.hostServiceAgentUser gcloud projects add-iam-policy-binding ${HOST_PROJECT} \ --member serviceAccount:${SVC_PROJECT_2_GKE_SA} \ --role roles/container.hostServiceAgentUser
Damit kann das GKE-Dienstkonto des Dienstprojekts das GKE-Dienstkonto des Hostprojekts verwenden, um gemeinsam genutzte Netzwerkressourcen zu konfigurieren.
Weisen Sie für jedes Dienstprojekt den Compute Engine-Standarddienst zu Konto IAM-Rolle „Compute-Netzwerkbetrachter“ (
roles/compute.networkViewer
) im Hostprojekt.gcloud projects add-iam-policy-binding ${SVC_PROJECT_1} \ --member serviceAccount:${SVC_PROJECT_1_COMPUTE_SA} \ --role roles/compute.networkViewer gcloud projects add-iam-policy-binding ${SVC_PROJECT_2} \ --member serviceAccount:${SVC_PROJECT_2_COMPUTE_SA} \ --role roles/compute.networkViewer
Wenn der Envoy-Sidecar-Proxy eine Verbindung zum xDS verwendet (Traffic Director API), verwendet der Proxy das Dienstkonto des Compute Engine-VM-Host oder des GKE-Knoteninstanz. Das Dienstkonto muss die IAM-Berechtigung
compute.globalForwardingRules.get
auf Projektebene haben. Die Rolle "Compute-Netzwerkbetrachter" ist für diesen Schritt ausreichend.
Projektinformationen konfigurieren
Wenn Sie noch kein Google Cloud-Projekt erstellt oder die Google Cloud CLI nicht installiert haben, folgen Sie dieser Anleitung. Wenn Sie noch nicht installiert haben, folgen Sie dieser Anleitung.
# The project that contains your GKE cluster. export CLUSTER_PROJECT_ID=YOUR_CLUSTER_PROJECT_NUMBER_HERE # The name of your GKE cluster. export CLUSTER=YOUR_CLUSTER_NAME # The channel of your GKE cluster. Eg: rapid, regular, stable. This channel # should match the channel of your GKE cluster. export CHANNEL=YOUR_CLUSTER_CHANNEL # The location of your GKE cluster, Eg: us-central1 for regional GKE cluster, # us-central1-a for zonal GKE cluster export LOCATION=ZONE # The network name of the traffic director load balancing API. export MESH_NAME=default # The project that holds the mesh resources. export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE export TARGET=projects/${MESH_PROJECT_NUMBER}/global/networks/${MESH_NAME} gcloud config set project ${CLUSTER_PROJECT_ID}
Wenn Sie die neuen Dienstrouting-APIs verwenden, legen Sie anhand der folgenden Anleitung MESH_NAME
,
MESH_PROJECT_NUMBER
und TARGET
:
# The mesh name of the traffic director load balancing API. export MESH_NAME=YOUR_MESH_NAME # The project that holds the mesh resources. export MESH_PROJECT_NUMBER=YOUR_PROJECT_NUMBER_HERE export TARGET=projects/${MESH_PROJECT_NUMBER}/locations/global/meshes/${MESH_NAME}
In den meisten Szenarien beziehen sich CLUSTER_PROJECT_ID
und MESH_PROJECT_NUMBER
auf den
Projekt arbeiten. Wenn Sie jedoch die
in einem anderen Projekt verwenden, z. B. bei Verwendung einer freigegebene VPC,
CLUSTER_PROJECT_ID
bezieht sich auf die Projekt-ID, die Ihre GKE enthält
Cluster und MESH_PROJECT_NUMBER
bezieht sich auf die Projektnummer.
der die Ressourcen enthält.
Achten Sie darauf, dass Sie die erforderlichen Berechtigungen konfiguriert haben, damit der eingeschleuste Envoy Konfigurationen aus dem
Mesh Config API aktivieren
Aktivieren Sie die folgende API, um mit dem von Google verwalteten Sidecar-Injector zu beginnen.
gcloud services enable --project=${CLUSTER_PROJECT_ID} meshconfig.googleapis.com
GKE-Cluster für Arbeitslasten erstellen
GKE-Cluster müssen die folgenden Anforderungen erfüllen, um Cloud Service Mesh:
- Die Unterstützung von Netzwerk-Endpunktgruppen muss aktiviert sein. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.
- Das Dienstkonto für Ihre GKE-Knoten/-Pods muss Berechtigung für den Zugriff auf die Traffic Director API. Weitere Informationen zu den erforderlichen Berechtigungen, siehe Aktivieren Sie das Dienstkonto für den Zugriff auf die Traffic Director API.
GKE-Cluster erstellen
Erstellen Sie einen GKE-Cluster in Ihrer bevorzugten Zone, z. B. us-central1-a
.
gcloud container clusters create YOUR_CLUSTER_NAME \ --zone ZONE \ --scopes=https://www.googleapis.com/auth/cloud-platform \ --enable-ip-alias
kubectl auf den neu erstellten Cluster verweisen
Ändern Sie den aktuellen Kontext für kubectl
in den neu erstellten Cluster. Führen Sie dazu den folgenden Befehl aus:
gcloud container clusters get-credentials traffic-director-cluster \ --zone ZONE
Konfigurationen für Mutating Webhook anwenden
In den folgenden Abschnitten finden Sie eine Anleitung zum Anwenden der MutatingWebhookConfiguration auf den Cluster. Wenn ein Pod erstellt wird, wird der clusterinterne Admission Controller aufgerufen. Der Admission Controller kommuniziert mit dem verwalteten Sidecar-Injektor, um dem Pod den Envoy-Container hinzuzufügen.
Wenden Sie die folgenden Webhook-Konfigurationen für Mutationen auf Ihren Cluster an.
cat <<EOF | kubectl apply -f -
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
labels:
app: sidecar-injector
name: td-mutating-webhook
webhooks:
- admissionReviewVersions:
- v1beta1
- v1
clientConfig:
url: https://meshconfig.googleapis.com/v1internal/projects/${CLUSTER_PROJECT_ID}/locations/${LOCATION}/clusters/${CLUSTER}/channels/${CHANNEL}/targets/${TARGET}:tdInject
failurePolicy: Fail
matchPolicy: Exact
name: namespace.sidecar-injector.csm.io
namespaceSelector:
matchExpressions:
- key: td-injection
operator: Exists
reinvocationPolicy: Never
rules:
- apiGroups:
- ""
apiVersions:
- v1
operations:
- CREATE
resources:
- pods
scope: '*'
sideEffects: None
timeoutSeconds: 30
EOF
Sidecar-Injektion aktivieren
Mit dem folgenden Befehl wird die Injektion für den Namespace default
aktiviert. Der Sidecar-Injektor fügt Sidecar-Container in Pods ein, die unter diesem Namespace erstellt werden:
kubectl label namespace default td-injection=enabled
Mit dem folgenden Befehl können Sie prüfen, ob der Namespace default
richtig aktiviert ist:
kubectl get namespace -L td-injection
In diesem Fall sollte Folgendes zurückgegeben werden:
NAME STATUS AGE TD-INJECTION default Active 7d16h enabled
Wenn Sie die Dienstsicherheit für Cloud Service Mesh mit Envoy konfigurieren, kehren Sie zum Abschnitt Testdienst einrichten in dieser Einrichtungsanleitung zurück.
Beispielclient bereitstellen und Injektion prüfen
In diesem Abschnitt wird gezeigt, wie Sie einen Beispiel-Pod mit Busybox bereitstellen. Busybox bietet Ihnen eine einfache Schnittstelle zum Erreichen eines Testdienstes. In einer echten Bereitstellung würden Sie stattdessen Ihre eigene Clientanwendung bereitstellen.
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
run: client
name: busybox
spec:
replicas: 1
selector:
matchLabels:
run: client
template:
metadata:
labels:
run: client
spec:
containers:
- name: busybox
image: busybox
command:
- sh
- -c
- while true; do sleep 1; done
EOF
Der Busybox-Pod besteht aus zwei Containern. Der erste Container ist der Client, der auf dem Busybox-Image basiert, und der zweite Container ist der Envoy-Proxy, der vom Sidecar-Injektor eingefügt wird. Mit dem folgenden Befehl können Sie weitere Informationen zum Pod abrufen:
kubectl describe pods -l run=client
In diesem Fall sollte Folgendes zurückgegeben werden:
… Init Containers: # Istio-init sets up traffic interception for the pod. Istio-init: … Containers: # busybox is the client container that runs application code. busybox: … # Envoy is the container that runs the injected Envoy proxy. envoy: …
Cloud Service Mesh-Proxy
Der verwaltete Sidecar-Injektor verwendet das Cloud Service Mesh-Proxy-Image als über den Proxy. Der Cloud Service Mesh-Proxy ist ein Sidecar-Container, zum Starten eines Envoy-Proxys für Mesh-Instanzen. Das Proxy-Image verwendet das OSS Envoy-Image zusammen mit einem Proxy-Agent, der für den Start um die Bootstrap-Konfiguration und die Systemdiagnose Gesandter. Die Cloud Service Mesh-Proxy-Imageversionen entsprechen der OSS-Envoy-Version. Hier können Sie die verfügbaren Proxy-Images verfolgen: https://gcr.io/gke-release/asm/csm-mesh-proxy
Der Cloud Service Mesh-Proxy, der eingeschleust wird, hängt vom Channel, den der Nutzer für den GKE-Cluster ausgewählt hat. Der Gesang Version regelmäßig auf Basis der aktuellen OSS Envoy-Releases und wird mit dem jeweiligen GKE-Release getestet, Kompatibilität.
Cloud Service Mesh-Proxyversion
Die folgende Tabelle zeigt den aktuellen Kanal des GKE-Cluster für Versionszuordnung des Cloud Service Mesh-Proxys:
Kanal | Cloud Service Mesh-Proxyversion |
---|---|
Rapid | 1.29.9-gke.3 |
Regulär | 1.28.7-gke.3 |
Stabile Version | 1.27.7-gke.3 |
Cloud Service Mesh-Proxy-Upgrade
Wir empfehlen dringend, ein Upgrade auf die neueste Version durchzuführen. Obwohl der Service das Mesh-Netzwerk in Ordnung ist, wenn die Steuerungsebene und die Proxys unterschiedliche Versionen empfehlen wir, die Proxys zu aktualisieren, sodass sie mit die neue Cloud Service Mesh-Version.
Der verwaltete Sidecar-Injektor übernimmt die Version von Envoy, die immer fügt die neueste von Google qualifizierte Envoy-Version ein. Wenn die Cloud Service Mesh Proxy-Version neuer als die Proxyversion ist, starten Sie die Proxys für Ihre Dienste neu.
kubectl rollout restart deployment -n YOUR_NAMESPACE_HERE
Kubernetes-Dienst zum Testen bereitstellen
In den folgenden Abschnitten finden Sie eine Anleitung zum Einrichten eines Testdienstes, den Sie später in diesem Leitfaden verwenden, um eine End-to-End-Prüfung Ihrer Einrichtung zu ermöglichen.
GKE-Dienste mit NEGs konfigurieren
GKE-Dienste müssen über Netzwerk-Endpunktgruppen verfügbar gemacht werden
(NEGs), damit Sie sie als Back-Ends eines Cloud Service Mesh-Back-Ends konfigurieren können
Service. Fügen Sie der Kubernetes-Dienstspezifikation die NEG-Annotation hinzu und wählen Sie einen Namen aus, indem Sie NEG-NAME
im Beispiel unten ersetzen, damit Sie sie später leicht wiederfinden. Sie benötigen den Namen, wenn Sie die NEG an Ihre
Back-End-Dienst von Cloud Service Mesh. Weitere Informationen zum Annotieren von NEGs finden Sie unter NEGs benennen.
... metadata: annotations: cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "service-test-neg"}}}' spec: ports: - port: 80 name: service-test protocol: TCP targetPort: 8000
Diese Annotation erstellt eine Standalone-NEG mit Endpunkten, die den IP-Adressen und Ports der Dienst-Pods entsprechen. Weitere Informationen und Beispiele finden Sie unter Standalone-Netzwerk-Endpunktgruppen.
Der folgende Beispieldienst enthält die NEG-Annotation. Der Dienst stellt den Hostnamen über HTTP auf Port 80
bereit. Verwenden Sie den folgenden Befehl, um den Dienst abzurufen und im GKE-Cluster bereitzustellen.
wget -q -O - \ https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \ | kubectl apply -f -
Prüfen Sie, ob der neue Dienst erstellt wurde und der Anwendungs-Pod ausgeführt wird:
kubectl get svc
Die Ausgabe sollte in etwa so aussehen:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service-test ClusterIP 10.71.9.71 none 80/TCP 41m [..skip..]
Prüfen Sie, ob der mit diesem Dienst verknüpfte Anwendungs-Pod ausgeführt wird:
kubectl get pods
NAME READY STATUS RESTARTS AGE app1-6db459dcb9-zvfg2 2/2 Running 0 6m busybox-5dcf86f4c7-jvvdd 2/2 Running 0 10m [..skip..]
Name der NEG speichern
Suchen Sie die im obigen Beispiel erstellte NEG und notieren Sie sich ihren Namen für die Cloud Service Mesh-Konfiguration im nächsten Abschnitt.
gcloud compute network-endpoint-groups list
Es wird Folgendes zurückgegeben:
NAME LOCATION ENDPOINT_TYPE SIZE service-test-neg ZONE GCE_VM_IP_PORT 1
Speichern Sie den Namen der NEG in der Variable NEG_NAME:
NEG_NAME=$(gcloud compute network-endpoint-groups list \ | grep service-test | awk '{print $1}')
Cloud Service Mesh mit Cloud Load Balancing-Komponenten konfigurieren
In diesem Abschnitt wird Cloud Service Mesh mithilfe der Compute Engine-Last konfiguriert Ressourcen auszugleichen. Dadurch kann der Sidecar-Proxy des Beispielclients die Konfiguration von Cloud Service Mesh empfangen. Ausgehende Anfragen vom Beispielclient werden vom Sidecar-Proxy verarbeitet und an den Testdienst weitergeleitet.
Sie müssen die folgenden Komponenten konfigurieren:
- Systemdiagnose Weitere Informationen zu Systemdiagnosen finden Sie unter Konzepte der Systemdiagnose und Systemdiagnosen erstellen.
- Back-End-Dienst Weitere Informationen zu Back-End-Diensten finden Sie unter Back-End-Dienste.
- Eine Routingregelzuordnung: Dazu gehört das Erstellen einer Weiterleitungsregel, eines Ziel-HTTP-Proxys und einer URL-Zuordnung. Weitere Informationen finden Sie unter Weiterleitungsregeln für Cloud Service Mesh verwenden Zielproxys für Cloud Service Mesh verwenden und URL-Zuordnungen verwenden.
Systemdiagnose und Firewallregel erstellen
Folgen Sie der nachstehenden Anleitung, um eine Systemdiagnose und die Firewallregel zu erstellen. die für die Systemdiagnoseprüfungen erforderlich ist. Weitere Informationen finden sich unter Firewallregeln für Systemdiagnosen.
Console
- Rufen Sie in der Google Cloud Console die Seite "Systemdiagnosen" auf.
Zur Seite "Systemdiagnosen" - Klicken Sie auf Systemdiagnose erstellen.
- Geben Sie als Name
td-gke-health-check
ein. - Wählen Sie als Protokoll HTTP aus.
Klicken Sie auf Erstellen.
Rufen Sie in der Google Cloud Console die Seite Firewallrichtlinien auf.
Zur Seite „Firewallrichtlinien“Klicken Sie auf Firewallregeln erstellen.
Geben Sie auf der Seite Firewallregel erstellen die folgenden Informationen an:
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
fw-allow-health-checks
. - Netzwerk: Wählen Sie ein VPC-Netzwerk aus.
- Priorität: Geben Sie eine Zahl für die Priorität ein. Niedrigere Zahlen haben höhere Prioritäten. Achten Sie darauf, dass die Firewallregel eine höhere Priorität hat als andere Regeln, die möglicherweise eingehenden Traffic ablehnen.
- Traffic-Richtung: Wählen Sie Eingehend aus.
- Aktion bei Übereinstimmung: Wählen Sie Zulassen aus.
- Ziele: Wählen Sie Alle Instanzen im Netzwerk aus.
- Quellfilter: Wählen Sie den richtigen IP-Bereichstyp aus.
- Quell-IP-Bereiche:
35.191.0.0/16,130.211.0.0/22
- Zielfilter: Wählen Sie den IP-Typ aus.
- Protokolle und Ports: Klicken Sie auf Angegebene Ports und Protokolle.
prüfen Sie
tcp
. TCP ist das zugrunde liegende Protokoll für alle Systemdiagnose-Protokolle. - Klicken Sie auf Erstellen.
- Name: Geben Sie einen Namen für die Regel an. Verwenden Sie für dieses Beispiel
gcloud
Erstellen Sie die Systemdiagnose.
gcloud compute health-checks create http td-gke-health-check \ --use-serving-port
Erstellen Sie die Firewallregel, um IP-Adressbereiche für die Systemdiagnose zuzulassen.
gcloud compute firewall-rules create fw-allow-health-checks \ --action ALLOW \ --direction INGRESS \ --source-ranges 35.191.0.0/16,130.211.0.0/22 \ --rules tcp
Back-End-Dienst erstellen
Erstellen Sie einen globalen Backend-Dienst mit dem Load-Balancing-Schema INTERNAL_SELF_MANAGED
. In der Google Cloud Console wird das Load-Balancing-Schema implizit festgelegt. Binden Sie die Systemdiagnose in den Backend-Dienst ein.
Console
Rufen Sie in der Google Cloud Console die Seite „Cloud Service Mesh“ auf.
Klicken Sie auf dem Tab Dienste auf Dienst erstellen.
Klicken Sie auf Weiter.
Geben Sie als Dienstname
td-gke-service
ein.Wählen Sie Netzwerk aus, das Sie in der Cloud Service Mesh-ConfigMap konfiguriert haben.
Wählen Sie unter Back-End-Typ Netzwerk-Endpunktgruppen aus.
Wählen Sie die erstellte Netzwerk-Endpunktgruppe aus.
Legen Sie die Maximale Anzahl der Anfragen pro Sekunde auf
5
fest.Legen Sie den Balancing-Modus auf Rate fest.
Klicken Sie auf Fertig.
Wählen Sie unter Systemdiagnose
td-gke-health-check
aus. Dies ist die Systemdiagnose, die Sie erstellt haben.Klicken Sie auf Weiter.
gcloud
Erstellen Sie den Back-End-Dienst und verknüpfen Sie die Systemdiagnose mit dem Back-End-Dienst.
gcloud compute backend-services create td-gke-service \ --global \ --health-checks td-gke-health-check \ --load-balancing-scheme INTERNAL_SELF_MANAGED
Fügen Sie dem Back-End-Dienst die zuvor erstellte NEG als Back-End hinzu. Wenn Sie Cloud Service Mesh mit einem Ziel-TCP-Proxy konfigurieren, müssen Sie den Balancing-Modus
UTILIZATION
verwenden. Wenn Sie HTTP- oder HTTPS-Zielproxy verwenden, können Sie denRATE
-Modus verwenden.gcloud compute backend-services add-backend td-gke-service \ --global \ --network-endpoint-group ${NEG_NAME} \ --network-endpoint-group-zone ZONE \ --balancing-mode [RATE | UTILIZATION] \ --max-rate-per-endpoint 5
Routingregelzuordnung erstellen
Die Routingregelzuordnung definiert, wie Cloud Service Mesh Traffic in Ihrem Mesh-Netzwerk. Im Rahmen der Routingregelzuordnung konfigurieren Sie eine virtuelle IP-Adresse (VIP) und eine Reihe zugehöriger Trafficverwaltungsregeln, z. B. hostbasiertes Routing. Wenn eine Anwendung eine Anfrage an die VIP sendet, führt der angehängte Envoy-Sidecar-Proxy die folgenden Schritte aus:
- Fängt die Anfrage ab
- Bewertet die Anfrage in Übereinstimmung mit den Trafficverwaltungsregeln in der URL-Zuordnung
- Wählt einen Back-End-Dienst anhand des Hostnamens in der Anfrage aus
- Wählt ein Back-End oder einen Endpunkt aus, der dem ausgewählten Back-End-Dienst zugeordnet ist
- Sendet Traffic an dieses Back-End oder den Endpunkt
Console
In der Console wird der Zielproxy mit der Weiterleitungsregel kombiniert. Wenn Sie die Weiterleitungsregel erstellen, erstellt Google Cloud automatisch einen Ziel-HTTP-Proxy und verknüpft ihn mit der URL-Zuordnung.
Die Routingregel besteht aus der Weiterleitungsregel und den Host- und Pfadregeln (auch als URL-Zuordnung bezeichnet).
Rufen Sie in der Google Cloud Console die Seite „Cloud Service Mesh“ auf.
Klicken Sie auf Routingregelzuordnungen.
Klicken Sie auf Routingregel erstellen.
Geben Sie als Name der URL-Zuordnung
td-gke-url-map
ein.Klicken Sie auf Weiterleitungsregel hinzufügen.
Geben Sie als Name für die Weiterleitungsregel
td-gke-forwarding-rule
ein.Wählen Sie das Netzwerk aus.
Wählen Sie Ihre Interne IP-Adresse aus.
Klicken Sie auf Speichern.
Fügen Sie optional benutzerdefinierte Host- und Pfadregeln hinzu oder behalten Sie die Pfadregeln als Standard bei.
Legen Sie den Host auf
service-test
fest.Klicken Sie auf Speichern.
gcloud
Erstellen Sie eine URL-Zuordnung, die
td-gke-service
als Standard-Back-End-Dienst verwendet.gcloud compute url-maps create td-gke-url-map \ --default-service td-gke-service
Erstellen Sie ein Tool zum Abgleich von Pfaden für URL-Zuordnungen und eine Hostregel, um den Traffic für Ihren Dienst auf Grundlage des Hostnamens und Pfads weiterzuleiten. In diesem Beispiel werden
service-test
als Dienstname und ein Standardtool zum Abgleich von Pfaden verwendet, das mit allen Pfadanfragen für diesen Host (/*
) übereinstimmt.gcloud compute url-maps add-path-matcher td-gke-url-map \ --default-service td-gke-service \ --path-matcher-name td-gke-path-matcher gcloud compute url-maps add-host-rule td-gke-url-map \ --hosts service-test \ --path-matcher-name td-gke-path-matcher
Erstellen Sie den Ziel-HTTP-Proxy.
gcloud compute target-http-proxies create td-gke-proxy \ --url-map td-gke-url-map
Erstellen Sie die Weiterleitungsregel.
gcloud compute forwarding-rules create td-gke-forwarding-rule \ --global \ --load-balancing-scheme=INTERNAL_SELF_MANAGED \ --address=0.0.0.0 \ --target-http-proxy=td-gke-proxy \ --ports 80 --network default
An dieser Stelle konfiguriert Cloud Service Mesh Ihre Sidecar-Proxys so, dass sie Anfragen weiterleiten, die den Hostnamen service-test
für Back-Ends von td-gke-service
angeben. Dabei sind diese Back-Ends Endpunkte in der Netzwerk-Endpunktgruppe, die dem zuvor bereitgestellten Kubernetes-Testdienst zugeordnet ist.
Konfiguration prüfen
In diesem Abschnitt wird gezeigt, wie Sie prüfen, ob der vom Busybox-Beispielclient gesendete Traffic an Ihren Kubernetes-Dienst service-test
weitergeleitet wird. Zum Senden einer Testanfrage können Sie auf eine Shell in einem der Container zugreifen und den folgenden Prüfungsbefehl ausführen. Ein service-test
-Pod sollte den Hostnamen des Bereitstellungs-Pods zurückgeben.
# Get the name of the pod running Busybox. BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}') # Command to execute that tests connectivity to the service service-test at # the VIP 10.0.0.1. Because 0.0.0.0 is configured in the forwarding rule, this # can be any VIP. TEST_CMD="wget -q -O - 10.0.0.1; echo" # Execute the test command on the pod. kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"
So wird die Konfiguration geprüft:
- Der Beispielclient hat eine Anfrage gesendet, in der der Hostname
service-test
angegeben ist. - Der Beispielclient verfügt über einen Envoy-Sidecar-Proxy, der vom Envoy-Sidecar-Injektor eingefügt wurde.
- Der Sidecar-Proxy hat die Anfrage abgefangen.
- Envoy hat mithilfe der URL-Zuordnung den Hostnamen
service-test
mit demtd-gke-service
Cloud Service Mesh-Dienst. - Envoy hat einen Endpunkt aus der mit
td-gke-service
verknüpften Netzwerk-Endpunktgruppe ausgewählt. - Envoy hat die Anfrage an einen Pod gesendet, der mit dem Kubernetes-Dienst
service-test
verknüpft ist.
Migration zu Managed Sidecar Injector
In dieser Anleitung erfahren Sie, wie Sie eine Anwendung vom alten Cloud Service Mesh-Sidecar-Injektor in GKE (mit einem In-Cluster-Sidecar-Injektor) zu einem mit einem verwalteten Sidecar-Injektor migrieren.
Sidecar-Injektion im Cluster deaktivieren
Mit den folgenden Befehlen wird der alte Sidecar-Injektor im Cluster für den Standard-Namespace deaktiviert.
kubectl label namespace default istio-injection-
In-Cluster-Sidecar-Injektor bereinigen
Laden Sie den alten Envoy-Sidecar-Injektor herunter und extrahieren Sie ihn.
wget https://storage.googleapis.com/traffic-director/td-sidecar-injector-xdsv3.tgz tar -xzvf td-sidecar-injector-xdsv3.tgz cd td-sidecar-injector-xdsv3
Sidecar-Injektor-Ressourcen im Cluster löschen
kubectl delete -f specs/
Nächste Schritte
- Weitere Informationen zur Erweiterten Trafficverwaltung.
- Sicherheit von Cloud Service Mesh-Diensten
- Beobachtbarkeit mit Envoy einrichten.
- Informationen zur Fehlerbehebung bei Cloud Service Mesh-Bereitstellungen
- Optionen für die Einrichtung des Google Kubernetes Engine-Pods mit automatischer Envoy-Einfügung.