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.10.6-asm.2 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.10.6-asm.2 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

En esta guía, suponemos que ya tienes lo siguiente:

• Un proyecto de Google Cloud
• Una cuenta de facturación de Cloud
• Las herramientas necesarias para ejecutar la secuencia de comandos install_asm.
• Para una malla de varios clústeres con la CA de Istio, se debe establecer el mismo certificado raíz en cada clúster.

Herramientas requeridas

Durante la migración, debes ejecutar una secuencia de comandos 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 secuencia de comandos tiene las siguientes dependencias:

• awk
• grep
• istioctl Cuando ejecutas la secuencia de comandos 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.

A continuación, se presenta un esquema de la migración a la CA de Mesh:

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

   1. Instala una nueva revisión del plano de control 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.

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

1. Sigue los pasos en Instala Anthos Service Mesh en GKE a fin de prepararte para usar una secuencia de comandos proporcionada por Google, install_asm, para instalar la revisión nueva del plano de control.

2. Asegúrate de tener la versión de install_asm que instala Anthos Service Mesh 1.10 o versiones posteriores:

   ./install_asm --version
   

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

   • PROJECT_ID: Obligatorio. El ID del proyecto en el que se creó el clúster.

   • CLUSTER_NAME: Obligatorio. Es el nombre del clúster.

   • CLUSTER_LOCATION: Obligatorio. Es la zona o región en la que se encuentra el clúster.

   • 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 secuencia de comandos establece el valor de la etiqueta de revisión según la versión de Anthos Service Mesh, por ejemplo: asm-1106-2. Te recomendamos incluir esta opción y reemplazar REVISION_1 por un nombre que describa la instalación, como asm-1106-2-distribute-root. El nombre debe ser una etiqueta DNS-1035, contener caracteres alfanuméricos en minúscula o -, comenzar con una letra y terminar con un carácter alfanumérico (como my-name' o abc-123). La regex que se usa para la validación es '[a-z]([-a-z0-9]*[a-z0-9])?').

   • DIR_PATH : Obligatorio. Una ruta de acceso relativa a un directorio en el que la secuencia de comandos descarga el paquete anthos-service-mesh y el archivo de instalación de Anthos Service Mesh, que contiene istioctl, muestras y manifiestos.

   • OVERLAYS: Opcional Si deseas habilitar funciones opcionales, incluye --custom_overlay con el nombre del archivo de superposición de cada función. Si no habilitarás las funciones opcionales, borra esta línea y la barra inversa de la línea anterior.

     ./install_asm \
       --project_id  PROJECT_ID \
       --cluster_name CLUSTER_NAME \
       --cluster_location CLUSTER_LOCATION \
       --mode install \
       --ca citadel \
       --enable_all \
       --option ca-migration-citadel \
       --revision_name REVISION_1  \
       --output_dir DIR_PATH \
       OVERLAYS
     

   Se requieren los siguientes argumentos de línea de comandos:

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

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

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=asm-1106-2-distribute-root y reiniciar las cargas de trabajo. Cuando pruebes tus cargas de trabajo después de reiniciarlas, debes ejecutar una secuencia de comandos para validar que el proxy de sidecar esté configurado con la raíz de confianza anterior y nueva para la CA de Mesh.

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

2. Descarga la secuencia de comandos de validación:

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

3. Configura el bit ejecutable en la secuencia de comandos:

   chmod +x migrate_ca
   

4. La secuencia de comandos migrate_ca llama a istioctl, que depende de la versión. La secuencia de comandos install_asm 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 secuencia de comandos.

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

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

   1. 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 install_asm. En este ejemplo, el valor es asm-1106-2-distribute-root.

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

6. Cambia istio-ingressgateway a la revisión nueva. En el siguiente comando, asegúrate de que REVISION_1 coincida con el valor de la etiqueta de revisión de la revisión nueva.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_1"}]'

   Resultado esperado:

   service/istio-ingressgateway patched

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

8. Reinicia los Pods para activar la reinserción:

   kubectl rollout restart deployment -n NAMESPACE
   

9. Verifica que tus pods estén configurados para apuntar a la nueva versión de istiod.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_1
   

10. Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.

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

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

13. 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. Vuelve a la versión anterior de la istio-ingressgatewqy. En el siguiente comando, reemplaza OLD_REVISION por la revisión anterior.

       kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
       

    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-1106-2-distribute-root -n istio-system
       

       El resultado esperado es similar al siguiente:

       istiooperator.install.istio.io "installed-state-asm-1106-2-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 install_asm para instalar una revisión nueva del plano de control que tenga habilitada la CA de Mesh.

1. Si personalizaste la instalación anterior, debes especificar los mismos archivos de superposición cuando ejecutes install_asm.

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

   • PROJECT_ID: Obligatorio. El ID del proyecto en el que se creó el clúster.

   • CLUSTER_NAME: Obligatorio. Es el nombre del clúster.

   • CLUSTER_LOCATION: Obligatorio. Es la zona o región en la que se encuentra el clúster.

   • REVISION_2: Recomendado Reemplaza REVISION_2 por un nombre que describa la instalación, como asm-1106-2-meshca-ca-migration. El nombre debe ser una etiqueta DNS-1035, contener caracteres alfanuméricos en minúscula o -, comenzar con una letra y terminar con un carácter alfanumérico (como my-name' o abc-123). La regex que se usa para la validación es '[a-z]([-a-z0-9]*[a-z0-9])?').

   • DIR_PATH : Obligatorio. Una ruta de acceso relativa a un directorio en el que la secuencia de comandos descarga el paquete anthos-service-mesh y el archivo de instalación de Anthos Service Mesh, que contiene istioctl, muestras y manifiestos.

   • OVERLAYS: Opcional Si deseas habilitar funciones opcionales, incluye --custom_overlay con el nombre del archivo de superposición de cada función. Si no habilitarás las funciones opcionales, borra esta línea y la barra inversa de la línea anterior.

   ./install_asm \
     --project_id  PROJECT_ID \
     --cluster_name CLUSTER_NAME \
     --cluster_location CLUSTER_LOCATION \
     --mode install \
     --ca mesh_ca \
     --enable_all \
     --option ca-migration-meshca \
     --revision_name REVISION_2 \
     --output_dir DIR_PATH \
     OVERLAYS
   

   Se requieren los siguientes argumentos de línea de comandos:

   • --ca mesh_ca: Ahora puedes cambiar a la CA de Mesh, ya que se distribuyó la raíz de confianza de la CA de Mesh.

   • --option ca-migration-migration: Cuando vuelves a implementar tus cargas de trabajo, esta opción configura los proxies para usar la raíz de confianza de la CA de Mesh.

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.

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

   1. 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-1106-2-meshca-ca-migration.

   2. 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-1106-2-distribute-root.

2. Cambia istio-ingressgateway a la revisión nueva. En el siguiente comando, cambia REVISION_2 por el valor que coincide con la etiqueta de revisión de la versión nueva.

   kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "REVISION_2"}]'

   Resultado esperado:

   service/istio-ingressgateway patched

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

4. Reinicia los Pods para activar la reinserción:

   kubectl rollout restart deployment -n NAMESPACE
   

5. Verifica que tus pods estén configurados para apuntar a la nueva versión de istiod.

   kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION_2
   

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

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

8. 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. Vuelve a la istio-ingressgatewqy anterior. En el siguiente comando, reemplaza OLD_REVISION por la revisión anterior.

      kubectl patch service -n istio-system istio-ingressgateway --type='json' -p='[{"op": "replace", "path": "/spec/selector/service.istio.io~1canonical-revision", "value": "OLD_REVISION"}]'
      

   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

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

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
   

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