Migración de CA en el lugar

Nota: En esta guía, se describe cómo migrar tu autoridad certificadora (AC) sin migrar cargas de trabajo a un plano de control nuevo (en el lugar) con un tiempo de inactividad mínimo mediante una herramienta basada en Bash. Para migrar de la CA de Istio a la CA de Mesh con un enfoque basado en versiones canary que incluya un tiempo de inactividad mínimo o nulo, consulta Migración basada en versiones canary a la CA de Mesh.

Si la malla tiene varios clústeres con cargas de trabajo que envían solicitudes a las cargas de trabajo en otro clúster, sigue todos los pasos de esta guía para todos los clústeres.

Sigue los pasos de esta guía para los siguientes casos de uso:

• Migra un plano de control del clúster de Cloud Service Mesh v1.13 o posterior con la AC de Mesh a Certificate Authority Service.
• Migra un plano de control de Cloud Service Mesh administrado en un canal de versiones que se asigne a la versión v1.13 o posterior con la AC de Mesh a Certificate Authority Service.

Limitaciones

Las migraciones y actualizaciones de AC locales solo son compatibles con la malla de servicios de Cloud v1.13 o una fecha posterior. Para las migraciones del plano de control administrado, asegúrate de que el canal elegido se asigne a la versión v1.13 o posterior.

Requisitos previos

Antes de seguir los pasos de esta guía, asegúrate de haber hecho lo siguiente:

• Otorgar permisos de administrador de clúster
• Configurar gcloud

Además, asegúrate de estar usando Cloud Service Mesh v1.13 o una versión posterior.

Herramientas requeridas

Durante la migración, debes ejecutar una herramienta proporcionada por Google, migrate_ca. Esta herramienta tiene las siguientes dependencias:

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

Antes de descargar la herramienta migrate_ca, sigue los pasos que se indican en Prepárate para la migración.

Descripción general de la migración

Durante el proceso de migración, la autenticación y la autorización son completamente funcionales entre las cargas de trabajo que usan la CA previa y las cargas de trabajo que usan la CA nueva.

La herramienta de migración migrate_ca creará un mapa de configuración de Kubernetes para realizar un seguimiento del estado de la migración de AC por revisión o canal instalado de Cloud Service Mesh. Este es un recurso con privilegios instalado en el espacio de nombres istio-system.

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:

La herramienta de migración creará una copia de seguridad del mapa de configuración de Istio MeshConfig antes de enmendar y, luego, intenta migrar la configuración de la AC con ProxyConfig CRD cuando sea posible.

El siguiente es un esquema de la migración de CA:

Nota: Debes realizar los pasos de migración en cada clúster de tu malla.

1. Prepárate para la migración.

2. Inicializa la CA nueva.

3. Agrega trustAnchors en toda la malla para todos los clústeres de la flota.

4. Migra la CA.

5. Realiza una reversión.

Prepárate para la migración

1. Descarga la herramienta bash migrate_ca:

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

2. Haz que la herramienta sea ejecutable:

   chmod +x migrate_ca
   

3. Configura el directorio de trabajo:

   ./migrate_ca setup --output_dir OUTPUT_DIR
   

   Nota: Si no especificas un directorio de trabajo, se creará uno temporal. Deberás usarlo como el directorio de trabajo para todas las instancias pasos.

4. Cambia el directorio de trabajo al OUTPUT_DIR especificado en el paso anterior.

   cd OUTPUT_DIR
   

5. Ejecuta el siguiente comando para asegurarte de que se cumplan todos los requisitos previos:

   ./migrate_ca check-prerequisites
   

6. Toma nota de la revisión (ASM_REVISION) del plano de control asociado con la CA anterior que se migra. Los pasos necesarios dependen del tipo de plano de control, ya sea en el clúster o administrado.

   En el clúster

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

   Administrado

   Consulta el canal que ya está instalado.

7. Dado que la migración de AC local requiere que reinicies tus cargas de trabajo, garantizar que los Presupuesto de interrupción de Pods esté configurada correctamente y todas las aplicaciones cuya CA deba migrarse tener más de un Pod en ejecución.

8. Asegúrate de que el clúster ya esté registrado en una flota y que la identidad de carga de trabajo esté habilitada en el clúster. Luego, toma nota del ID del proyecto de flota como (FLEET_ID) para los pasos futuros.

