Multi-Cluster-Mesh-Netzwerk in GKE einrichten

In dieser Anleitung wird erläutert, wie Sie zwei Cluster mit Mesh CA oder Istio CA zu einem einzigen Anthos Service Mesh zusammenführen und das clusterübergreifende Load-Balancing aktivieren. Sie können diesen Prozess problemlos erweitern, um eine beliebige Anzahl von Clustern in Ihr Mesh-Netzwerk einzubinden.

Eine Anthos Service Mesh-Konfiguration mit mehreren Clustern kann in mehreren wichtigen Unternehmensszenarien wie Skalierung, Standortwahl und Isolation eine Lösung sein. Weitere Informationen finden Sie unter Multi-Cluster-Anwendungsfälle.

Vorbereitung

In dieser Anleitung wird davon ausgegangen, dass Sie mindestens zwei Google Cloud-GKE-Cluster haben, die folgende Anforderungen erfüllen:

• Anthos Service Mesh Version 1.11 oder höher wurde in den Clustern mit asmcli install installiert. Sie benötigen asmcli, das istioctl-Tool und Beispiele, die asmcli in das Verzeichnis herunterlädt, das Sie bei der Ausführung von asmcli install in --output_dir angegeben haben. Wenn Sie die Einrichtung vornehmen müssen, führen Sie die Schritte unter Abhängige Tools installieren und Cluster validieren aus, um Folgendes zu tun:

  • Erforderliche Tools installieren
  • asmcli herunterladen
  • Clusteradministratorberechtigungen erteilen
  • Projekt und Cluster validieren

• Cluster in Ihrem Mesh-Netzwerk müssen eine Verbindung zwischen allen Pods haben, bevor Sie Anthos Service Mesh konfigurieren. Wenn Sie Cluster zusammenführen, die sich nicht im selben Projekt befinden, müssen diese im selben Flotten-Hostprojekt registriert sein und die Cluster müssen sich in einer freigegebenen VPC-Konfiguration befinden, die sich zusammen im selben Netzwerk befinden. Außerdem empfehlen wir, ein Projekt zum Hosten der freigegebenen VPC und zwei Dienstprojekte zum Erstellen von Clustern zu haben. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.

• Wenn Sie die Istio-Zertifizierungsstelle nutzen, verwenden Sie für beide Cluster dasselbe benutzerdefinierte Root-Zertifikat.

• Wenn Ihr Anthos Service Mesh auf privaten Clustern basiert, empfehlen wir das Erstellen eines einzelnen Subnetzes in derselben VPC. Andernfalls muss Folgendes gewährleistet sein:

  1. Die Steuerungsebenen können die Steuerungsebenen für private Remote-Cluster über die privaten IP-Adressen von Clustern erreichen.
  2. Sie können den autorisierten Netzwerken der privaten Remote-Cluster IP-Adressbereiche der aufrufenden Steuerungsebenen hinzufügen. Weitere Informationen finden Sie unter Endpunkterkennung zwischen privaten Clustern konfigurieren.

• Der API-Server muss von den anderen Instanzen der Anthos Service Mesh-Steuerungsebene im Multi-Cluster-Mesh aus erreichbar sein.

  • Für die Cluster muss der globale Zugriff aktiviert sein.
  • Prüfen Sie, ob die IP-Adresse der Anthos Service Mesh-Steuerungsebene über die Zulassungsliste des autorisierten Master-Netzwerks ordnungsgemäß zugelassen wurde.

Projekt- und Clustervariablen festlegen

1. Erstellen Sie die folgenden Umgebungsvariablen für die Projekt-ID, die Clusterzone oder -region, den Clusternamen und den Kontext.

   export PROJECT_1=PROJECT_ID_1
   export LOCATION_1=CLUSTER_LOCATION_1
   export CLUSTER_1=CLUSTER_NAME_1
   export CTX_1="gke_${PROJECT_1}_${LOCATION_1}_${CLUSTER_1}"
   
   export PROJECT_2=PROJECT_ID_2
   export LOCATION_2=CLUSTER_LOCATION_2
   export CLUSTER_2=CLUSTER_NAME_2
   export CTX_2="gke_${PROJECT_2}_${LOCATION_2}_${CLUSTER_2}"
   

