Migración basada en canary a la autoridad de certificación de Cloud Service Mesh

Para migrar a la autoridad de certificación de Cloud Service Mesh desde la autoridad de certificación de Istio (también conocida como Citadel), debes migrar 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 autoridad de certificación de Cloud Service Mesh, tenías que 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 nuevo certificado raíz, mientras que otras confían en el antiguo. 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 mutuo (mTLS) se interrumpe durante la migración. Todo el clúster solo se recupera por completo cuando el plano de control y todas las cargas de trabajo de todos los espacios de nombres se vuelven a implementar con el certificado de la autoridad de certificación de Cloud Service Mesh. Si tu malla tiene varios clústeres con cargas de trabajo que envían solicitudes a cargas de trabajo de otro clúster, todas las cargas de trabajo de esos clústeres también deben actualizarse.

Sigue los pasos que se indican en esta guía para los siguientes casos prácticos:

• Migrar de Istio en GKE al plano de control en el clúster de Cloud Service Mesh 1.19.10-asm.9 con la autoridad de certificación de Cloud Service Mesh.
• Actualiza de Cloud Service Mesh 1.15 or a 1.16 patch release con Istio CA al plano de control en el clúster de Cloud Service Mesh 1.19.10-asm.9 con la autoridad de certificación de Cloud Service Mesh.

Limitaciones

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

Requisitos previos

Sigue los pasos que se indican en Instalar herramientas dependientes y validar el clúster para:

• Instalar las herramientas necesarias
• Descargar asmcli
• Conceder permisos de administrador de clústeres
• Validar el proyecto y el clúster

Herramientas necesarias

Durante la migración, ejecuta una herramienta proporcionada por Google, migrate_ca, para validar lo siguiente en cada pod del clúster:

• El certificado raíz de la AC de Istio y de la AC de Cloud Service Mesh.
• El certificado mTLS de la carga de trabajo emitido por la CA de Istio y por la autoridad de certificación de Cloud Service Mesh.
• Los dominios de confianza configurados por la AC de Istio y la AC de Cloud Service Mesh.

Esta herramienta tiene las siguientes dependencias:

• awk
• grep
• istioctl Al ejecutar asmcli install, se descarga la versión de istioctl que coincide con la versión de Cloud Service Mesh que estás instalando.
• jq
• kubectl
• openssl

Información general sobre la migración

Para migrar a la autoridad de certificación de Cloud Service Mesh, debes seguir el proceso de migración basado en revisiones (también conocido como "actualización canary"). En una migración basada en revisiones, se despliega una nueva revisión del plano de control junto con el plano de control actual. Después, traslada gradualmente tus cargas de trabajo a la nueva revisión, lo que te permite monitorizar el efecto de la migración durante el proceso. Durante el proceso de migración, la autenticación y la autorización funcionan perfectamente entre las cargas de trabajo que usan la autoridad de certificación de Cloud Service Mesh y las cargas de trabajo que usan la autoridad de certificación de Istio.

A continuación, se muestra un resumen de la migración a la autoridad de certificación de Cloud Service Mesh:

1. Distribuye la raíz de confianza de la autoridad de certificación de Cloud Service Mesh.

   1. Instala una nueva revisión del plano de control que use la AC de Istio con una opción que distribuya la raíz de confianza de la autoridad de certificación de Cloud Service Mesh.

   2. Migra las 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 hayan migrado correctamente al nuevo plano de control, elimina el antiguo.

2. Migra a la autoridad de certificación de Cloud Service Mesh. Ahora que todos los proxies sidecar están configurados con la antigua raíz de confianza y la raíz de confianza de la autoridad de certificación de Cloud Service Mesh, puedes migrar a la autoridad de certificación de Cloud Service 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 autoridad de certificación de Cloud Service Mesh habilitada.

   2. Migra las 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 hayan migrado correctamente al nuevo plano de control, elimina el antiguo.

   3. Elimina los secretos de la CA del clúster que estén asociados a la CA antigua y reinicia el nuevo plano de control.