9. La herramienta acepta kubeConfig y kubeContext para seleccionar el clúster en el que se realizan las operaciones. Si estos argumentos no se pasan, se usa la configuración o el contexto predeterminado.

   • Para agregar las credenciales de un clúster de GKE a kubeConfig, usa el siguiente comando:

     gcloud container clusters get-credentials CLUSTER_NAME
     

   • Para cambiar el contexto kubectl actual o pasar el contexto a la herramienta, usa el siguiente comando:

     kubectl config get-contexts
     kubectl config use-context CLUSTER_NAME
     

Inicializa la CA nueva

1. Los pasos necesarios para inicializar la CA nueva dependen de la CA nueva a la que migras. Realiza estos pasos en cada clúster de flota en el que desees migrar la CA.

   CA de Mesh

   Llama al subcomando initialize de la herramienta de utilidad.

   Si especificas opciones de configuración personalizadas de Kubernetes, haz lo siguiente:

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

   En caso contrario:

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

   Servicio de CA

   a. Sigue los pasos necesarios para inicializar Certificate Authority Service. Toma nota del CA_POOL.

   b. Llama al subcomando initialize de la herramienta de utilidad:

   Si especificas opciones de configuración personalizadas de Kubernetes, haz lo siguiente:

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

   En caso contrario:

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

Agregar trustAnchors en toda la malla para todos los clústeres de la flota

1. Repite los pasos a continuación para la CA nueva y la CA previa en todos los clústeres que forman parte de la flota.

2. Descarga los trustAnchors de la CA:

   CA de Mesh

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

   Servicio de CA

   Almacena el certificado de CA en un archivo:

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

3. Agrega trustAnchors de la CA:

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

4. Verifica que todas las cargas de trabajo de la flota hayan recibido los trustAnchors. En el argumento de espacios de nombres, pasa todos los espacios de nombres en los que se implementan las cargas de trabajo:

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

   Resultado esperado:

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

Migra la CA

1. Migra la configuración de CA. El comando requerido depende de la nueva CA a la que migres.

   CA de Mesh

   ./migrate_ca migrate-ca --ca mesh_ca
   

   Servicio de CA

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

2. Reinicia todas las cargas de trabajo.

   Nota: Este paso es opcional si instalaste el plano de datos administrado. Esto se debe a que Google administra la vida útil del proxy y realiza este paso de forma automática durante una actualización administrada.

   Para minimizar el riesgo de tiempo de inactividad del tráfico TLS, este paso debe afectar primero a la menor cantidad de cargas de trabajo. Solo reinicia las cargas de trabajo asociadas con la revisión ASM_REVISION del plano de control. Por ejemplo, si todas las cargas de trabajo en el espacio de nombres de Kubernetes NAMESPACE están asociadas con el mismo plano de control de Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACE
   

3. Verifica que las conexiones de mTLS funcionen entre cargas de trabajo en el espacio de nombres reiniciado y otras cargas de trabajo antes de repetir los pasos 1 y 2 para todos los espacios de nombres y todos los clústeres que forman parte de la flota. Si surgen cargas de trabajo más nuevas y no se interrumpe el tráfico de la malla, repite los pasos 1 y 2 para todos los espacios de nombres y clústeres que forman parte de la flota. De lo contrario, realiza una reversión de la configuración de CA más reciente.

4. Verifica que todas las cargas de trabajo usen la nueva configuración de CA:

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

   Resultado esperado:

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

Realiza una reversión

1. Revierte la configuración de CA y quita los trustAnchors recién configurados:

   ./migrate-ca rollback
   

2. Reinicia todas las cargas de trabajo. Asegúrate de reiniciar solo las cargas de trabajo asociadas con la revisión ASM_REVISION del plano de control. Por ejemplo, si todas las cargas de trabajo del espacio de nombres de Kubernetes NAMESPACES están asociadas con el mismo plano de control de Cloud Service Mesh.

   kubectl rollout restart deployment -n NAMESPACES
   

3. (Opcional) Verifica que todas las cargas de trabajo usen la configuración de CA previa.

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

4. Repite los pasos 1 al 3 para todos los clústeres de la flota en los que las cargas de trabajo usan el plano de control ASM_REVISION.

¡Felicitaciones! Realizaste correctamente una migración de CA en el lugar.