Multiregionale Bereitstellung auf AKS

In diesem Thema wird erläutert, wie Sie eine multiregionale Bereitstellung für Apigee Hybrid in Microsoft® Azure Kubernetes Service (AKS) einrichten.

Zu den Topologien für die Multiregions-Bereitstellung zählen:

Aktiv-Aktiv: Wenn Sie Anwendungen an mehreren geografischen Standorten bereitgestellt haben und eine API-Antwort mit niedriger Latenz für Ihre Bereitstellungen benötigen. Sie haben die Möglichkeit, Hybrid an mehreren geografischen Standorten bereitzustellen, die Ihren Kunden am nächsten sind. Beispiel: US-Westküste, US-Ostküste, Europa, APAC.
Aktiv-Passiv: Wenn Sie eine primäre Region und eine Failover-Region oder eine Region für die Notfallwiederherstellung haben.

Die Regionen in einer multiregionalen Hybrid-Bereitstellung kommunizieren über Cassandra, wie das folgende Bild zeigt:

Vorbereitung

Bevor Sie Hybrid für mehrere Regionen konfigurieren, müssen folgende Elemente vorhanden sein:

Bevor Sie die Schritte zur Clustereinrichtung ausführen, müssen Sie der Hybrid-Installationsanleitung folgen, um die Voraussetzungen wie GCP- und Organisationskonfiguration zu erfüllen.

Ausführliche Informationen dazu finden sich in der Kubernetes-Dokumentation.

In jeder Region ein virtuelles Netzwerk erstellen

Erstellen Sie ein virtuelles Netzwerk für die multiregionale Bereitstellung. Mit den folgenden Beispielbefehlen werden beispielsweise Netzwerke in den Regionen "Central US" und "Eastern US" erstellt.

Führen Sie diesen Befehl aus, um ein virtuelles Netzwerk in der Region "Eastern US" mit dem Namen my-hybrid-rg-vnet zu erstellen:

az network vnet create \
 --name my-hybrid-rg-vnet \
 --location eastus \
 --resource-group my-hybrid-rg \
 --address-prefixes 120.38.1.0/24 \
 --subnet-name my-hybrid-rg-vnet-subnet \
 --subnet-prefix 120.38.1.0/26

Führen Sie diesen Befehl aus, um ein virtuelles Netzwerk in der Region "Central US" mit dem Namen my-hybrid-rg-vnet-ext01 zu erstellen:

az network vnet create \
 --name my-hybrid-rg-vnet-ext01 \
 --location centralus \
 --resource-group my-hybrid-rg \
 --address-prefixes 192.138.0.0/24 \
 --subnet-name my-hybrid-rg-vnet-ext01-subnet \
 --subnet-prefix 192.138.0.0/26

Netzwerk-Peering erstellen

Erstellen Sie ein Netzwerk-Peering zwischen den virtuellen Netzwerken.

IDs des virtuellen Netzwerks abrufen

Peerings werden zwischen virtuellen Netzwerk-IDs eingerichtet. Rufen Sie die ID jedes virtuellen Netzwerks mit dem Befehl az network vnet show ab und speichern Sie die ID in einer Variable.

Rufen Sie die ID des ersten virtuellen Netzwerks mit dem Namen my-hybrid-rg-vnet ab:

vNet1Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet \
 --query id --out tsv)

Rufen Sie die ID des zweiten virtuellen Netzwerks mit dem Namen my-hybrid-rg-vnet-ext01 ab:

vNet2Id=$(az network vnet show \
 --resource-group my-hybrid-rg \
 --name my-hybrid-rg-vnet-ext01 \
 --query id \
 --out tsv)

Peering vom ersten zum zweiten virtuellen Netzwerk erstellen

Mit den virtuellen Netzwerk-IDs können Sie ein Peering vom ersten virtuellen Netzwerk (my-hybrid-rg-vnet) bis zum zweiten (my-hybrid-rg-vnet-ext01) erstellen, wie in den folgenden Beispielen gezeigt:

Wenn Sie den Parameter --allow-vnet-access nicht angeben, wird ein Peering eingerichtet, aber keine Kommunikation ermöglicht.

az network vnet peering create \
 --name my-hybrid-rg-vnet1-peering \     # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \         # The virtual network name.
 --remote-vnet $vNet2Id \                # Resource ID of the remote virtual network.
 --allow-vnet-access

Beachten Sie in der Ausgabe des Befehls, dass peeringState auf Initiiert gesetzt ist. Das Peering bleibt im Status "Initiiert", bis Sie das Peering vom zweiten virtuellen Netzwerk zurück zum ersten erstellen.

{
  ...
  "peeringState": "Initiated",
  ...
}

Erstellen Sie ein Peering vom zweiten virtuellen Netzwerk zum ersten

Beispielbefehl:

