Direkte CA-Migration

Hinweis: In diesem Leitfaden wird beschrieben, wie Sie Ihre Zertifizierungsstelle (Certificate Authority, CA) migrieren, ohne Arbeitslasten mit minimaler Ausfallzeit zu einer neuen Steuerungsebene (vor Ort) mit einem Bash-basierten Tool zu migrieren. Informationen zur Migration von Istio CA zu Mesh CA mit einem Canary-basierten Ansatz, der nur minimale oder keine Ausfallzeiten umfasst, finden Sie unter Canary-basierte Migration zu Mesh CA.

Wenn Ihr Mesh über mehrere Cluster mit Arbeitslasten verfügt, die Anfragen an Arbeitslasten in einem anderen Cluster senden, führen Sie alle Schritte in dieser Anleitung für alle Cluster aus.

Befolgen Sie die Schritte in dieser Anleitung für folgende Anwendungsfälle:

• Migrieren Sie eine clusterinterne Steuerungsebene von Anthos Service Mesh Version 1.13 oder höher mit Mesh-CA zum Certificate Authority Service.
• Migrieren Sie eine verwaltete Steuerungsebene von Anthos Service Mesh mit Mesh CA dem Certificate Authority Service. auf einer Release-Version, die Version 1.13 oder höher zugeordnet ist.

Beschränkungen

Direkte CA-Migrationen und -Upgrades werden nur von Anthos Service Mesh v1.13 oder höher unterstützt. Achten Sie bei Migrationen von verwalteten Steuerungsebenen darauf, dass der ausgewählte Kanal Version 1.13 oder höher zugeordnet ist.

Vorbereitung

Bevor Sie die Schritte in dieser Anleitung ausführen, müssen Sie Folgendes ausführen:

• Gewährte Cluster-Administratorberechtigungen
• Konfigurierte gcloud

Prüfen Sie außerdem, ob Sie derzeit Anthos Service Mesh Version 1.13 oder höher verwenden.

Erforderliche Tools

Während der Migration führen Sie ein von Google bereitgestelltes Tool aus: migrate_ca. Für dieses Tool gelten die folgenden Abhängigkeiten:

• awk
• grep
• jq
• kubectl
• head
• sed
• tr
• yq

Führen Sie vor dem Herunterladen des migrate_ca-Tools die Schritte unter Vorbereitung auf die Migration aus.

Übersicht über die Migration

Während des Migrationsprozesses funktionieren Authentifizierung und Autorisierung vollständig zwischen Arbeitslasten, die die vorherige CA verwenden, und Arbeitslasten, die die neue CA verwenden.

Das Migrationstool migrate_ca erstellt eine Kubernetes-Konfigurationszuordnung, um den Status der CA-Migration pro installierter Anthos Service Mesh-Überarbeitung/-kanal zu verfolgen. Dies ist eine privilegierte Ressource, die im Namespace istio-system installiert ist.

apiVersion: v1
kind: ConfigMap
metadata:
  Name: asm-ca-migration-<revision>
Data:
  revision:
  start_time:
  state_update_time:
  current_state: TRUSTANCHOR_INJECT | MIGRATE_CA | ROLLBACK
  old_ca:
  target_ca:

Das Migrationstool sichert die Istio MeshConfig-Konfigurationszuordnung vor dem Ändern und versucht, die CA-Konfiguration, wenn möglich, mithilfe der ProxyConfig-CRD zu migrieren.

Im Folgenden finden Sie einen Überblick über die CA-Migration:

Hinweis: Sie müssen die Migrationsschritte für jeden Cluster in Ihrem Mesh-Netzwerk ausführen.

1. Migration vorbereiten.

2. Initialisieren Sie die neue CA.

3. Fügen Sie für alle Cluster in der Flotte Mesh-weite trustAnchors hinzu.

4. Migrieren Sie die CA.

5. Rollback ausführen.

Migration vorbereiten

1. Laden Sie das Bash-Tool migrate_ca herunter:

   curl  https://raw.githubusercontent.com/GoogleCloudPlatform/anthos-service-mesh-packages/main/scripts/migration/ca-migration/migrate_ca > migrate_ca
   