2. Wenn es sich um neu erstellte Cluster handelt, müssen Sie mit den folgenden gcloud-Befehlen Anmeldedaten für jeden Cluster abrufen. Andernfalls ist der zugehörige context nicht für die nächsten Schritte dieser Anleitung verfügbar:

   Die Befehle hängen vom Clustertyp ab, entweder regional oder zonal:

   Regional

   gcloud container clusters get-credentials ${CLUSTER_1} --region ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --region ${LOCATION_2}
   

   Zonal

   gcloud container clusters get-credentials ${CLUSTER_1} --zone ${LOCATION_1}
   gcloud container clusters get-credentials ${CLUSTER_2} --zone ${LOCATION_2}
   

Firewallregel erstellen

In einigen Fällen müssen Sie eine Firewallregel erstellen, um clusterübergreifenden Traffic zuzulassen. In folgenden Fällen müssen Sie beispielsweise eine Firewallregel erstellen:

• Sie verwenden unterschiedliche Subnetze für die Cluster in Ihrem Mesh-Netzwerk.
• Ihre Pods öffnen andere Ports als 443 und 15002.

GKE fügt jedem Knoten automatisch Firewallregeln hinzu, die Traffic innerhalb eines Subnetzes zulassen. Wenn Ihr Mesh-Netzwerk mehrere Subnetze enthält, müssen Sie die Firewallregeln explizit so einrichten, dass subnetzübergreifender Traffic zulässig ist. Sie müssen dabei für jedes Subnetz eine neue Firewallregel hinzufügen, die die CIDR-Blöcke der Quell-IP-Adresse und die Zielports des gesamten eingehenden Traffics zulässt.

Die folgende Anleitung ermöglicht die Kommunikation zwischen allen Clustern in Ihrem Projekt oder nur zwischen $CLUSTER_1 und $CLUSTER_2.

