Dieser Artikel wurde vom Autor aus der Huawei Cloud Community „ Implementierung eines Multi-Cluster-Verkehrsmanagements basierend auf Istio “ geteilt: Sie können einen Freund finden.
ein Hintergrund
Service Governance für heterogene Infrastrukturen wie Multi-Cloud und Hybrid Cloud ist eines der Szenarien, auf die sich Istio konzentriert. Um die Serviceverfügbarkeit zu verbessern und eine Anbieterbindung zu vermeiden, entscheiden sich Unternehmen normalerweise für die Bereitstellung von Anwendungen in mehreren Clustern in mehreren Regionen oder sogar in mehreren Cloud-Umgebungen wie Multi-Cloud- und Hybrid-Cloud-Lösungen Wahl für die Bereitstellung von Unternehmensanwendungen. Daher haben immer mehr Benutzer starke Anforderungen an die Cluster-übergreifende Service-Governance. In diesem Zusammenhang hat Istio als De-facto-Standard im ServiceMesh-Bereich eine Vielzahl von Multi-Cluster-Management-Lösungen auf den Markt gebracht.
2. Einführung
Derzeit unterstützt Istio 4 Multi-Cluster-Modelle.
- Flaches Netzwerk-Single-Control-Plane-Modell
- Flaches Netzwerk-Multi-Control-Plane-Modell
- Nicht-flaches Netzwerkmodell mit einer einzigen Steuerungsebene
- Nicht-flaches Netzwerkmodell mit mehreren Steuerungsebenen
Das Single-Control-Plane-Modell von Multi-Cluster bedeutet, dass mehrere Cluster dieselbe Istio-Control-Ebene teilen. Das Multi-Control-Plane-Modell von Multi-Cluster bedeutet, dass jeder Cluster unabhängig einen Satz von Istio-Control-Ebenen verwenden muss, unabhängig davon, ob es sich um eine einzelne Steuerung handelt Ebene oder ein Modell mit mehreren Steuerungsebenen, jeder Satz von Istio-Steuerungsebenen (istiod) muss mit dem Kube-Apiserver aller Cluster verbunden sein, und List-Watch ruft alle Cluster ab Service、Endpoint、Pod 、Node und steuert den Dienstzugriff innerhalb des Clusters oder zwischen Clustern Überwacht nur VirtualService、DestinationRule、Gatewaydie Istio-API-Objekte des Hauptclusters.
Abhängig davon, ob das Inter-Cluster-Netzwerk flach ist oder nicht, unterteilt Istio zwei Steuerungsebenenmodelle:
- Flaches Netzwerk: Multi-Cluster-Containernetzwerke sind über VPN und andere Technologien verbunden, und Pods können direkt über Cluster hinweg darauf zugreifen.
- Nicht flaches Netzwerk: Die Containernetzwerke jedes Clusters sind voneinander isoliert. Der Cluster-übergreifende Zugriff kann nicht weitergeleitet werden und muss über das Ost-West-Gateway erfolgen.
Wenn Sie das Istio-Multi-Cluster-Modell in einer Produktionsumgebung auswählen, müssen Sie natürlich eine Entscheidung basierend auf Ihrem tatsächlichen Szenario treffen. Wenn das Netzwerk zwischen Clustern flach ist, können Sie ein flaches Netzwerkmodell wählen. Wenn das Netzwerk zwischen Clustern isoliert ist, können Sie ein nicht flaches Netzwerkmodell wählen. Wenn die Clustergröße klein ist, können Sie das Modell mit einer einzigen Steuerebene wählen. Wenn die Clustergröße groß ist, können Sie das Modell mit mehreren Steuerebenen wählen.
In diesem Dokument wird ein Nicht-Flachnetzwerk-Multi-Control-Plane-Modell für Installationsanweisungen ausgewählt: Das Installationsmodell ist wie folgt. Das
Nicht-Flat-Netzwerk-Multi-Control-Plane-Modell weist die folgenden Merkmale auf.
- Verschiedene Cluster müssen sich nicht in einem großen Netzwerk befinden, das heißt, das Containernetzwerk muss nicht auf drei Ebenen verbunden sein, und der Zugriff auf Cluster-übergreifende Dienste erfolgt über
Istio East-West GatewayWeiterleitung. - Es gibt keine Begrenzung für den Pod-Adressbereich und den Service-Adressbereich jedes Kubernetes-Clusters. Er kann sich mit anderen Clustern überschneiden und verschiedene Cluster stören sich nicht gegenseitig.
- Der Sidecar jedes Kubernetes-Clusters ist nur mit der Istio-Steuerungsebene dieses Clusters verbunden, wodurch die Kommunikation effizienter wird.
- Istiod überwacht nur die Istio-Konfiguration des Hauptclusters, daher gibt es redundante Replikationsprobleme für andere Ressourcen.
VirtualService、DestinationRule、Gateway - Interner Dienstzugriff im selben Cluster: direkte Verbindung zwischen Pods; Cluster-übergreifender Dienstzugriff: Verlassen Sie sich auf den DNS-Proxy, um Dienstdomänennamen anderer Cluster aufzulösen. Da die Netzwerke zwischen Clustern voneinander isoliert sind, sind sie auf den Transitverkehr von angewiesen der Remote-Cluster.
East-west Gateway
Drei ClusterMesh-Umgebungskonstruktionen
Erstellen Sie zwei Cluster, Cluster1 und Cluster2, installieren Sie dann die Istio-Steuerungsebene auf jedem Cluster und legen Sie beide als primäre Cluster fest. Cluster Cluster1 befindet sich im Netzwerk Netzwerk1 und Cluster Cluster2 befindet sich im Netzwerk Netzwerk2.
3.1 Voraussetzungen
Die Umgebungsinformationen für diesen Build lauten wie folgt: Verwenden Sie Kind, um einen Kubernetes-Cluster zu erstellen. Die Kind-Version ist v0.19.0. Die Kubernetes-Version ist 1.27.3; die Istio-Version ist 1.20.1.
Stellen Sie vor dem Erstellen eines k8s-Clusters sicher, dass Docker kubectl und kind auf dem Linux-Knoten installiert sind.
Istioctl-Binärdatei herunterladen
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.1 TARGET_ARCH=x86_64 sh -
Istioctl-Client zum Pfad hinzufügen
3.2 Kubernetes-Cluster-Installation
Die Cluster-Installationsskripts für Cluster1 und Cluster2 lauten wie folgt
# create-cluster.sh
# Dieses Skript verwaltet die Erstellung mehrerer Cluster mithilfe von kind und the
# Möglichkeit zum Erstellen und Konfigurieren einer unsicheren Containerregistrierung.
setze -o xtrace
set -o ausgelöst
set -o Substantivmenge
set -o Pipefail
# Shellcheck source=util.sh
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
KIND_IMAGE="${KIND_IMAGE:-}"
KIND_TAG="${KIND_TAG:-v1.27.3@sha256:3966ac761ae0136263ffdb6cfd4db23ef8a83cba8a463690e98317add2c9ba72}"
OS="$(uname)"
Funktion create-clusters() {
local num_clusters=${1}
local image_arg=""
if [[ "${KIND_IMAGE}" ]]; Dann
image_arg="--image=${KIND_IMAGE}"
elif [[ "${KIND_TAG}" ]]; Dann
image_arg="--image=kindest/node:${KIND_TAG}"
Sei
for i in $(seq "${num_clusters}"); Tun
Art Cluster erstellen --name „cluster${i}“ „${image_arg}“
Fixup-Cluster „${i}“
Echo
Erledigt
}
Funktion fixup-cluster() {
local i=${1} # Clusternum
if [ "$OS" != "Darwin" ];then
# Legen Sie die Container-IP-Adresse als Kube-API-Endpunkt fest, damit Cluster Kube-API-Server in anderen Clustern erreichen können.
lokale docker_ip
docker_ip=$(docker inspect --format='{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
kubectl config set-cluster „kind-cluster${i}“ --server="https://${docker_ip}:6443"
Sei
# Kontextnamen vereinfachen
kubectl config rename-context „kind-cluster${i}“ „cluster${i}“
}
echo „${NUM_CLUSTERS} Cluster werden erstellt“
create-clusters „${NUM_CLUSTERS}“
kubectl config use-context cluster1
echo "Art CIDR ist $(docker network inspect -f '{{$map := index .IPAM.Config 0}}{{index $map "Subnet"}}' kind)"
echo „Abgeschlossen“
Während des obigen Cluster-Installationsprozesses wird die Cluster-Adresse auf die Adresse des Masterknotens gesetzt , damit istiod auf apiserverdie Adresse des anderen Clusters zugreifen kann. kube-apiserverDa es sich um einen Cluster handelt, der seiner Art nach bereitgestellt wird, handelt es sich bei den Masterknoten der beiden Cluster im Wesentlichen um Container, auf denen Docker auf demselben Host ausgeführt wird.
Bestätigen Sie, ob Cluster1 und Cluster2 bereit sind
3.3 Verwenden Sie MetalLB, um dem Gateway eine externe IP zuzuweisen
Da Art zur Bereitstellung mehrerer Cluster verwendet wird, erfordert die Erstellung des Istio-Nord-Süd-Gateways und des Ost-West-Gateways die Erstellung des LoadBalencer-Dienstes, die beide die Verwendung von ExternalIP erfordern. Dabei wird MetalLB verwendet, um die Verteilung und Bekanntgabe von LB-IP-Adressen zu realisieren.
Sehen Sie sich an, wie Sie einen Cluster mithilfe des Knoten-Subnetzsegments erstellen: Bereitstellung im MetalLB-L2-Modus. 172.18.0.0/16
MetalLB-Konfigurationsliste in Cluster1: metallb-config-1.yaml
### für Cluster1
##Konfigurieren Sie IPAddressPool für die Zuweisung von LBIP-Adressen. Im L2-Modus können sich die IP-Pool-Adresse und der Worker-Knoten im selben Subnetz befinden.
API-Version: metallb.io/v1beta1
Art: IPAddressPool
Metadaten:
Name: erster Pool
Namensraum: metallb-system
Spezifikation:
Adressen:
- 172.18.1.230-172.18.1.240
---
##Konfigurieren Sie L2Advertisement für die Adressankündigung
API-Version: metallb.io/v1beta1
Art: L2Advertisement
Metadaten:
Name: Erstadv
Namensraum: metallb-system
Spezifikation:
ipAddressPools:
- Erster Pool
MetalLB-Konfigurationsliste im Cluster Cluster2: metallb-config-2.yaml
### für Cluster2
##Konfigurieren Sie IPAddressPool für die Zuweisung von LBIP-Adressen. Im L2-Modus können sich die IP-Pool-Adresse und der Worker-Knoten im selben Subnetz befinden.
API-Version: metallb.io/v1beta1
Art: IPAddressPool
Metadaten:
Name: zweiter Pool
Namensraum: metallb-system
Spezifikation:
Adressen:
- 172.18.1.241-172.18.1.252
---
##Konfigurieren Sie L2Advertisement für die Adressankündigung
API-Version: metallb.io/v1beta1
Art: L2Advertisement
Metadaten:
Name: zweiter Adv
Namensraum: metallb-system
Spezifikation:
ipAddressPools:
- Zweiter Pool
Mit Skript installieren
#!/usr/bin/env bash
setze -o xtrace
set -o ausgelöst
set -o Substantivmenge
set -o Pipefail
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); Tun
echo „Metallb-Bereitstellung im Cluster${i} wird gestartet“
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.10/config/manifests/metallb-native.yaml --context "cluster${i}"
kubectl create Secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)" --context "cluster${i}"
## Erhöhen Sie die Wartezeit. Wenn die Metallb-Last nicht bereitgestellt wird, wird beim Erstellen von IPAddressPool L2Advertisement ein Fehler gemeldet.
Schlaf 10
kubectl apply -f ./metallb-config-${i}.yaml --context "cluster${i}"
Echo „----“
Erledigt
Bestätigen Sie den Bereitstellungsstatus von metalLB
Bestätigen Sie die IPAddressPool-Informationen:
3.4 Vertrauensbeziehung der Konfiguration der gemeinsam genutzten Stammzertifizierungsstelle des Clusters
Um eine sichere Cluster-übergreifende mTLS-Kommunikation zu unterstützen, erfordert das Multi-Control-Plane-Modell, dass die Kontrollebene Istiod jedes Clusters ein Zwischen-CA-Zertifikat verwendet, das von derselben CA-Behörde für Citatel ausgestellt wurde, um Zertifikate zur Unterstützung der Cluster-übergreifenden bidirektionalen TLS-Authentifizierung auszustellen .
Das Istio-Ost-West-Gateway (Cross-Cluster-Zugriff) verwendet beim Betrieb SNI-basiertes Routing. Es leitet es automatisch an den Cluster weiter, der dem von TLS angeforderten SNI entspricht erfordert, dass der gesamte Datenverkehr TLS-verschlüsselt sein muss.
Fügen Sie das Zertifikat und den Schlüssel in den Cluster ein. Das Skript lautet wie folgt (das Skript muss in das istio-Installationspaketverzeichnis verschoben werden):
#!/usr/bin/env bash
setze -o xtrace
#set -o ausgelöst
set -o Substantivmenge
set -o Pipefail
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
##Erstellen Sie im obersten Verzeichnis des Istio-Installationspakets ein Verzeichnis zum Speichern von Zertifikaten und Schlüsseln.
mkdir -p Zertifikate
Pushd-Zertifikate
##Stammzertifikat und Schlüssel generieren
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
for i in $(seq "${NUM_CLUSTERS}"); Tun
##Generieren Sie für jeden Cluster ein Zwischenzertifikat und einen Schlüssel für die Istio-Zertifizierungsstelle
make -f ../tools/certs/Makefile.selfsigned.mk "cluster${i}-cacerts"
##Erstellen Sie für jeden Cluster den istio-system-Namespace
kubectl Namespace erstellen istio-system --context „cluster${i}“
## Fügen Sie für jeden Cluster eine Netzwerkidentifikation hinzu, indem Sie den Istio-System-Namespace mit dem Tag topology.istio.io/network markieren
kubectl --context="cluster${i}" Label-Namespace istio-system topology.istio.io/network="network${i}"
##Beschriften Sie für jeden Cluster den Arbeitsknotenknoten mit einer Region und einer Verfügbarkeitszone, um Istio die Implementierung von regionalem Failover und regionalem Lastausgleich zu erleichtern.
kubectl --context="cluster${i}" Labelknoten "cluster${i}-control-plane" topology.kubernetes.io/region="region${i}"
kubectl --context="cluster${i}" Labelknoten "cluster${i}-control-plane" topology.kubernetes.io/zone="zone${i}"
#Erstellen Sie in jedem Cluster ein privates Cacert unter Verwendung aller Eingabedateien ca-cert.pem, ca-key.pem, root-cert.pem und cert-chain.pem.
kubectl lösche geheime cacerts -n istio-system --context „cluster${i}“
kubectl erstellt geheime generische cacerts -n istio-system --context "cluster${i}" \
--from-file="cluster${i}/ca-cert.pem" \
--from-file="cluster${i}/ca-key.pem" \
--from-file="cluster${i}/root-cert.pem" \
--from-file="cluster${i}/cert-chain.pem"
Echo „----“
Erledigt
3.5 Istio-Service-Mesh-Installation
Installieren Sie das Istio-Grid mit mehreren Steuerungsebenen für die Cluster Cluster1 und Cluster2.
Legen Sie Cluster1 als Hauptcluster fest und führen Sie den folgenden Befehl im Installationsverzeichnis von istio aus
cat <<EOF > cluster1.yaml
apiVersion: install.istio.io/v1alpha1
Art: IstioOperator
Spezifikation:
Werte:
global:
Mesh-ID: Mesh1
multiCluster: ##Multi-Cluster-Konfiguration aktivieren
ClusterName: Cluster1 #K8s-Clusternamen angeben
Netzwerk: Netzwerk1 #Geben Sie die Netzwerkkennung an
Protokollierung:
Ebene: debuggen
EOF
Legen Sie Cluster2 als Hauptcluster fest und führen Sie den folgenden Befehl im Installationsverzeichnis von istio aus
cat <<EOF > cluster2.yaml
apiVersion: install.istio.io/v1alpha1
Art: IstioOperator
Spezifikation:
Werte:
global:
Mesh-ID: Mesh2
multiCluster: ##Multi-Cluster-Konfiguration aktivieren
ClusterName: Cluster2 #K8s-Clusternamen angeben
Netzwerk: Netzwerk2 #Geben Sie die Netzwerkkennung an
Protokollierung:
Ebene: debuggen
EOF
#!/usr/bin/env bash
setze -o xtrace
set -o ausgelöst
set -o Substantivmenge
set -o Pipefail
OS="$(uname)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); Tun
echo „Istio-Bereitstellung im Cluster${i} wird gestartet“
istioctl install --force --context="cluster${i}" -f "cluster${i}.yaml"
echo „Ost-West-Gateway im Cluster${i} generieren“
## Installieren Sie Ost-West-Gateways in jedem Cluster.
Bash-Samples/multicluster/gen-eastwest-gateway.sh \
--mesh "mesh${i}" --cluster "cluster${i}" --network "network${i}" | \
istioctl --context="cluster${i}" install -y -f -
Echo
Erledigt
Führen Sie das Skript aus, um istio zu installieren und bereitzustellen
Warten Sie eine Weile, bis die Installation abgeschlossen ist
3.6 Öffnungsdienste am Ost-West-Gateway
Da sich die Cluster in unterschiedlichen Netzwerken befinden, müssen wir alle Dienste (*.local) auf den Ost-West-Gateways beider Cluster öffnen. Obwohl dieses Gateway im Internet öffentlich ist, können auf die Dienste dahinter nur Dienste mit vertrauenswürdigen mTLS-Zertifikaten zugreifen, als ob sie sich im selben Netzwerk befänden. Führen Sie die folgenden Befehle aus, um Dienste in beiden Clustern verfügbar zu machen:
apiVersion: networking.istio.io/v1beta1
Art: Gateway
Metadaten:
Name: Cross-Network-Gateway
Spezifikation:
Wähler:
istio: eastwestgateway # Dediziertes Gateway für Ost-West-Verkehr
Server:
- Hafen:
Nummer: 15443 # Bereits deklariert
Name: tls
Protokoll: TLS
TLS:
mode: AUTO_PASSTHROUGH # Der Arbeitsmodus des Ost-West-Gateways ist TLS AUTO_PASSTHROUGH
Gastgeber:
- „*.local“ # Alle Dienste verfügbar machen
Wenden Sie die obige Gateway-Konfiguration in jedem Cluster separat an:
kubectl -n istio-system --context=cluster${i} apply -f samples/multicluster/expose-services.yaml
3.7 Konfigurieren Sie das Geheimnis, damit istiod auf den Remote-Cluster-Apiserver zugreifen kann
Der istiod in jedem k8s-Cluster muss den Kube-APIServer anderer Cluster auflisten und die Anmeldeinformationen des K8s-Clusters verwenden, um ein Secret-Objekt zu erstellen, damit Istio auf den Remote-Kubernetes-Apiserver zugreifen kann.
#!/usr/bin/env bash
setze -o xtrace
set -o ausgelöst
set -o Substantivmenge
set -o Pipefail
OS="$(uname)"
NUM_CLUSTERS="${NUM_CLUSTERS:-2}"
for i in $(seq "${NUM_CLUSTERS}"); Tun
für j in $(seq "${NUM_CLUSTERS}"); Tun
if [ "$i" -ne "$j" ]
Dann
echo „Endpoint Discovery zwischen Cluster${i} und Cluster${j} aktivieren“
if [ "$OS" == "Darwin" ]
Dann
# Legen Sie die Container-IP-Adresse als Kube-API-Endpunkt fest, damit Cluster Kube-API-Server in anderen Clustern erreichen können.
docker_ip=$(docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' "cluster${i}-control-plane")
istioctl create-remote-secret \
--context="cluster${i}" \
--server="https://${docker_ip}:6443" \
--name="cluster${i}" | \
kubectl apply --validate=false --context="cluster${j}" -f -
anders
istioctl create-remote-secret \
--context="cluster${i}" \
--name="cluster${i}" | \
kubectl apply --validate=false --context="cluster${j}" -f -
Sei
Sei
Erledigt
Erledigt
Führen Sie das obige Skript aus: Das Remote-Geheimnis wird erstellt.
Überprüfen Sie das Istiod-Protokoll und stellen Sie fest, dass der Remote-Cluster bereits überwacht wird.
Vier Multi-Cluster-Verkehrsmanagementpraktiken von Istio
kubectl create --context=cluster1 Namespace-Beispiel
kubectl create --context=cluster2-Namespace-Beispiel
kubectl label --context=cluster1-Namespace-Beispiel \
istio-injection=aktiviert
kubectl label --context=cluster2-Namespace-Beispiel \
istio-injection=aktiviert
kubectl apply --context=cluster1 \
-f Proben/helloworld/helloworld.yaml \
-l service=helloworld -n Beispiel
kubectl apply --context=cluster2 \
-f Proben/helloworld/helloworld.yaml \
-l service=helloworld -n Beispiel
Stellen Sie verschiedene Versionen von Diensten in verschiedenen Clustern bereit
Stellen Sie die Anwendung helloworld-v1 auf Cluster1 bereit:kubectl apply --context=cluster1 \
-f Proben/helloworld/helloworld.yaml \
-l Version=v1 -n Beispiel
Stellen Sie die Anwendung helloworld-v2 auf Cluster2 bereit:
kubectl apply --context=cluster2 \ -f Proben/helloworld/helloworld.yaml \ -l version=v2 -n BeispielTestclient bereitstellen
kubectl apply --context=cluster1 \
-f Proben/sleep/sleep.yaml -n Beispiel
kubectl apply --context=cluster2 \
-f Proben/sleep/sleep.yaml -n Beispiel
Bestätigen Sie, dass die Ladeinstanz erfolgreich bereitgestellt wurde und der Sidecar eingefügt wurde
4.1 Überprüfen Sie den Cluster-übergreifenden Datenverkehr
Verwenden Sie den Sleep Pod, um den Dienst HelloWorld wiederholt aufzurufen. Um zu bestätigen, dass der Lastausgleich wie erwartet funktioniert, muss der Dienst HelloWorld von allen Clustern aufgerufen werden.
Senden Sie vom Sleep-Pod in Cluster1 eine Anfrage an den Dienst HelloWorld
Senden Sie vom Sleep-Pod in Cluster2 eine Anfrage an den Dienst HelloWorld
4.3 Überprüfen Sie den Zugriff vom Gateway
Greifen Sie über das Gateway auf den Server Helloworld zu
Erstellen Sie Istio-Ressourcen wie VirtualService und Gateway. Die Konfigurationsliste lautet wie folgt
# helloworld-gateway.yaml
apiVersion: networking.istio.io/v1beta1
Art: Gateway
Metadaten:
Name: helloworld-gateway
Spezifikation:
Wähler:
istio: ingressgateway # Istio-Standardcontroller verwenden
Server:
- Hafen:
Anzahl: 80
Name: http
Protokoll: HTTP
Gastgeber:
- "*"
---
apiVersion: networking.istio.io/v1beta1
Art: VirtualService
Metadaten:
Name: hallowelt
Spezifikation:
Gastgeber:
- "*"
Gateways:
- helloworld-gateway
http:
- übereinstimmen:
- Typ:
genau: /hello
Route:
- Ziel:
Gastgeber: Hallo Welt
Hafen:
Anzahl: 5000
Hinweis: Diese Konfiguration muss auf beide Cluster angewendet werden
Der Zugriffseffekt ist wie folgt:
4.3 Überprüfen Sie den regionalen Lastausgleich
Für eine detailliertere Kontrolle des Datenverkehrs legen Sie die Gewichtungen der beiden Regionen auf 80 % bzw. 20 % fest und konfigurieren die Gewichtsverteilung mit DestinationRule . region1 -> zone1 region1 -> zone2
# locality-lb-weight.yaml
apiVersion: networking.istio.io/v1beta1
Art: DestinationRule
Metadaten:
Name: hallowelt
Namensraum: Beispiel
Spezifikation:
Host: helloworld.sample.svc.cluster.local
Verkehrsrichtlinie:
Verbindungspool:
http:
maxRequestsPerConnection: 1
Lastenausgleicher:
einfach: ROUND_ROBIN
localityLbSetting:
aktiviert: wahr
verteilen:
- aus: Region1/*
Zu:
"region1/*": 80
"region2/*": 20
- aus: Region2/*
Zu:
„region2/*“: 80
"region1/*": 20
Ausreißererkennung:
aufeinanderfolgende5xxFehler: 1
Intervall: 1s
baseEjectionTime: 1m
Hinweis: Diese Konfiguration muss auf beide Cluster angewendet werden
Senden Sie eine Anfrage von Cluster1 über das Gateway an den Dienst HelloWorld
Senden Sie eine Anfrage von Cluster2 über das Gateway an den Dienst HelloWorld
4.4 Überprüfen Sie das regionale Failover
Wenn mehrere Dienstinstanzen in mehreren Regionen/Regionen bereitgestellt werden und die Dienstinstanz in einer bestimmten Region/Region nicht verfügbar ist, kann der Datenverkehr an Dienstinstanzen in anderen Regionen/Regionen übertragen werden, um ein regionales Failover zu erreichen und so eine hohe Verfügbarkeit des Dienstes sicherzustellen.
# locality-lb-failover.yaml
apiVersion: networking.istio.io/v1beta1
Art: DestinationRule
Metadaten:
Name: hallowelt
Namensraum: Beispiel
Spezifikation:
Host: helloworld.sample.svc.cluster.local
Verkehrsrichtlinie:
Verbindungspool:
http:
maxRequestsPerConnection: 1 # Deaktivieren Sie HTTP Keep-Alive und erzwingen Sie, dass jede HTTP-Anfrage eine neue Verbindungsrichtlinie verwendet
Lastenausgleicher:
einfach: ROUND_ROBIN
localityLbSetting: # Regionale Lastausgleichskonfiguration. Nach dem Aktivieren der Ausreißererkennung ist sie standardmäßig aktiviert.
aktiviert: wahr
Failover: # Regionale Failover-Strategie
- aus: Region1
zu: Region2
- aus: Region2
zu: Region1
Ausreißererkennung:
consequent5xxErrors: 1 # 1 aufeinanderfolgender 5xx-Fehler
Intervall: 1s # Erkennungsintervall 1s
baseEjectionTime: 1m #Grundauswurfzeit 1m
Hinweis: Diese Konfiguration muss auf beide Cluster angewendet werden
Senden Sie eine Anfrage von Cluster1 über das Gateway an den Dienst HelloWorld
Simulieren Sie einen Fehler und stellen Sie die Helloworld V1-Version im Cluster „cluster1“ manuell auf „Fehler“ ein.
Beim erneuten Zugriff tritt die Fehlererkennung in Kraft, löst ein Failover aus und überprüft, ob die Version in der Antwort immer v2 ist, was bedeutet, dass wir auf den Helloworld-Dienst in Region 2 zugreifen und so ein regionales Failover erreichen.
Die Voraussetzung des Failovers besteht darin, dass, wenn alle Instanzen in der aktuellen Region nicht verfügbar sind, der Datenverkehr in die aktuelle Region übertragen wird. Andernfalls wird der Datenverkehr an andere verfügbare Instanzen in der aktuellen Region gesendet.
Fünf Bemerkungen
Die Referenzen lauten wie folgt:
-
istio Open Source Community (Installationsanweisungen für netzwerkübergreifende multiprimäre Architektur): https://istio.io/latest/zh/docs/setup/install/multicluster/multi-primary_multi-network/
-
Referenz zum Kind-Installationscluster-Skript: https://github.com/cnych/multi-cluster-istio-kind/tree/main/kind-create
-
Referenz zur Verwaltung von Multi-Cluster-Zertifikaten: https://istio.io/latest/zh/docs/tasks/security/cert-management/plugin-ca-cert/
Das erste große Versionsupdate von JetBrains 2024 (2024.1) ist Open Source. Sogar Microsoft plant, dafür zu bezahlen. Warum steht es immer noch in der Kritik? [Wiederhergestellt] Tencent Cloud-Backend stürzte ab: Viele Servicefehler und keine Daten nach der Anmeldung an der Konsole. Deutschland muss auch 30.000 PCs von Windows auf Linux Deepin-IDE migriert haben Bootstrapping! Visual Studio Code 1.88 wurde veröffentlicht. Tencent hat Switch wirklich in eine „denkende Lernmaschine“ verwandelt. Der auf SQLite basierende Web-Client WCDB hat ein umfangreiches Upgrade erhalten.