2. Machen Sie das Tool ausführbar:

   chmod +x migrate_ca
   

3. Richten Sie das Arbeitsverzeichnis ein:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Hinweis: Wenn Sie kein Arbeitsverzeichnis angeben, wird ein temporäres Verzeichnis erstellt. Sie benötigen es für alle nachfolgenden Schritte als Arbeitsverzeichnis.

4. Ändern Sie das Arbeitsverzeichnis in das im vorherigen Schritt angegebene OUTPUT_DIR.

   cd OUTPUT_DIR
   

5. Führen Sie den folgenden Befehl aus, um sicherzustellen, dass alle Voraussetzungen erfüllt sind:

   ./migrate_ca check-prerequisites
   

6. Notieren Sie sich die Überarbeitung (ASM_REVISION) der Steuerungsebene, die der vorherigen zu migrierenden CA zugeordnet ist. Die erforderlichen Schritte hängen vom Typ der Steuerungsebene ab, entweder clusterintern oder verwaltet.

   Clusterintern

   asm-revision=$(kubectl get deploy -n istio-system -l app=istiod -o \
    "jsonpath={.items[*].metadata.labels[istio\.io/rev']}{'\n'}")
   

   Verwaltet

   Verweisen Sie auf den bereits installierten Kanal.

7. Da Sie bei der direkten CA-Migration Ihre Arbeitslasten neu starten müssen, muss das Budget für Pod-Störungen korrekt konfiguriert und alle Anwendungen, deren CA migriert werden muss, mehr als einen ausgeführten Pod haben.

8. Achten Sie darauf, dass der Cluster bereits für eine Flotte registriert ist und dass Workload Identity auf dem Cluster aktiviert ist. Notieren Sie sich dann die Projekt-ID der Flotte (FLEET_ID) für zukünftige Schritte.

9. Das Tool akzeptiert kubeConfig und kubeContext, um den Cluster auszuwählen, in dem die Vorgänge ausgeführt werden. Wenn diese Argumente nicht übergeben werden, wird der Standardkontext/die Standardkonfiguration verwendet.

   • Verwenden Sie den folgenden Befehl, um die Anmeldedaten eines GKE-Clusters in kubeConfig hinzuzufügen:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Verwenden Sie den folgenden Befehl, um den aktuellen kubectl-Kontext zu ändern oder den Kontext an das Tool zu übergeben:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Neue CA initialisieren