1. Sammeln Sie Informationen zum Netzwerk Ihres Clusters.

   Alle Projektcluster

   Wenn sich die Cluster im selben Projekt befinden, können Sie den folgenden Befehl verwenden, um die Kommunikation zwischen allen Clustern in Ihrem Projekt zuzulassen. Wenn in Ihrem Projekt Cluster enthalten sind, die Sie nicht verfügbar machen möchten, verwenden Sie den Befehl auf dem Tab Bestimmte Cluster.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(gcloud container clusters list --project $PROJECT_1 --format='value(clusterIpv4Cidr)' | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(gcloud compute instances list --project $PROJECT_1 --format='value(tags.items.[0])' | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

   Bestimmte Cluster

   Der folgende Befehl ermöglicht die Kommunikation zwischen $CLUSTER_1 und $CLUSTER_2 und macht keine anderen Cluster in Ihrem Projekt verfügbar.

   function join_by { local IFS="$1"; shift; echo "$*"; }
   ALL_CLUSTER_CIDRS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P container clusters list --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(clusterIpv4Cidr)'; done | sort | uniq)
   ALL_CLUSTER_CIDRS=$(join_by , $(echo "${ALL_CLUSTER_CIDRS}"))
   ALL_CLUSTER_NETTAGS=$(for P in $PROJECT_1 $PROJECT_2; do gcloud --project $P compute instances list  --filter="name:($CLUSTER_1,$CLUSTER_2)" --format='value(tags.items.[0])' ; done | sort | uniq)
   ALL_CLUSTER_NETTAGS=$(join_by , $(echo "${ALL_CLUSTER_NETTAGS}"))
   

2. Firewallregel erstellen

   GKE

   gcloud compute firewall-rules create istio-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --direction=INGRESS \
       --priority=900 \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags="${ALL_CLUSTER_NETTAGS}" --quiet \
       --network=YOUR_NETWORK
   

   Autopilot

   TAGS=""
   for CLUSTER in ${CLUSTER_1} ${CLUSTER_2}
   do
       TAGS+=$(gcloud compute firewall-rules list --filter="Name:$CLUSTER*" --format="value(targetTags)" | uniq) && TAGS+=","
   done
   TAGS=${TAGS::-1}
   echo "Network tags for pod ranges are $TAGS"
   
   gcloud compute firewall-rules create asm-multicluster-pods \
       --allow=tcp,udp,icmp,esp,ah,sctp \
       --network=gke-cluster-vpc \
       --direction=INGRESS \
       --priority=900 --network=VPC_NAME \
       --source-ranges="${ALL_CLUSTER_CIDRS}" \
       --target-tags=$TAGS
   

Endpunkterkennung konfigurieren

Hinweis: Weitere Informationen zur Endpunkterkennung finden Sie unter Endpunkterkennung mit mehreren Steuerungsebenen.

Die Schritte, die zum Konfigurieren der Endpunkterkennung erforderlich sind, hängen davon ab, ob Sie die deklarative API clusterübergreifend in einer Flotte verwenden oder manuell in öffentliche Clustern oder privaten Clustern aktivieren.

Warnung: Wenn die Endpunkterkennung zwischen Clustern aktiviert ist, können Dienste zwischen Clustern ohne ordnungsgemäße DNS-Konfiguration nicht miteinander kommunizieren. Dies liegt daran, dass GKE-Dienste für das Traffic-Routing vom voll qualifizierten Domainnamen (FQDN) der einzelnen Dienste abhängen. Sie können den DNS-Proxy aktivieren, um die Erkennung zwischen Clustern zu ermöglichen. Der DNS-Proxy erfasst alle DNS-Anfragen und löst sie mit Informationen aus der Steuerungsebene.

Endpunkterkennung zwischen öffentlichen oder privaten Clustern mit deklarativer API aktivieren (Vorabversion)

Vorschau — Enable endpoint discovery

Diese Funktion unterliegt den „Nutzungsbedingungen für Pre-GA-Angebote“ im Abschnitt „Allgemeine Nutzungsbedingungen“ der dienstspezifischen Nutzungsbedingungen. Pre-GA-Funktionen sind „wie besehen“ verfügbar und werden möglicherweise nur eingeschränkt unterstützt. Weitere Informationen finden Sie in den Beschreibungen der Startphase.

Sie können die Endpunkterkennung für öffentliche oder private Cluster in einer Flotte aktivieren. Wenden Sie dazu die Konfiguration "multicluster_mode":"connected" in der asm-options-Konfigurationsmap an. Bei Clustern mit aktivierter Konfiguration in derselben Flotte ist die clusterübergreifende Diensterkennung automatisch untereinander aktiviert.

Warnung: Verwenden Sie diese Methode nicht, wenn Ihre Cluster bereits vorhandene clusterinterne Remote-Secrets verwenden.

Diese Methode ist für verwaltete Anthos Service Mesh-Installationen auf allen Releasekanälen verfügbar. Dies ist auch die bevorzugte Methode zum Konfigurieren der Multi-Cluster-Endpunkterkennung, wenn Sie beim Erstellen eines neuen GKE-Cluster in der Google Cloud Console ein verwaltetes Anthos Service Mesh mit dem Feature Anthos Service Mesh aktivieren bereitgestellt haben.

Bevor Sie fortfahren, müssen Sie eine Firewallregel erstellt haben.

Bei mehreren Projekten müssen Sie FLEET_PROJECT_ID.svc.id.goog zu trustDomainAliases manuell in der meshConfig der Überarbeitung hinzufügen, falls noch nicht vorhanden.

Aktivieren

Wenn die asm-options-Konfigurationsmap bereits in Ihrem Cluster vorhanden ist, aktivieren Sie die Endpunkterkennung für den Cluster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'

Wenn die asm-options-Konfigurationsmap noch nicht in Ihrem Cluster vorhanden ist, erstellen Sie sie mit den zugehörigen Daten und aktivieren Sie die Endpunkterkennung für den Cluster:

kubectl --context ${CTX_1} create configmap asm-options -n istio-system --from-file <(echo '{"data":{"multicluster_mode":"connected"}}')

Deaktivieren

Deaktivieren Sie die Endpunkterkennung für einen Cluster:

kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"manual"}}'

