Versión 1.15

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

Migración de CA en el lugar

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 Anthos Service Mesh v1.13 o posterior con la CA de Mesh a Certificate Authority Service.
  • Migra un plano de control de Anthos Service Mesh administrado en un canal de versiones que se asigne a la versión v1.13 o posterior con la CA de Mesh a Certificate Authority Service.

Limitaciones

Las migraciones y actualizaciones de CA en su lugar solo son compatibles con Anthos Service Mesh v1.13 o versiones posteriores. 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:

Además, asegúrate de estar usando Anthos 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 CA por revisión o canal instalado de Anthos 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 modificar esto e intentará migrar la configuración de la CA con la CRD de ProxyConfig cuando sea posible.

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

  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
    
  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 CA en el lugar requiere que reinicies tus cargas de trabajo, asegúrate de que el presupuesto de interrupción del Pod esté configurado de forma correcta y todas las aplicaciones cuya CA deba migrarse tenga 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.

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