Anthos Service Mesh 1.11 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

Migra a la CA de Mesh

La migración a la autoridad certificada de Anthos Service Mesh (CA de Mesh) desde la CA de Istio (también conocida como Citadel) requiere la migración de la raíz de confianza. Antes de Anthos Service Mesh 1.10, si querías migrar de Istio en Google Kubernetes Engine (GKE) a Anthos Service Mesh con la CA de Mesh, debías programar un tiempo de inactividad porque Anthos Service Mesh no podía cargar varios certificados raíz. Por lo tanto, durante la migración, las cargas de trabajo recién implementadas confían en el certificado raíz nuevo, mientras que otras confían en el certificado raíz anterior. Las cargas de trabajo que usan certificados firmados por diferentes certificados raíz no pueden autenticarse entre sí. Esto significa que el tráfico de TLS mutua (mTLS) se interrumpe durante la migración. Todo el clúster se recupera por completo solo cuando el plano de control y todas las cargas de trabajo en todos los espacios de nombres se vuelven a implementar con el certificado de la CA de Mesh. Si la malla tiene varios clústeres con cargas de trabajo que envían solicitudes a cargas de trabajo en otro clúster, todas las cargas de trabajo en esos clústeres también deben actualizarse.

En esta página, se describe cómo migrar de la CA de Istio a la CA de Mesh con un tiempo de inactividad mínimo o nulo. Sigue los pasos de esta guía para los siguientes casos de uso:

Migra de Istio en GKE al plano de control en clúster 1.11.8-asm.4 de Anthos Service Mesh con la CA de Mesh.
Actualiza de Anthos Service Mesh 1.9 or a 1.10 patch release con la CA de Istio al plano de control en clúster 1.11.8-asm.4 de Anthos Service Mesh con la CA de Mesh.

Limitaciones

La CA de Mesh solo es compatible con GKE.
Todos los clústeres de GKE deben estar en el mismo proyecto de Google Cloud.

Requisitos previos

Sigue los pasos que se indican en Comenzar para hacer lo siguiente:

Herramientas requeridas

Durante la migración, debes ejecutar una herramienta proporcionada por Google, migrate_ca, para validar lo siguiente para cada Pod del clúster:

El certificado raíz de la CA de Istio y la CA de Mesh.
El certificado mTLS de carga de trabajo emitido por la CA de Istio y la CA de Mesh.
Los dominios de confianza configurados por la CA de Istio y la CA de Mesh.

Esta herramienta tiene las siguientes dependencias:

awk
grep
istioctl Cuando ejecutas la herramienta install_asm, descarga la versión de istioctl que coincide con la versión de Anthos Service Mesh que instalarás.
jq
kubectl
openssl

Descripción general de la migración

Para migrar a la CA de Mesh, debes seguir el proceso de migración basado en revisiones (también conocido como “actualización canary”). Con una migración basada en revisiones, se implementa una nueva revisión del plano de control junto con el plano de control existente. Luego, debes migrar de forma gradual tus cargas de trabajo a la revisión nueva, lo que te permite supervisar el efecto de la migración a lo largo del proceso. 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 de Mesh y las cargas de trabajo que usan la CA de Istio.

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

Distribuye la raíz de confianza de la CA de Mesh.
1. Instala una revisión nueva del plano de control que use la CA de Istio con una opción que distribuirá la raíz de confianza de la CA de Mesh.
2. Migra cargas de trabajo al nuevo plano de control, espacio de nombres por espacio de nombres, y prueba tu aplicación. Cuando todas las cargas de trabajo se migren correctamente al nuevo plano de control, quita el plano de control anterior.
Migra a la CA de Mesh. Ahora que todos los proxies de sidecar están configurados con la raíz de confianza antigua y la raíz de confianza de la CA de Mesh, puedes migrar a la CA de Mesh sin tiempo de inactividad. De nuevo, debes seguir el proceso de migración basado en revisiones:
1. Instala una revisión del plano de control con la CA de Mesh habilitada.
2. Migra cargas de trabajo a la nueva revisión del plano de control, espacio de nombres por espacio de nombres, y prueba tu aplicación. Cuando todas las cargas de trabajo se migren correctamente al nuevo plano de control, quita el plano de control anterior.
3. Quita los secretos de CA del clúster que estén asociados con la CA anterior y reinicia el plano de control nuevo.

Distribuye la raíz de confianza de la CA de Mesh

Antes de que puedas migrar a la CA de Mesh, todos los clústeres de GKE en la malla deben tener Anthos Service Mesh 1.10 o una versión posterior, y todos los clústeres deben configurarse con una opción del plano de control que active el raíz de confianza para que la CA de Mesh se distribuya a los proxies de todas las cargas de trabajo del clúster. Cuando finaliza el proceso, cada proxy se configura con la raíz de confianza anterior y la nueva. Con este esquema, cuando migres a la CA de Mesh, las cargas de trabajo que usen la CA de Mesh podrán autenticarse con cargas de trabajo que usen la CA anterior.