Distribuir la raíz de confianza de la autoridad de certificación de Cloud Service Mesh

Para poder migrar a la autoridad de certificación de Cloud Service Mesh, todos los clústeres de GKE de 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 de plano de control que active la distribución de la raíz de confianza de la autoridad de certificación de Cloud Service Mesh a los proxies de todas las cargas de trabajo del clúster. Cuando finalice el proceso, cada proxy se configurará con la raíz de confianza antigua y la nueva. Con este esquema, cuando migres a la autoridad de certificación de Cloud Service Mesh, las cargas de trabajo que usen la autoridad de certificación de Cloud Service Mesh podrán autenticarse con las cargas de trabajo que usen la antigua autoridad de certificación.

Instalar una nueva revisión 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 autoridad de certificación de Cloud Service Mesh.

1. Sigue los pasos que se indican en Instalar herramientas dependientes y validar el clúster para preparar el uso de una herramienta proporcionada por Google, asmcli, para instalar la nueva revisión del plano de control.

2. Asegúrate de que tienes la versión de asmcli que instala Cloud Service Mesh 1.11 o una posterior:

   ./asmcli --version
   

3. Ejecuta asmcli install. En el siguiente comando, sustituya los marcadores de posición por sus 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 del proyecto host de la flota.
• --kubeconfig La ruta al archivo kubeconfig Puede especificar una ruta relativa o una ruta completa. La variable de entorno $PWD no funciona aquí.
• --output_dir Incluye esta opción para especificar un directorio en el que asmcli descargue el paquete anthos-service-mesh y extraiga el archivo de instalación, que contiene istioctl, muestras y manifiestos. De lo contrario, asmcli descarga los archivos en un directorio tmp. Puede especificar una ruta relativa o una ruta completa. La variable de entorno $PWD no funciona aquí.
• --enable_all Permite que la herramienta haga lo siguiente:
  • Concede los permisos de gestión de identidades y accesos necesarios.
  • Habilita las APIs de Google necesarias.
  • Define una etiqueta en el clúster que identifique la malla.
  • Registra el clúster en la flota si aún no lo has hecho.
• -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 autoridad de certificación de Cloud Service Mesh en este momento.
• --ca_cert El certificado intermedio.
• --ca_key La clave del certificado intermedio
• --root_cert El certificado raíz.
• --cert_chain La cadena de certificados.
• --option ca-migration-citadel Cuando vuelvas a implementar tus cargas de trabajo, esta opción hará que la nueva raíz de confianza se distribuya a los proxies sidecar de las cargas de trabajo.
• REVISION_1: recomendado. Una etiqueta de revisión es un par clave-valor que se define en el plano de control. La clave de la etiqueta de revisión siempre es istio.io/rev. De forma predeterminada, la herramienta asigna el valor de la etiqueta de revisión en función de la versión de Cloud Service Mesh. Por ejemplo, asm-11910-9. Te recomendamos que incluyas esta opción y sustituyas REVISION_1 por un nombre que describa la instalación, como asm-11910-9-distribute-root. El nombre debe ser una etiqueta DNS-1035 y debe constar de caracteres alfanuméricos en minúscula o -, empezar por un carácter alfabético y terminar por un carácter alfanumérico (como my-name o abc-123).

Migrar cargas de trabajo al nuevo plano de control

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

1. Define el contexto actual de 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
   

2. Descarga la herramienta de validación:

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

3. Define el bit ejecutable en la herramienta:

   chmod +x migrate_ca
   

4. La herramienta migrate_ca llama a istioctl, que depende de la versión. La herramienta asmcli añade un enlace simbólico a istioctl en el directorio que hayas especificado para --output_dir. Asegúrate de que el directorio esté al principio de la ruta. En el siguiente comando, sustituye ISTIOCTL_PATH por el directorio que contiene istioctl que ha descargado la herramienta.

   export PATH=ISTIOCTL_PATH:$PATH
   which istioctl
   echo $PATH
   