az network vnet peering create \
 --name my-hybrid-rg-vnet2-peering \        # The name of the virtual network peering.
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet-ext01 \      # The virtual network name.
 --remote-vnet $vNet1Id \                   # Resource ID of the remote virtual network.
 --allow-vnet-access

Beachten Sie in der Ausgabe des Befehls, dass peeringState Connected ist. Außerdem ändert Azure den Peering-Status vom ersten zum zweiten virtuellen Netzwerk-Peering in Connected.

{
  ...
  "peeringState": "Connected",
  ...
}

Sie können auch prüfen, ob der Peering-Status für my-hybrid-rg-vnet1-peering zu my-hybrid-rg-vnet2-peering mit dem folgenden Befehl in "Connected" geändert wurde:

az network vnet peering show \
 --name my-hybrid-rg-vnet1-peering \
 --resource-group my-hybrid-rg \
 --vnet-name my-hybrid-rg-vnet \
 --query peeringState

Erwartete Ausgabe:

Connected

Multiregionale Cluster erstellen

Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR einrichten. Siehe auch Schritt 1: Cluster erstellen. Verwenden Sie die zuvor erstellten Standorte und virtuellen Netzwerknamen.

Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen (7000 kann bei der Fehlerbehebung als Sicherungsoption verwendet werden).

Seed-Host für mehrere Regionen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie den vorhandenen Cassandra-Cluster auf eine neue Region erweitern. Diese Konfiguration ermöglicht der neuen Region, einen Bootstrap-Vorgang auf den Cluster anzuwenden und dem vorhandenen Rechenzentrum beizutreten. Ohne diese Konfiguration würden die multiregionalen Kubernetes-Cluster nichts voneinander wissen.

Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
```
kubectl config use-context original-cluster-name
```
Führen Sie folgenden kubectl-Befehl aus, um eine Seed-Hostadresse für Cassandra in der aktuellen Region zu identifizieren.

Mit einer Seed-Hostadresse kann eine neue regionale Instanz beim ersten Start den ursprünglichen Cluster finden, um die Topologie des Clusters zu erlernen. Die Seed-Hostadresse wird als Kontaktpunkt im Cluster festgelegt.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra

apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist. In diesem Beispiel, in dem nur ein einzelner Knoten-Kassandra-Cluster ausgeführt wird, lautet der Seed-Host 120.38.1.9.
Kopieren Sie in Ihrem Rechenzentrum 2 die overrides-datei in eine neue Datei, deren Name den Clusternamen enthält. z. B. overrides_your_cluster_name.yaml
Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter in overrides_your_cluster_name.yaml, wobei multiRegionSeedHost eine der vom vorherigen Befehl zurückgegebenen IP-Adressen ist:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
```
Beispiel:
```
cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "centralus"
  rack: "ra-1"
```
Geben Sie in overrides_your_cluster_name.yaml für das neue Rechenzentrum bzw. für die neue Region vor der Installation von Hybrid die gleichen TLS-Zertifikate und -Anmeldedaten wie für die erste Region an.
HINWEIS: Verwenden Sie im zweiten Rechenzentrum die gleichen Cassandra-TLS-Zertifikate und -Anmeldedaten wie im ursprünglichen Rechenzentrum. Die Anmeldedaten, die Sie im ersten Rechenzentrum in der overrides-datei festlegen, müssen mit den Anmeldedaten übereinstimmen, die Sie im zweiten Rechenzentrum in der overrides-datei angeben. Ausführliche Informationen dazu finden Sie unter TLS für Cassandra konfigurieren.

Neue Region einrichten

Nachdem Sie den Seed-Host konfiguriert haben, können Sie die neue Region einrichten.

So richten Sie die neue Region ein:

Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
1. Legen Sie für den Kontext den ursprünglichen Namespace fest:
```
kubectl config use-context original-cluster-name
```
2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:
```
$ kubectl get namespace  -o yaml > apigee-namespace.yaml
```
3. Exportieren Sie das apigee-ca-Secret in eine Datei:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:
```
kubectl config use-context new-cluster-name
```
5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importieren Sie das Secret in den neuen Cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.
Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Führen Sie nodetool rebuild nacheinander auf allen Knoten im neuen Rechenzentrum aus. Dies kann, je nach Datengröße, bis zu einigen Stunden dauern.
```
kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool rebuild -- dc-1
```

Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße:

kubectl logs apigee-cassandra-default-0 -f -n apigee

Das folgende Beispiel zeigt beispielhafte Logeinträge.

INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
Seed-Hosts sind lokale Clustermitglieder. Zum Starten einer neuen Region ist ein externer Seed-Host erforderlich. Sobald eine Region gestartet wurde, müssen Sie die Seed-Hosts wieder zu ihren lokalen Clustern in overrides.yaml ändern und die Konfiguration dann noch einmal anwenden.
```
apigeectl apply -f overrides-DC_name.yaml
```