Wenn Sie die Registrierung eines Clusters bei der Flotte aufheben, ohne die Endpunkterkennung zu deaktivieren, können Secrets im Cluster verbleiben. Sie müssen die verbleibenden Secrets manuell bereinigen.

1. Führen Sie den folgenden Befehl aus, um Secrets zu finden, die bereinigt werden müssen:

   kubectl get secrets -n istio-system -l istio.io/owned-by=mesh.googleapis.com,istio/multiCluster=true
   

2. Löschen Sie jedes Secret:

   kubectl delete secret SECRET_NAME
   

   Wiederholen Sie diesen Schritt für jedes verbleibende Secret.

Endpunkterkennung zwischen öffentlichen Clustern konfigurieren

Zum Konfigurieren der Endpunkterkennung zwischen GKE-Clustern führen Sie asmcli create-mesh aus. Dieser Befehl:

• Registriert alle Cluster in derselben Flotte
• Konfiguriert das Mesh-Netzwerk so, dass der Workload Identity der Flotte vertraut wird
• Erstellt Remote-Secrets

Sie können entweder den URI für jeden Cluster oder den Pfad zur kubeconfig-Datei angeben.

Cluster-URI

Ersetzen Sie im folgenden Befehl FLEET_PROJECT_ID durch die Projekt-ID des Flottenhostprojekts und den Cluster-URI durch den Clusternamen, die Zone oder Region und die Projekt-ID für jeden Cluster. In diesem Beispiel werden nur zwei Cluster gezeigt. Sie können jedoch den Befehl ausführen, um die Endpunkterkennung auf zusätzlichen Clustern zu aktivieren. Dabei gilt die maximal zulässige Anzahl von Clustern, die Sie Ihrer Flotte hinzufügen können..

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    ${PROJECT_1}/${LOCATION_1}/${CLUSTER_1} \
    ${PROJECT_2}/${LOCATION_2}/${CLUSTER_2}

kubeconfig-Datei

Ersetzen Sie im folgenden Befehl FLEET_PROJECT_ID durch die Projekt-ID des Flottenhostprojekts und PATH_TO_KUBECONFIG durch den Pfad zu jeder kubeconfig-Datei. In diesem Beispiel werden nur zwei Cluster gezeigt. Sie können jedoch den Befehl ausführen, um die Endpunkterkennung auf zusätzlichen Clustern zu aktivieren. Dabei gilt die maximal zulässige Anzahl von Clustern, die Sie Ihrer Flotte hinzufügen können.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2

Endpunkterkennung zwischen privaten Clustern konfigurieren