5. Obtiene la etiqueta de revisión que está en istiod y el istio-ingressgateway.

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

   El resultado debería ser 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

   1. En el resultado, en la columna REV, anota el valor de la etiqueta de revisión de la nueva revisión, que coincide con la etiqueta de revisión que especificaste al ejecutar asmcli install. En este ejemplo, el valor es asm-11910-9-distribute-root.

   2. Debes eliminar la revisión antigua de istiod cuando termines de mover las cargas de trabajo a la nueva revisión. Anota el valor de la etiqueta de revisión de la revisión antigua de istiod. El resultado de ejemplo muestra una migración de Istio, que usa la revisión default.

6. Añade la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, sustituye NAMESPACE por el espacio de nombres que quieras 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. Como el comportamiento de la inyección automática no está definido cuando un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Cloud Service Mesh se aseguran explícitamente de que solo se defina una.

7. Reinicia los pods para activar la reinyección.

   kubectl rollout restart deployment -n NAMESPACE
   

8. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente.

9. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reinicia los pods.

10. Valida que los proxies sidecar de todas las cargas de trabajo del 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]

11. Si necesitas migrar pasarelas, sigue los pasos que se indican en Actualizaciones de Canary (avanzadas) para instalar nuevas implementaciones de pasarela. Debes tener en cuenta lo siguiente:

    • Usa REVISION_1 como etiqueta de revisión.
    • Implementa los recursos de la pasarela en el mismo espacio de nombres que la pasarela de la instalación anterior para realizar una migración sin tiempo de inactividad. Asegúrate de que los recursos de servicio que apuntan a la antigua pasarela también incluyan las implementaciones más recientes.
    • No elimines las implementaciones de la antigua pasarela hasta que te asegures de que tu aplicación funciona correctamente (después del paso siguiente).

12. Si estás seguro de que tu aplicación funciona correctamente, sigue los pasos para cambiar a la nueva versión de istiod. Si hay algún problema con tu aplicación, sigue los pasos para revertir la versión.

    Completar la transición

    Si estás seguro de que tu aplicación funciona correctamente, elimina el antiguo plano de control para completar la transición a la nueva versión.

    1. Cambia al directorio en el que se encuentran los archivos del anthos-service-mesh repositorio de GitHub.

    2. Configura el webhook de validación para que use el nuevo plano de control.

       kubectl apply -f asm/istio/istiod-service.yaml
       

    3. Elimina la istio-ingressgatewayimplementación antigua. El comando que ejecutes dependerá de si vas a migrar desde Istio o a actualizar desde una versión anterior de Cloud Service Mesh:

       Migrar

       Si has migrado desde Istio, el antiguo istio-ingressgateway no tiene una etiqueta de revisión.

       kubectl delete deploy/istio-ingressgateway -n istio-system
       

       Actualizar

       Si has actualizado desde una versión anterior de Cloud Service Mesh, en el siguiente comando, sustituye OLD_REVISION por la etiqueta de revisión de 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. Elimina la revisión antigua de istiod. El comando que uses dependerá de si vas a migrar desde Istio o a actualizar desde una versión anterior de Cloud Service Mesh.

       Migrar

       Si has migrado desde Istio, el antiguo istio-ingressgateway no tiene una etiqueta de revisión.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
       

       Actualizar

       Si has actualizado 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. Elimina la versión anterior de la configuración 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

    Restauración

    Si has tenido algún problema al probar tu aplicación con la nueva versión de istiod, sigue estos pasos para volver a la versión anterior:

    1. Elimina las nuevas implementaciones de pasarela instaladas en el paso 11.

    2. Cambia el nombre de tu espacio de nombres para habilitar la inyección automática con la versión anterior de istiod. El comando que utilices dependerá de si has usado una etiqueta de revisión o istio-injection=enabled con la versión anterior.

       • Si ha usado una etiqueta de revisión para la inyección automática:

         kubectl label namespace NAMESPACE istio.io/rev=OLD_REVISION --overwrite
         

       • Si has usado 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 del espacio de nombres coincide con la etiqueta de revisión de la versión anterior de istiod:

       kubectl get ns NAMESPACE --show-labels
       

    4. Reinicia los pods para activar la reinyección de forma que los proxies tengan la versión anterior:

       kubectl rollout restart deployment -n NAMESPACE
       

    5. Elimina la nueva implementación de istio-ingressgateway.

       kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_1 -n istio-system --ignore-not-found=true
       

    6. Elimina la nueva revisión de istiod.

       kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-REVISION_1 -n istio-system --ignore-not-found=true
       

    7. Elimina la nueva configuración de IstioOperator.

       kubectl delete IstioOperator installed-state-asm-11910-9-distribute-root -n istio-system
       

       El resultado esperado es similar al siguiente:

       istiooperator.install.istio.io "installed-state-asm-11910-9-distribute-root" deleted

