GKE-Cluster zu einem Anthos Service Mesh hinzufügen

Beta

Dieses Produkt oder Feature unterliegt den Nutzungsbedingungen des Pre-GA-Angebots in den Nutzungsbedingungen der Google Cloud Platform. Pre-GA-Produkte und -Features werden eventuell nur eingeschränkt unterstützt. Änderungen an Pre-GA-Produkten und -Features sind möglicherweise nicht mit anderen Pre-GA--Versionen kompatibel. Weitere Informationen finden Sie unter Beschreibungen der Startphase.

In dieser Anleitung wird erläutert, wie Sie zwei Cluster mit Mesh CA oder Citadel 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. Darüber hinaus sollten Sie Ihre Anwendungen optimieren, um die Vorteile eines Service Mesh optimal zu nutzen. Weitere Informationen finden Sie unter Anwendung für Anthos Service Mesh vorbereiten.

Vorbereitung

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

• In den Clustern ist Anthos Service Mesh Version 1.6.8 oder höher installiert.
  • Wenn sich Ihre Cluster im selben Projekt befinden, finden Sie unter Installationsübersicht Informationen zur Installation oder Aktualisierung Ihrer Cluster auf die erforderliche Version.
  • Wenn sich Ihre Cluster in verschiedenen Projekten befinden, lesen Sie Installation und Migration für mehrere Projekte, um Ihre Cluster zu installieren oder auf die erforderliche Version zu aktualisieren.
• Wenn Sie Cluster zusammenführen, die sich nicht im selben Projekt befinden, müssen sie mit dem Profil asm-gcp-multiproject installiert werden. Die Cluster müssen sich zusammen im selben Netzwerk in einer Konfiguration mit freigegebener VPC befinden. Außerdem empfehlen wir, dass Sie ein Projekt zum Hosten der freigegebenen VPC und zwei Dienstprojekte zum Erstellen von Clustern haben. Weitere Informationen finden Sie unter Cluster mit freigegebener VPC einrichten.
• Wenn Sie Citadel CA nutzen, verwenden Sie für beide Cluster dieselbe benutzerdefinierte Stamm-CA.
• 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.

Projekt- und Clustervariablen festlegen

1. Legen Sie einen Arbeitsordner fest. Dies ist der Ordner, in den Sie im vorherigen Schritt Installation von Anthos Service Mesh vorbereiten die Anthos Service Mesh-Dateien heruntergeladen haben.

   export PROJECT_DIR=YOUR_WORKING_FOLDER

2. Erstellen Sie für jeden Cluster eine Kontextvariable. Der Kontext ist ein String, der aus den Clusterprojekt-IDs, Clusternamen und Standorten erstellt wurde. Verwenden Sie für Standortwerte den Standort des Clusters, z. B. us-west2-a. In diesem Beispiel enthält ein Mesh-Netzwerk bereits einen Cluster und Sie fügen dem Mesh-Netzwerk einen weiteren Cluster hinzu:

   export CTX_1=gke_CLUSTER_1_PROJECT_ID_CLUSTER_1_LOCATION_CLUSTER_1_NAME
   export CTX_2=gke_CLUSTER_2_PROJECT_ID_CLUSTER_2_LOCATION_CLUSTER_2_NAME

Endpunkterkennung zwischen Clustern konfigurieren

Hinweis: Wenn Sie private Cluster nutzen, finden Sie entsprechende Informationen unter Endpunkterkennung zwischen privaten Clustern konfigurieren.

Konfigurieren Sie mit den folgenden Befehlen die Endpunkterkennung für das clusterübergreifende Load-Balancing. Mit diesem Schritt werden folgende Aufgaben ausgeführt:

• Mit dem Befehl istioctl wird ein Secret erstellt, das Zugriff auf den Kube API-Server für einen Cluster gewährt.
• Mit dem Befehl kubectl wird das Secret auf einen anderen Cluster angewendet, sodass der zweite Cluster Dienstendpunkte vom ersten lesen kann.

Hinweis: Für diese Schritte ist das istioctl-Befehlszeilentool erforderlich. Informationen zu seiner Installation finden Sie unter Installationsdatei herunterladen.

istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} | \
  kubectl apply -f - --context=${CTX_2}

istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} | \
  kubectl apply -f - --context=${CTX_1}

Hinweis: Sie können weitere Cluster hinzufügen, indem Sie das in diesem Verfahren beschriebene Muster erweitern. Erstellen Sie beispielsweise mehrere Kontexte (einen pro Cluster), erstellen Sie dann weitere Secrets und wenden Sie diese an. Achten Sie dabei darauf, dass zwischen jedem Cluster ein Secret vorhanden ist.

Endpunkterkennung zwischen privaten Clustern konfigurieren

Wenn Sie private Cluster nutzen, müssen Sie die privaten IP-Adressen der Remote-Cluster anstelle der öffentlichen IP-Adressen konfigurieren, da nicht auf die öffentlichen IP-Adressen zugegriffen werden kann.

