Konfigurationsupdates für die Modernisierung

In diesem Dokument werden Konfigurationsaktualisierungen beschrieben, die Sie möglicherweise an Ihrem verwalteten Cloud Service Mesh vornehmen müssen, bevor Sie Ihr Mesh von der ISTIOD-Steuerungsebene auf die TRAFFIC_DIRECTOR-Steuerungsebene umstellen.

Weitere Informationen zum Modernisierungsworkflow finden Sie auf der Seite Verwaltete Steuerungsebene modernisieren.

Von Istio-Secrets zu multicluster_mode migrieren

Multi-Cluster-Secrets werden nicht unterstützt, wenn ein Cluster die TRAFFIC_DIRECTOR-Steuerungsebene verwendet. In diesem Dokument wird beschrieben, wie Sie die Verwendung von Istio-Multi-Cluster-Secrets durch multicluster_mode ersetzen können.

Istio-Secrets im Vergleich zu deklarativen APIs

Bei der Open-Source-Istio-Multi-Cluster-Endpunkterkennung wird mit istioctl oder anderen Tools ein Kubernetes-Secret in einem Cluster erstellt. Mit diesem Secret kann ein Cluster Traffic an einen anderen Cluster im Mesh ausgleichen. Die ISTIOD-Steuerungsebene liest dann dieses Secret und leitet den Traffic an diesen anderen Cluster weiter.

Cloud Service Mesh bietet eine deklarative API, mit der sich der Multi-Cluster-Traffic steuern lässt, anstatt Istio-Secrets direkt zu erstellen. Diese API behandelt Istio-Secrets als Implementierungsdetail und ist zuverlässiger als das manuelle Erstellen von Istio-Secrets. Künftige Cloud Service Mesh-Funktionen sind von der deklarativen API abhängig und Sie können diese neuen Funktionen nicht direkt mit Istio-Secrets verwenden. Die deklarative API ist die einzige unterstützte Option.

Wenn Sie Istio-Secrets verwenden, sollten Sie so bald wie möglich zur deklarativen API migrieren. Beachten Sie, dass die Einstellung multicluster_mode jeden Cluster anweist, Traffic an jeden anderen Cluster im Mesh weiterzuleiten. Die Verwendung von Secrets ermöglicht eine flexiblere Konfiguration. Sie können für jeden Cluster konfigurieren, an welchen anderen Cluster im Mesh der Traffic weitergeleitet werden soll. Eine vollständige Liste der Unterschiede zwischen den unterstützten Funktionen der deklarativen API und Istio-Secrets finden Sie unter Unterstützte Funktionen mit Istio APIs.

Von Istio-Secrets zur deklarativen API migrieren

Wenn Sie Cloud Service Mesh mit automatischer Verwaltung über die Fleet Feature API bereitgestellt haben, müssen Sie diese Anleitung nicht befolgen. Diese Schritte gelten nur, wenn Sie die Einrichtung mit asmcli --managed durchgeführt haben.

Hinweis: Bei diesem Vorgang werden Secrets geändert, die auf einen Cluster verweisen. Dabei werden die Endpunkte entfernt und dann wieder hinzugefügt. In der Zeit zwischen dem Entfernen und Hinzufügen der Endpunkte wird der Traffic kurzzeitig lokal weitergeleitet, anstatt über das Load Balancing an andere Cluster weitergeleitet zu werden. Weitere Informationen finden Sie im GitHub-Problem.

So wechseln Sie von Istio-Secrets zur deklarativen API: Führen Sie die folgenden Schritte gleichzeitig oder direkt hintereinander aus:

Aktivieren Sie die deklarative API für jeden Cluster in der Flotte, in dem Sie die Endpunkterkennung für mehrere Cluster aktivieren möchten. Legen Sie dazu multicluster_mode=connected fest. Sie müssen multicluster_mode=disconnected explizit festlegen, wenn der Cluster nicht auffindbar sein soll.

Mit dem folgenden Befehl können Sie einen Cluster für die clusterübergreifende Endpunkterkennung aktivieren:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"connected"}}'
```
Verwenden Sie den folgenden Befehl, um die Endpunkterkennung für einen Cluster zu deaktivieren:
```
 kubectl patch configmap/asm-options -n istio-system --type merge -p '{"data":{"multicluster_mode":"disconnected"}}'
```
Löschen Sie alte Secrets.

Nachdem Sie multicluster_mode=connected für Ihre Cluster festgelegt haben, wird für jeden Cluster ein neues Secret für jeden anderen Cluster generiert, für den auch multicluster_mode=connected festgelegt ist. Das Secret wird im Namespace „istio-system“ platziert und hat das folgende Format:
```
istio-remote-secret-projects-PROJECT_NAME-locations-LOCATION-memberships-MEMBERSHIPS
```
Auf jedes Secret wird außerdem das Label istio.io/owned-by: mesh.googleapis.com angewendet.

Nachdem die neuen Secrets erstellt wurden, können Sie alle manuell mit istioctl create-remote-secret erstellten Secrets löschen:
```
kubectl delete secret SECRET_NAME -n istio-system
```

Prüfen Sie nach der Migration die Messwerte für Anfragen, um sicherzustellen, dass sie wie erwartet weitergeleitet werden.