Migrar a la autoridad de certificación de Cloud Service Mesh

Ahora que los proxies sidecar de todas las cargas de trabajo están configurados con la antigua raíz de confianza y la nueva raíz de confianza de la autoridad de certificación de Cloud Service Mesh, los pasos para migrar a la autoridad de certificación de Cloud Service Mesh son similares a los que has seguido para distribuir la raíz de confianza de la autoridad de certificación de Cloud Service Mesh:

Instalar un nuevo plano de control con la autoridad de certificación de Cloud Service Mesh habilitada

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

1. Si has personalizado la instalación anterior, debes especificar los mismos archivos de superposición al ejecutar asmcli install.

2. Ejecuta asmcli install. En el siguiente comando, sustituye 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 \
      --option ca-migration-meshca \
     --revision_name REVISION_2 \
     OVERLAYS
   

   • --fleet_id El ID del proyecto del proyecto host de la flota.
   • --kubeconfig La ruta al archivo kubeconfig Puede especificar una ruta relativa o una ruta completa. La variable de entorno $PWD no funciona aquí.
   • --output_dir Incluye esta opción para especificar un directorio donde asmcli descargue el paquete anthos-service-mesh y extraiga el archivo de instalación, que contiene istioctl, muestras y manifiestos. De lo contrario, asmcli descarga los archivos en un directorio tmp. Puede especificar una ruta relativa o una ruta completa. La variable de entorno $PWD no funciona aquí.
   • --enable_all Permite que la herramienta haga lo siguiente:
     • Concede los permisos de gestión de identidades y accesos necesarios.
     • Habilita las APIs de Google necesarias.
     • Define una etiqueta en el clúster que identifique la malla.
     • Registra el clúster en la flota si aún no lo has hecho.
   • --ca mesh_ca Ahora puedes cambiar a la autoridad de certificación de Cloud Service Mesh, ya que se ha distribuido la raíz de confianza de la autoridad de certificación de Cloud Service Mesh.
   • REVISION_2 Recomendado. Sustituye REVISION_2 por un nombre que describa la instalación, como asm-11910-9-meshca-ca-migration. El nombre debe ser una etiqueta DNS-1035 y debe estar formado por caracteres alfanuméricos en minúscula o -, empezar por un carácter alfabético y terminar por un carácter alfanumérico (como my-name o abc-123).
   • --option ca-migration-migration Cuando [vuelvas a implementar tus cargas de trabajo](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads), esta opción configurará los proxies para que usen la raíz de confianza de la autoridad de certificación de Cloud Service Mesh.

Migrar cargas de trabajo al nuevo plano de control

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