Hinweis: Für diese Schritte ist das istioctl-Befehlszeilentool erforderlich. Informationen zu seiner Installation finden Sie unter Installationsdatei herunterladen.

1. Schreiben Sie die Secrets mit öffentlichen IP-Adressen in temporäre Dateien:

   istioctl x create-remote-secret --context=${CTX_1} --name=${CLUSTER_1_NAME} > ${CTX_1}.secret
   

   istioctl x create-remote-secret --context=${CTX_2} --name=${CLUSTER_2_NAME} > ${CTX_2}.secret
   

2. Rufen Sie die privaten IP-Adressen für die privaten Cluster ab und ersetzen Sie die öffentlichen IP-Adressen durch die Secrets in den temporären Dateien:

   IFS="_" read -r -a VALS <<< ${CTX_1}
   PROJECT_1=${VALS[1]}
   LOCATION_1=${VALS[2]}
   CLUSTER_1=${VALS[3]}
   PRIV_IP=`gcloud container clusters describe "${CLUSTER_1}" --project "${PROJECT_1}" \
      --zone "${LOCATION_1}" --format "value(privateClusterConfig.privateEndpoint)"`
   sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_1}.secret
   

   IFS="_" read -r -a VALS <<< ${CTX_2}
   PROJECT_2=${VALS[1]}
   LOCATION_2=${VALS[2]}
   CLUSTER_2=${VALS[3]}
   PRIV_IP=`gcloud container clusters describe "${CLUSTER_2}" --project "${PROJECT_2}" \
      --zone "${LOCATION_2}" --format "value(privateClusterConfig.privateEndpoint)"`
   sed -i 's/server\:.*/server\: https:\/\/'"${PRIV_IP}"'/' ${CTX_2}.secret
   

3. 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 Cluster in Anthos Service Mesh bereitstellen, muss Istiod 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} --zone ${LOCATION_1} \
      --format "value(ipAllocationPolicy.clusterIpv4CidrBlock)"`
   

   POD_IP_CIDR_2=`gcloud container clusters describe ${CLUSTER_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} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_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} --zone ${LOCATION_2} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"`
   gcloud container clusters update ${CLUSTER_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} --zone ${LOCATION_1} \
    --format "value(masterAuthorizedNetworksConfig.cidrBlocks.cidrBlock)"
   

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

Ports für den subnetzübergreifenden Traffic auf privaten Clustern öffnen

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.
• 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.

Erstellen Sie die Firewallregeln:

TARGET_TAG_1=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_1}-[0-9a-z]*-master" --format 'value(targetTags)'`
NEW_FIREWALL_NAME_1=new_firewall_name_1

gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_1} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_2} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_1}

TARGET_TAG_2=`gcloud compute firewall-rules list --filter="name~gke-${CLUSTER_2}-[0-9a-z]*-master" --format "value(targetTags)"`
NEW_FIREWALL_NAME_2=new_firewall_name_2
gcloud compute firewall-rules create ${NEW_FIREWALL_NAME_2} \
    --action ALLOW \
    --direction INGRESS \
    --source-ranges ${POD_IP_CIDR_1} \
    --rules protocol:port[,protocol,port] \
    --target-tags ${TARGET_TAG_2}

wobei

• protocol:port ist der gewünschte Port und das zugehörige Protokoll, tcp oder udp.

Deployment prüfen

In diesem Abschnitt wird erläutert, wie Sie einen HelloWorld-Beispieldienst in Ihrer Multi-Cluster-Umgebung bereitstellen, um zu prüfen, ob das clusterübergreifende Load-Balancing funktioniert.

Sidecar-Injektion aktivieren

1. Verwenden Sie den folgenden Befehl, um den Wert des Überarbeitungslabels des Diensts istiod zu ermitteln, das Sie in späteren Schritten verwenden.

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

   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

Erstellen Sie den Beispiel-Namespace und die Dienstdefinition in jedem Cluster.

1. Erstellen Sie den Beispiel-Namespace in jedem Cluster:

   kubectl create --context=${CTX_1} namespace sample
   

   kubectl create --context=${CTX_2} namespace sample
   

2. Überschreiben Sie das Überarbeitungslabel:

   kubectl label --context=${CTX_1} namespace sample \
         istio-injection- istio.io/rev=REVISION --overwrite
   

   kubectl label --context=${CTX_2} namespace sample \
     istio-injection- istio.io/rev=REVISION --overwrite
   

   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.

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

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

   kubectl create --context=${CTX_2} \
       -f ${PROJECT_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 ${PROJECT_DIR}/samples/helloworld/helloworld.yaml \
     -l version=v1 -n sample

   kubectl create --context=${CTX_2} \
     -f ${PROJECT_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 ${PROJECT_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}')" \
       -- curl -sS helloworld.sample:5000/hello
   

   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}')" \
       -- curl -sS helloworld.sample:5000/hello
   

   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}