Anthos Service Mesh y Traffic Director ahora son Cloud Service Mesh. Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Se usó la API de Cloud Translation para traducir esta página.

Migración de AC local

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 que se indican en esta guía para migrar una versión 1.13 de Cloud Service Mesh en el clúster. o un plano de control posterior con la autoridad certificadora de Cloud Service Mesh para Certificate Authority Service.

Limitaciones

Las migraciones y actualizaciones de AC en su lugar solo son compatibles con Cloud Service Mesh v1.13 o versiones posteriores.

Requisitos previos

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

Además, asegúrate de utilizar la versión 1.13 o posterior de la malla de servicios de Cloud.

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 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:

Prepárate para la migración.
Inicializa la CA nueva.
Agrega trustAnchors en toda la malla para todos los clústeres de la flota.
Migra la CA.
Realiza una reversión.

Prepárate para la migración

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

Haz que la herramienta sea ejecutable:
```
chmod +x migrate_ca
```
Configura el directorio de trabajo:
```
./migrate_ca setup --output_dir OUTPUT_DIR
```
Nota: Si no especificas un directorio de trabajo, se creará uno temporal crear. Deberás usarlo como directorio de trabajo para todos los pasos posteriores.
Cambia el directorio de trabajo al OUTPUT_DIR especificado en el paso anterior.
```
cd OUTPUT_DIR
```
Ejecuta el siguiente comando para asegurarte de que se cumplan todos los requisitos previos:
```
./migrate_ca check-prerequisites
```

Toma nota de la revisión (ASM_REVISION) del plano de control asociado con la CA anterior que se migra.

En el clúster

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

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

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

Repite los siguientes pasos para la AC nueva y la AC anterior en todos los clústeres que forman parte de la flota.

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

Agrega trustAnchors de la CA:

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

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

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
```
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 asociados con la misma malla de servicios de Cloud plano de control.
```
kubectl rollout restart deployment -n NAMESPACE
```
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.

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

Revierte la configuración de CA y quita los trustAnchors recién configurados:
```
./migrate-ca rollback
```
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 en el espacio de nombres de Kubernetes NAMESPACES están asociados con la misma malla de servicios de Cloud plano de control.
```
kubectl rollout restart deployment -n NAMESPACES
```
(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
```
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.