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

La migración a la autoridad certificadora de Cloud Service Mesh (CA de Cloud Service 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 De Google Kubernetes Engine (GKE) a Cloud Service Mesh con la autoridad certificadora de Cloud Service Mesh, debías programar debido a que Cloud Service Mesh no pudo 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 solo por completo, se recupera cuando el plano de control y todas las cargas de trabajo en todos los espacios de nombres se volverá a implementar con el certificado de la autoridad certificadora de Cloud Service 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 1.19.10-asm.9 Cloud Service Mesh con la AC de Cloud Service Mesh.
  • Actualiza desde Cloud Service Mesh 1.15 or a 1.16 patch release con la CA de Istio a la Plano de control en el clúster 1.19.10-asm.9 de Cloud Service Mesh con la autoridad certificadora de Cloud Service 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 autoridad certificadora de Cloud Service Mesh.
  • El certificado de mTLS de carga de trabajo emitido por la CA de Istio y por la autoridad certificadora de Cloud Service Mesh.
  • Los dominios de confianza configurados por la CA de Istio y la autoridad certificadora de Cloud Service 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 AC de Cloud Service 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 totalmente funcionales entre cargas de trabajo con con la autoridad certificadora de Cloud Service Mesh y las cargas de trabajo con la CA de Istio

A continuación, se presenta un esquema de la migración a la autoridad certificadora de Cloud Service Mesh:

  1. Distribuye la raíz de confianza de la autoridad certificadora de Cloud Service Mesh.

    1. Instalar una nueva revisión del plano de control que use la AC de Istio con un que distribuirá la raíz de confianza de la autoridad certificadora de Cloud Service 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 autoridad certificadora de Cloud Service Mesh. Ahora que todos los proxies de sidecar están configurados con el raíz de confianza anterior y la raíz de confianza de la autoridad certificadora de Cloud Service Mesh, puedes migrar a la autoridad certificadora 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 AC de Cloud Service 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 autoridad certificadora de Cloud Service Mesh

Antes de que puedas migrar a la autoridad certificadora de Cloud Service Mesh, todos los clústeres de GKE de la malla debe tener Cloud Service Mesh 1.10 o una versión posterior, y todos los clústeres se deben configurar con una opción del plano de control que active la raíz de confianza para que la autoridad certificadora de Cloud Service Mesh distribuidos 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 autoridad certificadora de Cloud Service Mesh, las cargas de trabajo que usen la autoridad certificadora de Cloud Service Mesh podrán autenticarse con cargas de trabajo que usen la AC 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 AC de Cloud Service Mesh.

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

  2. Asegúrate de tener la versión de asmcli que instala Cloud Service Mesh 1.11 o versiones posteriores:

    ./asmcli --version

  3. 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 “citadel” correspondiente a la AC de Istio). No cambies a la autoridad certificadora de Cloud Service 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 R [etiqueta de revisión](/service-mesh/docs/revisions-overview) es un par clave-valor que se configura en el plano de control. La clave de 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-11910-9. Te recomendamos incluir esta opción y reemplazar 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 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 pruebas las cargas de trabajo después de reiniciarlas, ejecutas una herramienta para validar que el proxy de sidecar esté configurado con la raíz antigua y la nueva de confianza para la autoridad certificadora de Cloud Service 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 herramienta de validación:

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

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

  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 asmcli install. En este ejemplo, el valor es asm-11910-9-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. 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.

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

  12. 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 la siguiente comando, reemplaza OLD_REVISION por etiqueta de revisión de la versión anterior del 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 uses depende si migras desde Istio o actualizas de servicio 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-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

Migra a la autoridad certificadora de Cloud Service Mesh

Ahora que los proxies de sidecar para todas las cargas de trabajo están configurados con la configuración raíz de confianza y la nueva raíz de confianza para la autoridad certificadora de Cloud Service Mesh, que migras a la autoridad certificadora de Cloud Service Mesh son similares a las que usaste la raíz de confianza de la autoridad certificadora de Cloud Service Mesh:

Instala un nuevo plano de control con la autoridad certificadora de Cloud Service Mesh habilitada

Usa asmcli install 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 asmcli install.

  2. 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
      • --fleet_id El ID del proyecto host de la flota.
      • --kubeconfig es la ruta a 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 mesh_ca Ahora puedes cambiar a la autoridad certificadora de Cloud Service Mesh raíz de confianza.
      • REVISION_2 recomendada. Reemplaza 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 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).
      • --option ca-migration-migration Cuando [volver a implementar tus cargas de trabajo](/service-mesh/docs/unified-install/install-anthos-service-mesh#deploy_and_redeploy_workloads) Esta opción configura los proxies para que usen la raíz de confianza de la autoridad certificadora de Cloud Service 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-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, anota el valor de la etiqueta de revisión de la versión nueva. En este ejemplo, el valor es asm-11910-9-meshca-ca-migration.

    2. Observa también el valor en la etiqueta de revisión de la versión anterior de istiod. Necesitas 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-11910-9-distribute-root.

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

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

  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