Instala una revisión nueva del plano de control

Instala una revisión del plano de control con una opción que distribuya la raíz de confianza de la CA de Mesh.

Sigue los pasos de Comenzar a fin de prepararte para usar una herramienta proporcionada por Google, asmcli, y de instalar la revisión nueva del plano de control.
Asegúrate de tener la versión de asmcli que instala Anthos Service Mesh 1.10 o versiones posteriores:
```
./asmcli --version
```

Ejecuta asmcli install. En el siguiente comando, reemplaza los marcadores de posición por tus valores.

 ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH \
   --option ca-migration-citadel \
   --revision_name REVISION_1 \
   --output_dir DIR_PATH

--fleet_id El ID del proyecto host de la flota.
--kubeconfig es la ruta al archivo kubeconfig. Puedes especificar una ruta de acceso relativa o una completa. La variable de entorno $PWD no funciona aquí.
--output_dir: Incluye esta opción para especificar un directorio en el que asmcli descarga el paquete anthos-service-mesh y extrae el archivo de instalación, que contiene istioctl, muestras y manifiestos. De lo contrario, asmcli descarga los archivos en un directorio tmp. Puedes especificar una ruta de acceso relativa o una completa. La variable de entorno $PWD no funciona aquí.
--enable_all Permite que la herramienta realice las siguientes acciones:
- Otorga los permisos de IAM necesarios.
- Habilita las API de Google necesarias.
- Configura una etiqueta en el clúster que identifique la malla.
- Registra el clúster en la flota si aún no está registrado.
-ca citadel para evitar el tiempo de inactividad, especifica la CA de Istio (la opción citadel corresponde a la CA de Istio). No cambies a la CA de Mesh en este momento.
--ca_cert es el certificado intermedio.
--ca_key: Es la clave para el certificado intermedio.
--root_cert es el certificado raíz.
--cert_chain es la cadena de certificados.
--option ca-migration-citadel.Cuando vuelves a implementar tus cargas de trabajo, esta opción activa la nueva raíz de confianza para distribuirla a los proxies de sidecar de las cargas de trabajo.
REVISION_1: Recomendado Una etiqueta de revisión es un par clave-valor que se configura en el plano de control. La clave de la etiqueta de revisión siempre es istio.io/rev. De forma predeterminada, la herramienta establece el valor de la etiqueta de revisión según la versión de Anthos Service Mesh, por ejemplo: asm-1118-4. Te recomendamos incluir esta opción y reemplazar REVISION_1 por un nombre que describa la instalación, como asm-1118-4-distribute-root. El nombre debe ser una etiqueta DNS-1035 y debe contener caracteres alfanuméricos en minúscula, o -, comienza con un carácter alfabético y termina con un carácter alfanumérico (como my-name o abc-123).

Migra las cargas de trabajo al nuevo plano de control

Para terminar de distribuir la raíz de confianza nueva, debes etiquetar los espacios de nombres con la etiqueta de revisión istio.io/rev=<var>REVISION_1</var>-distribute-root y reiniciar las cargas de trabajo. Cuando pruebes tus cargas de trabajo después de reiniciarlas, debes ejecutar una herramienta para validar que el proxy de sidecar esté configurado con la raíz de confianza anterior y nueva para la CA de Mesh.

Establece el contexto actual para kubectl. En el siguiente comando, cambia --region por --zone si tienes un clúster de una sola zona.
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID \
    --region=CLUSTER_LOCATION
```

Descarga la herramienta de validación:

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

Configura el bit ejecutable en la herramienta:
```
chmod +x migrate_ca
```
La herramienta migrate_ca llama a istioctl, que depende de la versión. La herramienta asmcli agrega un symlink a istioctl en el directorio que especificaste para --output_dir. Asegúrate de que el directorio esté al comienzo de tu ruta de acceso. En el siguiente comando, reemplaza ISTIOCTL_PATH por el directorio que contiene istioctl que descargó la herramienta.
```
export PATH=ISTIOCTL_PATH:$PATH
which istioctl
echo $PATH
```

Obtén la etiqueta de revisión que se encuentra en istiod y la istio-ingressgateway.

kubectl get pod -n istio-system -L istio.io/rev

El resultado es similar al siguiente:

NAME                                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-5fd454f8ff-t7w9x                            1/1     Running   0          36m   default
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-z2s9p   1/1     Running   0          18m   asm-195-2-distribute-root
istio-ingressgateway-asm-195-2-distribute-root-c6ccfbdbd-zr2cs   1/1     Running   0          18m   asm-195-2-distribute-root
istiod-68bc495f77-shl2h                                          1/1     Running   0          36m   default
istiod-asm-195-2-distribute-root-6f764dbb7c-g9f8c                1/1     Running   0          18m   asm-195-2-distribute-root
istiod-asm-195-2-distribute-root-6f764dbb7c-z7z9s                1/1     Running   0          18m   asm-195-2-distribute-root

En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la revisión nueva, que coincide con la etiqueta de revisión que especificaste cuando ejecutaste asmcli install. En este ejemplo, el valor es asm-1118-4-distribute-root.
Debes borrar la revisión anterior de istiod cuando termines de migrar las cargas de trabajo a la revisión nueva. Anota el valor en la etiqueta de revisión de la revisión de istiod anterior. En el resultado de ejemplo, se muestra una migración desde Istio, en la que se usa la revisión default.

Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, reemplaza NAMESPACE por el espacio de nombres que deseas etiquetar.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_1 istio-injection- --overwrite
```
Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection antes. Debido a que la inserción automática falla si un espacio de nombres tiene tanto la istio-injection como la etiqueta de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la acción de quitar la etiqueta istio-injection.