1. Konfigurieren Sie Remote-Secrets, um API-Serverzugriff auf den Cluster auf die Anthos Service Mesh-Steuerungsebene des anderen Clusters zu ermöglichen. Die Befehle hängen von Ihrem Anthos Service Mesh-Typ (entweder im Cluster oder verwaltet) ab:

   Hinweis: Führen Sie die folgenden Befehle unbedingt mit dem istioctl an dem --output_dir-Speicherort aus, den Sie beim Ausführen von asmcli install angegeben haben. Führen Sie dazu istioctl-Befehle auf ../output_dir/istioctl aus.

   A. Für Anthos Service Mesh im Cluster müssen Sie die privaten IP-Adressen anstelle der öffentlichen IP-Adressen konfigurieren, da die öffentlichen IP-Adressen nicht zugänglich sind:

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PRIV_IP} > ${CTX_1}.secret
   

   PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PRIV_IP} > ${CTX_2}.secret
   

   B. Für Managed Anthos Service Mesh:

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
    --zone "${LOCATION_1}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1} --server=https://${PUBLIC_IP} > ${CTX_1}.secret
   

   PUBLIC_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
    --zone "${LOCATION_2}" --format "value(privateClusterConfig.publicEndpoint)"`
   
   ./istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2} --server=https://${PUBLIC_IP} > ${CTX_2}.secret
   

2. Wenden Sie die neuen Secrets auf die Cluster an:

   kubectl apply -f ${CTX_1}.secret --context=${CTX_2}
   

   kubectl apply -f ${CTX_2}.secret --context=${CTX_1}
   

Autorisierte Netzwerke für private Cluster konfigurieren

Führen Sie die Schritte dieses Abschnitts nur aus, wenn die folgenden Bedingungen für Ihr Mesh-Netzwerk zutreffen:

• Sie verwenden private Cluster.
• Die Cluster gehören nicht zum selben Subnetz.
• Für die Cluster sind autorisierte Netzwerke aktiviert.

Wenn Sie mehrere private Cluster bereitstellen, muss die Anthos Service Mesh-Steuerungsebene in jedem Cluster die GKE-Steuerungsebene der Remote-Cluster aufrufen. Um Traffic zuzulassen, müssen Sie den autorisierten Netzwerken der Remote-Cluster den Pod-Adressbereich im aufrufenden Cluster hinzufügen.

1. Rufen Sie den CIDR-Block des Pod-IP-Adressbereichs für jeden Cluster ab:

   POD_IP_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

   POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
     --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

2. Fügen Sie den Remote-Clustern die CIDR-Blöcke des Pod-IP-Adressbereichs im Kubernetes-Clusters hinzu:

   EXISTING_CIDR_1=`gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_2},${EXISTING_CIDR_1//;/,}
   

   EXISTING_CIDR_2=`gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
   --enable-master-authorized-networks \
   --master-authorized-networks ${POD_IP_CIDR_1},${EXISTING_CIDR_2//;/,}
   

   Weitere Informationen finden Sie unter Cluster mit autorisierten Netzwerken erstellen.

3. Prüfen Sie, ob die autorisierten Netzwerke aktualisiert wurden:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

Globalen Zugriff auf Steuerungsebene aktivieren

Führen Sie die Schritte dieses Abschnitts nur aus, wenn die folgenden Bedingungen für Ihr Mesh-Netzwerk zutreffen:

• Sie verwenden private Cluster.
• Sie verwenden unterschiedliche Subnetze für die Cluster in Ihrem Mesh-Netzwerk.

Sie müssen den globalen Zugriff auf Steuerungsebene aktivieren, damit die Anthos Service Mesh-Steuerungsebene in jedem Cluster die GKE-Steuerungsebene der Remote-Cluster aufrufen kann.

1. Globalen Zugriff auf Steuerungsebene aktivieren

   gcloud container clusters update ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1} \
    --enable-master-global-access
   

   gcloud container clusters update ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2} \
    --enable-master-global-access
   

2. Prüfen Sie, ob der globale Zugriff auf die Steuerungsebene aktiviert ist:

   gcloud container clusters describe ${CLUSTER_1} --project ${PROJECT_1} --zone ${LOCATION_1}
   

   gcloud container clusters describe ${CLUSTER_2} --project ${PROJECT_2} --zone ${LOCATION_2}
   

   Im Abschnitt privateClusterConfig wird in der Ausgabe der Status masterGlobalAccessConfig angezeigt.

Multicluster-Konnektivität prüfen

Plattformhinweis: Diese Schritte gelten nur, wenn Sie eine clusterinterne Steuerungsebene verwenden. Informationen zum verwalteten Anthos Service Mesh finden Sie unter Sidecar-Proxys einfügen oder Verwaltete Datenebene anwenden.

In diesem Abschnitt wird erläutert, wie Sie die Beispieldienste HelloWorld und Sleep in Ihrer Multi-Cluster-Umgebung bereitstellen, um zu überprüfen, ob das clusterübergreifende Load-Balancing funktioniert.

Hinweis: Diese Beispieldienste befinden sich im Looker-Verzeichnis samples im istioctl-Tarball (in OUTPUT_DIR/istio-${ASM_VERSION%+*}/samples) und nicht im samples-Verzeichnis, das von asmcli (unter OUTPUT_DIR/samples) heruntergeladen wurde.

Variable für Beispielverzeichnis festlegen

1. Gehen Sie zu dem Speicherort, an dem asmcli heruntergeladen wurde, und führen Sie den folgenden Befehl aus, um ASM_VERSION festzulegen:

   export ASM_VERSION="$(./asmcli --version)"
   

2. Legen Sie einen Arbeitsordner für die Beispiele fest, mit denen Sie prüfen, ob das clusterübergreifende Load-Balancing funktioniert. Die Beispiele befinden sich in einem Unterverzeichnis im Verzeichnis --output_dir, das Sie im Befehl asmcli install angegeben haben. Ändern Sie im folgenden Befehl OUTPUT_DIR in das Verzeichnis, das Sie in --output_dir angegeben haben.

   export SAMPLES_DIR=OUTPUT_DIR/istio-${ASM_VERSION%+*}
   

Sidecar-Injektion aktivieren

1. Suchen Sie den Wert des Überarbeitungslabels, den Sie in späteren Schritten verwenden. Der Schritt hängt von Ihrem Anthos Service Mesh-Typ ab (verwaltet oder im Cluster).

   Hinweis: Wenn Ihre Cluster jeweils unterschiedliche Versionen von Anthos Service Mesh haben, müssen Sie für jeden Cluster den folgenden Befehl ausführen.

   Verwaltet

   Ermitteln Sie mit folgendem Befehl das Überarbeitungslabel, das Sie in späteren Schritten verwenden werden.

   kubectl get controlplanerevision -n istio-system

   Die Ausgabe sieht dann ungefähr so aus:

    NAME                RECONCILED   STALLED   AGE
    asm-managed-rapid   True         False     89d
    

   Notieren Sie sich den Wert des Überarbeitungslabels in der Ausgabe, in der Spalte NAME. In diesem Beispiel ist der Wert asm-managed-rapid Verwenden Sie den Überarbeitungswert in den Schritten im nächsten Abschnitt.

   Clusterintern

   Ermitteln Sie mit folgendem Befehl das Überarbeitungslabel, das Sie in späteren Schritten verwenden werden.

   kubectl -n istio-system get pods -l app=istiod --show-labels

   Die Ausgabe sieht dann ungefähr so aus:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-173-3-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-173-3-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-173-3,istio=istiod,pod-template-hash=5788d57586
    

   Notieren Sie sich den Wert des Überarbeitungslabels istiod aus der Ausgabe in der Spalte LABELS, das auf das Präfix istio.io/rev= folgt. In diesem Beispiel ist der Wert asm-173-3. Verwenden Sie den Überarbeitungswert in den Schritten im nächsten Abschnitt.

HelloWorld-Dienst installieren

Hinweis: Im Beispiel HelloWorld wird Docker Hub verwendet. In einem privaten Cluster kann die Containerlaufzeit Container-Images standardmäßig aus Artifact Registry abrufen. Die Containerlaufzeit kann keine Images aus einer anderen Container-Image-Registry im Internet abrufen. Sie können das Image herunterladen und in Artifact Registry hochladen oder Cloud NAT verwenden, um ausgehenden Internetzugriff für bestimmte private Knoten bereitzustellen. Weitere Informationen finden Sie unter Externe Container migrieren und Private Cluster erstellen.

1. Erstellen Sie den Beispiel-Namespace und die Dienstdefinition in jedem Cluster. Ersetzen Sie im folgenden Befehl REVISION durch das Überarbeitungslabel istiod, das Sie im vorherigen Schritt notiert haben.

   Wichtig: Wenn Sie die von Anthos Service Mesh verwaltete Steuerungsebene verwenden, ersetzen Sie in den folgenden Schritten REVISION durch asm-managed.

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl create --context=${CTX} namespace sample
       kubectl label --context=${CTX} namespace sample \
           istio-injection- istio.io/rev=REVISION --overwrite
   done
   

   Dabei ist REVISION das Versionslabel istiod, das Sie zuvor notiert haben.

   Die Ausgabe sieht so aus:

   label "istio-injection" not found.
   namespace/sample labeled
   

   Sie können label "istio-injection" not found. ignorieren.

2. Erstellen Sie in beiden Clustern den HelloWorld-Dienst:

   kubectl create --context=${CTX_1} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

   kubectl create --context=${CTX_2} \
       -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
       -l service=helloworld -n sample
   

HelloWorld v1 und v2 in jedem Cluster bereitstellen

1. Stellen Sie HelloWorld v1 in CLUSTER_1 und v2 in CLUSTER_2 bereit. Das erleichtert später die Prüfung des clusterübergreifenden Load-Balancings.

   kubectl create --context=${CTX_1} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${SAMPLES_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v2 -n sample

2. Prüfen Sie mit den folgenden Befehlen, ob HelloWorld v1 und v2 ausgeführt werden. Prüfen Sie, ob die Ausgabe in etwa so aussieht:

   kubectl get pod --context=${CTX_1} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v1-86f77cd7bd-cpxhv  2/2       Running   0          40s

   kubectl get pod --context=${CTX_2} -n sample

   NAME                            READY     STATUS    RESTARTS   AGE
   helloworld-v2-758dd55874-6x4t8  2/2       Running   0          40s

Sleep-Dienst bereitstellen

1. Stellen Sie den Sleep-Dienst in beiden Clustern bereit. Dieser Pod generiert künstlichen Netzwerktraffic zur Veranschaulichung:

   for CTX in ${CTX_1} ${CTX_2}
   do
       kubectl apply --context=${CTX} \
           -f ${SAMPLES_DIR}/samples/sleep/sleep.yaml -n sample
   done
   

2. Warten Sie, bis der Sleep-Dienst in jedem Cluster gestartet wurde. Prüfen Sie, ob die Ausgabe in etwa so aussieht:

   kubectl get pod --context=${CTX_1} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-n6bzf           2/2     Running   0          5s

   kubectl get pod --context=${CTX_2} -n sample -l app=sleep

   NAME                             READY   STATUS    RESTARTS   AGE
   sleep-754684654f-dzl9j           2/2     Running   0          5s

Clusterübergreifendes Load-Balancing prüfen

Rufen Sie den HelloWorld-Dienst mehrmals auf und prüfen Sie die Ausgabe, um abwechselnde Antworten von v1 und v2 zu prüfen:

1. Rufen Sie den Dienst HelloWorld auf:

   kubectl exec --context="${CTX_1}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_1}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Die Ausgabe sollte in etwa so aussehen:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

2. Rufen Sie den Dienst HelloWorld noch einmal auf:

   kubectl exec --context="${CTX_2}" -n sample -c sleep \
       "$(kubectl get pod --context="${CTX_2}" -n sample -l \
       app=sleep -o jsonpath='{.items[0].metadata.name}')" \
       -- /bin/sh -c 'for i in $(seq 1 20); do curl -sS helloworld.sample:5000/hello; done'
   

   Die Ausgabe sollte in etwa so aussehen:

   Hello version: v2, instance: helloworld-v2-758dd55874-6x4t8
   Hello version: v1, instance: helloworld-v1-86f77cd7bd-cpxhv
   ...

Sie haben Ihr Anthos Service Mesh mit Load-Balancing und mehreren Clustern geprüft.

HelloWorld-Dienst bereinigen

Entfernen Sie nach der Prüfung des Load-Balancings die Dienste HelloWorld und Sleep aus dem Cluster.

kubectl delete ns sample --context ${CTX_1}
kubectl delete ns sample --context ${CTX_2}