Estás viendo la documentación heredada de Service Mesh v1.18.

Versiones disponibles

Cloud Service Mesh
Archivo 1.22
Archivo 1.21
Archivo 1.20
Archivo 1.19
Archivo 1.18

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

Migración basada en versiones canary a la CA de Mesh

La migración a la autoridad certificadora de Cloud 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 Cloud Service Mesh 1.10, si querías migrar de Istio en Google Kubernetes Engine (GKE) a Cloud Service Mesh con la AC de Mesh, debías programar un tiempo de inactividad porque Cloud 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.

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 de Cloud Service Mesh 1.18.7-asm.26 con la AC de Mesh.
Actualiza de Cloud Service Mesh 1.15 or a 1.16 patch release con la AC de Istio al plano de control en clúster 1.18.7-asm.26 de Cloud Service Mesh con la AC de Mesh.

Limitaciones

Todos los clústeres de GKE deben estar en el mismo proyecto de Google Cloud.

Requisitos previos

Sigue los pasos que se indican en Instala herramientas dependientes y valida el clúster 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 se ejecuta asmcli install, se descarga la versión de istioctl que coincide con la versión de Cloud Service Mesh que instalas.
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 AC de Mesh, todos los clústeres de GKE en la malla deben tener Cloud 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 AC 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 en Instala las herramientas dependientes y valida el clúster para prepararte para usar una herramienta proporcionada por Google, asmcli, a fin de instalar la nueva revisión del plano de control.
Asegúrate de tener la versión de asmcli que instala Cloud Service Mesh 1.11 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 Cloud Service Mesh, por ejemplo: asm-1187-26. Te recomendamos incluir esta opción y reemplazar REVISION_1 por un nombre que describa la instalación, como asm-1187-26-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-1187-26-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 el comportamiento de la inserción automática no se define cuando 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 Cloud Service Mesh se aseguran de forma explícita de que solo se establezca uno.

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 Cloud 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 Cloud 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 Cloud 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 Cloud 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-1187-26-distribute-root -n istio-system
  El resultado esperado es similar al siguiente:
  istiooperator.install.istio.io "installed-state-asm-1187-26-distribute-root" deleted

Migra a la CA de Mesh

Ahora que los proxies de sidecar de todas las cargas de trabajo se configuraron con la raíz de confianza antigua y la nueva para la CA de la Mesh, los pasos para migrar a la CA de Mesh son similares a los que usaste para distribuir la raíz de confianza de la CA de Mesh:

Instala un nuevo plano de control con la CA de Mesh habilitada

Usa asmcli install para instalar una revisión nueva del plano de control que tenga habilitada la CA de Mesh.

Si personalizaste la instalación anterior, debes especificar los mismos archivos de superposición cuando ejecutes asmcli install.
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 \
   --output_dir DIR_PATH \
   --enable_all \
   --ca mesh_ca \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
   --option ca-migration-meshca \
  --revision_name REVISION_2 \
  --output_dir DIR_PATH \
  OVERLAYS
```

Migra las cargas de trabajo al nuevo plano de control

Para finalizar la instalación, debes etiquetar los espacios de nombres con la etiqueta de revisión nueva y reiniciar las cargas de trabajo.

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-asm-1187-26-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-1187-26-distribute-root
istio-ingressgateway-asm-1187-26-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-1187-26-distribute-root
istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1187-26-meshca-ca-migration
istio-ingressgateway-asm-1187-26-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1187-26-meshca-ca-migration
istiod-asm-1187-26-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-1187-26-distribute-root
istiod-asm-1187-26-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-1187-26-distribute-root
istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1187-26-meshca-ca-migration
istiod-asm-1187-26-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1187-26-meshca-ca-migration

En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la versión nueva. En este ejemplo, el valor es asm-1187-26-meshca-ca-migration.
Observa también el valor en la etiqueta de revisión de la versión istiod anterior. Necesitarás esto para borrar la versión anterior de istiod cuando termines de migrar las cargas de trabajo a la versión nueva. En el ejemplo, el valor de la etiqueta de revisión para la revisión anterior es asm-1187-26-distribute-root.

Agrega la nueva etiqueta de revisión a un espacio de nombres. En el siguiente comando, reemplaza NAMESPACE por el espacio de nombres que deseas etiquetar.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
```

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. Asegúrate de que la comunicación de mTLS funcione entre las cargas de trabajo del espacio de nombres anterior y las del espacio de nombres más reciente.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.
Sigue los pasos que se describen en Actualizaciones locales para actualizar las implementaciones de puerta de enlace más antiguas instaladas en el paso 11 de la sección anterior a la última revisión REVISION_2.
Si estás seguro de que tu aplicación funciona como se esperaba, continúa con los pasos para completar la transición al nuevo plano de control. 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. 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. En el siguiente comando, reemplaza OLD_REVISION por la etiqueta de revisión para 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 configuración anterior de 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 revisión nueva de istiod, sigue estos pasos para realizar una reversión a la revisión anterior:
1. Sigue los pasos en la página sobre actualizaciones locales para cambiar las implementaciones de puerta de enlace actualizadas en el paso 6 de esta sección a la revisión anterior.REVISION_1
2. Vuelve a etiquetar tu espacio de nombres para habilitar la inserción automática con la revisión istiod anterior.
  kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --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_2 -n istio-system --ignore-not-found=true
6. Quita la versión nueva de istiod. Asegúrate de que la etiqueta de revisión del siguiente comando coincida con tu revisión.
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_2 -n istio-system --ignore-not-found=true
7. Quita la versión nueva de la configuración IstioOperator.
  kubectl delete IstioOperator installed-state-REVISION_2 -n istio-system
  El resultado esperado es similar al siguiente:
  istiooperator.install.istio.io "installed-state-REVISION_2" deleted

Quita los secretos de CA y reinicia el plano de control nuevo

Conserva los secretos solo por si los necesitas:

kubectl get secret/cacerts -n istio-system -o yaml > save_file_1
kubectl get secret/istio-ca-secret -n istio-system -o yaml > save_file_2

Quita los secretos de CA del clúster asociados con la CA anterior:

kubectl delete secret cacerts istio-ca-secret -n istio-system --ignore-not-found

Reinicia el plano de control recién instalado. Esto garantiza que la raíz de confianza anterior se limpie de todas las cargas de trabajo que se ejecutan en la malla.
```
kubectl rollout restart deployment -n istio-system
```

Migración basada en versiones canary a la CA de Mesh

Limitaciones

Requisitos previos

Herramientas requeridas

Descripción general de la migración

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

Instala una revisión nueva del plano de control

Migra las cargas de trabajo al nuevo plano de control

Completa la transición

Migra

Actualizar

Migra

Actualizar

Revertir

Migra a la CA de Mesh

Instala un nuevo plano de control con la CA de Mesh habilitada

Migra las cargas de trabajo al nuevo plano de control

Completa la transición

Revertir

Quita los secretos de CA y reinicia el plano de control nuevo