1. Die zum Initialisieren der neuen CA erforderlichen Schritte hängen von der neuen CA ab, zu der Sie migrieren. Führen Sie diese Schritte in jedem Flottencluster aus, in den Sie die CA migrieren möchten.

   Mesh CA

   Rufen Sie den Unterbefehl initialize des Dienstprogramms auf.

   Wenn Sie benutzerdefinierte Kubernetes-Konfigurationen angeben:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --kubecontext KUBECONTEXT --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
   

   Andernfalls:

    ./migrate_ca initialize --ca mesh_ca --old_ca OLD_CA_TYPE \
    --fleet_id FLEET_ID --revision ASM_REVISION
    ```
   

   CA-Dienst

   a. Folgen Sie den Schritten, die zum Initialisieren von Certificate Authority Service erforderlich sind. Notieren Sie sich den CA_POOL.

   b. Rufen Sie den Unterbefehl initialize des Dienstprogramms auf:

   Wenn Sie benutzerdefinierte Kubernetes-Konfigurationen angeben:

    ./migrate_ca initialize --kubeconfig KUBECONFIG --context KUBECONTEXT --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
    --fleet-id FLEET_ID --revision ASM_REVISION
   

   Andernfalls:

     ./migrate_ca initialize --ca gcp_cas --ca-pool CA_POOL --ca-old OLD_CA_TYPE \
     --fleet-id FLEET_ID --revision ASM_REVISION
   

Mesh-weite trustAnchors für alle Cluster in der Flotte hinzufügen

1. Wiederholen Sie die folgenden Schritte für die neue und die alte CA für alle Cluster, die Teil der Flotte sind.

2. Laden Sie die trustAnchors der CA herunter:

   Mesh CA

   ./migrate_ca download-trust-anchor --ca mesh_ca --ca_cert ROOT_CERT.pem
   

   CA-Dienst

   Speichern Sie das CA-Zertifikat in einer Datei:

   gcloud privateca pools get-ca-certs POOL_NAME --location=POOL_REGION --project=POOL_PROJECT--output-file ROOT_CERT.pem
   

3. Fügen Sie die trustAnchors der CA hinzu:

   ./migrate-ca add-trust-anchor --ca_cert ROOT_CERT.pem
   

4. Prüfen Sie, ob die trustAnchors von allen Arbeitslasten in der Flotte empfangen wurden. Übergeben Sie im Namespace-Argument alle Namespaces, in denen Arbeitslasten bereitgestellt werden:

   ./migrate-ca check-trust-anchor --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Erwartete Ausgabe:

   Check the CA cert in namespace nsa-1-24232
   a-v1-597f875788-52c5t.nsa-1-24232 trusts root-cert.pem
   

CA migrieren

1. Migrieren Sie die CA-Konfiguration. Der erforderliche Befehl hängt von der neuen CA ab, zu der Sie migrieren.

   Mesh CA

   ./migrate_ca migrate-ca --ca mesh_ca
   

   CA-Dienst

   ./migrate_ca migrate-ca --ca gcp_cas --ca_pool CA_POOL
   

2. Starten Sie alle Arbeitslasten neu.

   Hinweis: Dieser Schritt ist optional, wenn Sie die verwaltete Datenebene installiert haben. Dies liegt daran, dass Google die Proxy-Lebensdauer verwaltet und diesen Schritt während eines verwalteten Upgrades automatisch ausführt.

   Dieser Schritt sollte sich auf die kleinste Anzahl von Arbeitslasten auswirken, um das Risiko von TLS-Trafficausfällen zu minimieren. Starten Sie nur Arbeitslasten neu, die der Überarbeitung ASM_REVISION der Steuerungsebene zugeordnet sind. Beispielsweise wenn alle Arbeitslasten im Kubernetes-Namespace NAMESPACE derselben Anthos Service Mesh-Steuerungsebene zugeordnet sind.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Prüfen Sie, ob mTLS-Verbindungen zwischen Arbeitslasten im neu gestarteten Namespace und anderen Arbeitslasten funktionieren, bevor Sie die Schritte 1 und 2 für alle Namespaces und für alle Cluster der Flotte wiederholen. Wenn neuere Arbeitslasten verfügbar sind und der Mesh-Traffic nicht unterbrochen wird, wiederholen Sie Schritte 1 und 2 für alle Namespaces und Cluster der Flotte. Andernfalls können Sie ein Rollback ausführen, um ein Rollback der neueren CA-Konfiguration durchzuführen.

4. Prüfen Sie, ob die neue CA-Konfiguration von allen Arbeitslasten verwendet wird:

   ./migrate_ca verify-ca --ca_cert ROOT_CERT.pem --namespaces NAMESPACES
   

   Erwartete Ausgabe:

   Check the CA configuration in namespace nsb-2-76095
   b-v1-8ff557759-pds69.nsb-2-76095 is signed by root-cert.pem
   

Rollback durchführen

1. Führen Sie ein Rollback der CA-Konfiguration durch und entfernen Sie die neu konfigurierten trustAnchors:

   ./migrate-ca rollback
   

2. Starten Sie alle Arbeitslasten neu. Starten Sie nur Arbeitslasten neu, die der Überarbeitung ASM_REVISION der Steuerungsebene zugeordnet sind. Beispielsweise wenn alle Arbeitslasten im Kubernetes-Namespace NAMESPACES derselben Anthos Service Mesh-Steuerungsebene zugeordnet sind.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Optional) Prüfen Sie, ob die ältere CA-Konfiguration von allen Arbeitslasten verwendet wird.

   ./migrate-ca verify-ca --ca_cert older-root-cert.pem
   

4. Wiederholen Sie die Schritte 1 bis 3 für alle Cluster in der Flotte, in denen Arbeitslasten die Steuerungsebene ASM_REVISION verwenden.

Glückwunsch! Sie haben eine direkte CA-Migration durchgeführt.