Reinicia los Pods para activar la reinserción:

kubectl rollout restart deployment -n NAMESPACE

Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.
Valida que los proxies de sidecar de todas las cargas de trabajo en el clúster estén configurados con los certificados raíz antiguos y nuevos:
```
./migrate_ca check-root-cert
```
Resultado esperado:
```
Namespace: foo
httpbin-66cdbdb6c5-pmzps.foo trusts [CITADEL MESHCA]
sleep-64d7d56698-6tmjm.foo trusts [CITADEL MESHCA]
```
Si necesitas migrar puertas de enlace, sigue los pasos en Actualizaciones canary (avanzadas) para instalar nuevas implementaciones de puerta de enlace. Debes tener en cuenta lo siguiente:
- Usa REVISION_1 como etiqueta de revisión.
- Implementa los recursos de la puerta de enlace en el mismo espacio de nombres que la puerta de enlace de la instalación anterior para realizar una migración sin tiempo de inactividad. Asegúrate de que los recursos del servicio que apuntan a la puerta de enlace más antigua también incluyan las implementaciones más recientes.
- No borres las implementaciones de puerta de enlace más antiguas hasta que estés seguro de que tu aplicación funcione de forma correcta (después del siguiente paso).
Si estás seguro de que tu aplicación funciona como se esperaba, continúa con los pasos para completar la transición a la versión nueva de istiod. Si hay un problema con tu aplicación, sigue los pasos para revertirla.
Completa la transición
Si estás seguro de que tu aplicación funciona como se esperaba, quita el plano de control anterior para completar la transición a la nueva versión.
1. Cambia al directorio en el que se encuentran los archivos del repositorio de GitHub anthos-service-mesh.
2. Configura el webhook de validación para usar el plano de control nuevo.
  kubectl apply -f asm/istio/istiod-service.yaml
3. Borra el Deployment istio-ingressgateway anterior. El comando que debes ejecutar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh:
  Migra
  Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Actualizar
  Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, reemplaza OLD_REVISION por la etiqueta de revisión para la versión anterior de istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
4. Borra la revisión anterior de istiod. El comando que debes usar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh.
  Migra
  Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Actualizar
  Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, asegúrate de que OLD_REVISION coincida con la etiqueta de revisión de la versión anterior de istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
5. Quita la versión anterior de la configuración IstioOperator.
  kubectl delete IstioOperator installed-state-OLD_REVISION -n istio-system
  El resultado esperado es similar al siguiente:
  istiooperator.install.istio.io "installed-state-OLD_REVISION" deleted
Revertir
Si encontraste un problema cuando probaste tu aplicación con la versión nueva de istiod, sigue estos pasos para realizar una reversión a la versión anterior:
1. Borra las implementaciones de puerta de enlace nuevas instaladas como parte del paso 11.
2. Vuelve a etiquetar tu espacio de nombres para habilitar la inserción automática con la versión anterior de istiod. El comando que uses depende de si usaste una etiqueta de revisión o istio-injection=enabled con la versión anterior.
  - Si usaste una etiqueta de revisión para la inserción automática, haz lo siguiente:
    
    kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
  - Si usaste istio-injection=enabled:
    
    kubectl label namespace NAMESPACE istio.io/rev- istio-injection=enabled --overwrite
  Resultado esperado:
  namespace/NAMESPACE labeled
3. Confirma que la etiqueta de revisión en el espacio de nombres coincida con la etiqueta de revisión en la versión anterior de istiod:
  kubectl get ns NAMESPACE --show-labels
4. Reinicia los Pods para activar la reinserción a fin de que los proxies tengan la versión previa:
  kubectl rollout restart deployment -n NAMESPACE
5. Quita el Deployment istio-ingressgateway nuevo.
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
6. Quita la revisión nueva de istiod.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
7. Quita la configuración nueva de IstioOperator.
  kubectl delete IstioOperator installed-state-asm-1118-4-distribute-root -n istio-system
  El resultado esperado es similar al siguiente:
  istiooperator.install.istio.io "installed-state-asm-1118-4-distribute-root" deleted