1. Obtiene la etiqueta de revisión que está en istiod y el istio-ingressgateway.

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

   El resultado debería ser similar al siguiente:

   NAME                                                                          READY   STATUS    RESTARTS   AGE   REV
   istio-ingressgateway-asm-11910-9-distribute-root-65d884685d-6hrdk      1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-distribute-root65d884685d-94wgz       1/1     Running   0          67m   asm-11910-9-distribute-root
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-11910-9-meshca-ca-migration
   istio-ingressgateway-asm-11910-9-meshca-ca-migration-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-distribute-root-67998f4b55-lrzpz                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-distribute-root-67998f4b55-r76kr                    1/1     Running   0          68m   asm-11910-9-distribute-root
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration
   istiod-asm-11910-9-meshca-ca-migration-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-11910-9-meshca-ca-migration

   1. En el resultado, en la columna REV, anote el valor de la etiqueta de revisión de la nueva versión. En este ejemplo, el valor es asm-11910-9-meshca-ca-migration.

   2. También debes fijarte en el valor de la etiqueta de revisión de la versión anterior de istiod. Lo necesitas para eliminar la versión anterior de istiod cuando termines de mover las cargas de trabajo a la nueva versión. En el ejemplo, el valor de la etiqueta de revisión de la revisión anterior es asm-11910-9-distribute-root.

2. Añade la nueva etiqueta de revisión a un espacio de nombres. En el siguiente comando, sustituye NAMESPACE por el espacio de nombres que quieras etiquetar.

   kubectl label namespace NAMESPACE istio.io/rev=REVISION_2 --overwrite
   

3. Reinicia los pods para activar la reinyección.

   kubectl rollout restart deployment -n NAMESPACE
   

4. Prueba tu aplicación para verificar que las cargas de trabajo funcionan correctamente. Asegúrate de que la comunicación mTLS funcione entre las cargas de trabajo del espacio de nombres antiguo y las del nuevo.

5. Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reinicia los pods.

6. Sigue los pasos que se indican en Actualizaciones in situ para actualizar las implementaciones de pasarela anteriores que se instalaron en el paso 11 de la sección anterior a la revisión más reciente REVISION_2.

7. Si estás seguro de que tu aplicación funciona correctamente, sigue los pasos para cambiar al nuevo plano de control. Si hay algún problema con tu aplicación, sigue los pasos para revertir la versión.

   Completar la transición

   Si estás seguro de que tu aplicación funciona correctamente, elimina el antiguo plano de control para completar la transición a la nueva versión.

   1. Cambia al directorio en el que se encuentran los archivos del anthos-service-mesh repositorio de GitHub.

   2. Configura el webhook de validación para que use el nuevo plano de control.

      kubectl apply -f asm/istio/istiod-service.yaml
      

   3. Elimina la istio-ingressgatewayimplementación antigua. En el siguiente comando, sustituye OLD_REVISION por la etiqueta de revisión de 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. Elimina la revisión antigua de istiod. En el siguiente comando, sustituye OLD_REVISION por 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 configuración antigua 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

   Restauración

   Si has tenido algún problema al probar tu aplicación con la nueva revisión istiod, sigue estos pasos para volver a la revisión anterior:

   1. Sigue los pasos que se indican en Actualizaciones in situ para cambiar a la revisión anterior REVISION_1 de las implementaciones de la pasarela que se actualizaron en el paso 6 de esta sección.

   2. Cambia el nombre de tu espacio de nombres para habilitar la inyecció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 del espacio de nombres coincide con la etiqueta de revisión de la versión anterior de istiod:

      kubectl get ns NAMESPACE --show-labels
      

   4. Reinicia los pods para activar la reinyección de forma que los proxies tengan la versión anterior:

      kubectl rollout restart deployment -n NAMESPACE
      

   5. Elimina la nueva implementación de istio-ingressgateway.

      kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=REVISION_2 -n istio-system --ignore-not-found=true
      

   6. Quita la nueva versión 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 nueva versión de la configuración de 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

Elimina los secretos de la CA y reinicia el nuevo plano de control

1. Conserva los secretos por si los necesitas:

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

2. Elimina los secretos de la AC del clúster asociado a la AC antigua:

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

3. Reinicia el plano de control recién instalado. De esta forma, se asegura de que la antigua raíz de confianza se elimine de todas las cargas de trabajo que se ejecutan en la malla.

   kubectl rollout restart deployment -n istio-system