Migrar de Istio a Anthos Service Mesh

Esta página forma parte de una guía de varias páginas en la que se explica cómo migrar de Istio a la versión 1.11.8 de Anthos Service Mesh en un clúster de GKE para una malla que contiene varios clústeres que están en proyectos diferentes de Google Cloud. Si tienes una versión anterior de Istio, debes realizar una actualización antes de migrar a Anthos Service Mesh. Si necesitas realizar una actualización, ve a la página Actualiza Istio en la versión de Istio aplicable. Ten en cuenta que no se prueba ni se recomienda de forma oficial la actualización de Istio en más de una versión secundaria (por ejemplo, de 1.6.x a 1.8.x) en un paso.

Para las migraciones en una malla de un solo clúster o una malla que contiene varios clústeres en el mismo proyecto de Google Cloud, consulta Instalación, migración y actualización para GKE.

Antes de comenzar

Antes de instalar Anthos Service Mesh, asegúrate de haber hecho lo siguiente:

Prepárate para la migración

Asegúrate de revisar la sección Prepara la migración desde Istio.

Para migrar desde Istio, sigue el proceso de actualización de revision (denominado actualizaciones “canary” en la documentación de Istio). Con una actualización basada en una revisión, instalas una revisión nueva del plano de control junto con el plano de control existente. Cuando ejecutas istioctl install, se incluye una opción para configurar una etiqueta revision que identifica el nuevo plano de control.

Luego, migras a la versión nueva mediante la configuración de la misma etiqueta revision en tus cargas de trabajo y la ejecución de un reinicio progresivo para volver a incorporar los proxies con la nueva versión y configuración de Anthos Service Mesh. Con este enfoque, puedes supervisar el efecto de la actualización en un porcentaje pequeño de tus cargas de trabajo. Después de probar la aplicación, puedes migrar todo el tráfico a la revisión nueva. Este enfoque es mucho más seguro que realizar una actualización in situ en la que un plano de control nuevo reemplaza inmediatamente a la versión anterior.

Configura credenciales y permisos

  1. Inicializa tu proyecto a fin de prepararlo para la instalación. Entre otras cosas, con este comando puedes crear una cuenta de servicio para permitir que los componentes del plano de datos, como el proxy de sidecar, accedan a los datos y recursos de tu proyecto de forma segura:

    curl --request POST \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --data '' \
  "https://meshconfig.googleapis.com/v1alpha1/projects/${PROJECT_ID}:initialize"

    El comando responde con llaves vacías: {}.

  2. Obtén credenciales de autenticación para interactuar con el clúster. En este comando, también se establece el contexto actual de kubectl en el clúster.

    gcloud container clusters get-credentials ${CLUSTER_NAME} \
    --project=${PROJECT_ID}

  3. Otorga permisos de administrador de clúster al usuario actual. Estos permisos son obligatorios a fin de crear las reglas de control de acceso basado en funciones (RBAC) necesarias para Anthos Service Mesh:

    kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole=cluster-admin \
  --user="$(gcloud config get-value core/account)"

Si ves el error "cluster-admin-binding" already exists, puedes ignorarlo sin problemas y continuar con la vinculación del administrador del clúster existente.

Descarga el archivo de instalación

Linux

  1. Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-linux-amd64.tar.gz

  2. Descarga el archivo de firma y usa openssl para verificar la firma:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-linux-amd64.tar.gz.1.sig
openssl dgst -verify /dev/stdin -signature istio-1.11.8-asm.4-linux-amd64.tar.gz.1.sig istio-1.11.8-asm.4-linux-amd64.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    El resultado esperado es: Verified OK.

  3. Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

     tar xzf istio-1.11.8-asm.4-linux-amd64.tar.gz

    El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.11.8-asm.4 que contiene lo siguiente:

    • Hay aplicaciones de muestra en el directorio samples.
    • La herramienta de línea de comandos de istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
    • Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

  4. Asegúrate de estar en el directorio raíz de la instalación de Anthos Service Mesh.

    cd istio-1.11.8-asm.4

macOS

  1. Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-osx.tar.gz

  2. Descarga el archivo de firma y usa openssl para verificar la firma:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-osx.tar.gz.1.sig
openssl dgst -sha256 -verify /dev/stdin -signature istio-1.11.8-asm.4-osx.tar.gz.1.sig istio-1.11.8-asm.4-osx.tar.gz <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    El resultado esperado es: Verified OK.

  3. Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

    tar xzf istio-1.11.8-asm.4-osx.tar.gz

    El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.11.8-asm.4 que contiene lo siguiente:

    • Hay aplicaciones de muestra en el directorio samples.
    • La herramienta de línea de comandos de istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
    • Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

  4. Asegúrate de estar en el directorio raíz de la instalación de Anthos Service Mesh.

    cd istio-1.11.8-asm.4

Windows

  1. Descarga el archivo de instalación de Anthos Service Mesh en el directorio de trabajo actual:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-win.zip

  2. Descarga el archivo de firma y usa openssl para verificar la firma:

    curl -LO https://storage.googleapis.com/gke-release/asm/istio-1.11.8-asm.4-win.zip.1.sig
openssl dgst -verify - -signature istio-1.11.8-asm.4-win.zip.1.sig istio-1.11.8-asm.4-win.zip <<'EOF'
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEWZrGCUaJJr1H8a36sG4UUoXvlXvZ
wQfk16sxprI2gOJ2vFFggdq3ixF2h4qNBt0kI7ciDhgpwS8t+/960IsIgw==
-----END PUBLIC KEY-----
EOF

    El resultado esperado es: Verified OK.

  3. Extrae el contenido del archivo a cualquier ubicación en tu sistema de archivos. Por ejemplo, para extraer el contenido en el directorio de trabajo actual, ingresa este comando:

    tar xzf istio-1.11.8-asm.4-win.zip

    El comando crea un directorio de instalación en tu directorio de trabajo actual llamado istio-1.11.8-asm.4 que contiene lo siguiente:

    • Hay aplicaciones de muestra en el directorio samples.
    • La herramienta de línea de comandos de istioctl que usas para instalar Anthos Service Mesh se encuentra en el directorio bin.
    • Los perfiles de configuración de Anthos Service Mesh se encuentran en el directorio manifests/profiles.

  4. Asegúrate de estar en el directorio raíz de la instalación de Anthos Service Mesh.

    cd istio-1.11.8-asm.4

Prepara los archivos de configuración de recursos

Cuando ejecutes el comando istioctl install, debes especificar -f istio-operator.yaml en la línea de comandos. En este archivo, encontrarás la información que requiere Anthos Service Mesh sobre el proyecto y el clúster. Debes descargar un paquete que contenga istio-operator.yaml y otros archivos de configuración de recursos a fin de establecer la información del proyecto y del clúster.

Para preparar los archivos de configuración de recursos, sigue estos pasos:

CA de Mesh

  1. Crea un directorio nuevo para los archivos de configuración de recursos del paquete de Anthos Service Mesh. Recomendamos que uses el nombre del clúster como el nombre del directorio.

  2. Cambia al directorio en el que deseas descargar el paquete de Anthos Service Mesh.

  3. Verifica la versión de kpt. Asegúrate de ejecutar una versión anterior a 1.x de kpt:

    kpt version

    El resultado debería ser similar al ejemplo siguiente:

    0.39.2

    Si tienes la versión 1.x de kpt o una posterior, consulta Configura tu entorno para descargar la versión requerida para tu sistema operativo.

  4. Descarga el paquete :

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm

  5. Configura el ID del proyecto en el que se creó el clúster:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Configura el número de proyecto para el proyecto host de la flota:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Configura el nombre del clúster:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Establece la zona o región predeterminada:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Configura la etiqueta de la versión de Anthos Service Mesh que instalarás:

    kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4

  10. Configura la revisión en los archivos de configuración de recursos del paquete de Anthos Service Mesh:

    kpt cfg set asm anthos.servicemesh.rev asm-1118-4

    Cuando instales Anthos Service Mesh, configura una etiqueta de revisión en istiod. Debes configurar la misma revisión en el webhook de validación.

  11. Debido a que los clústeres en tu configuración de varios clústeres están en proyectos diferentes, debes configurar los alias de dominio de confianza para los otros proyectos que formarán la malla de servicios de varios clústeres o varios proyectos.

    1. Obtén el ID del proyecto de todos los clústeres que se incluirán en la malla de varios clústeres o varios proyectos.

    2. Para el ID del proyecto de cada clúster, configura los alias del dominio de confianza. Por ejemplo, si tienes clústeres en 3 proyectos, ejecuta el siguiente comando y reemplaza PROJECT_ID_1, PROJECT_ID_2 y PROJECT_ID_3 por el ID del proyecto de cada clúster.

      kpt cfg set asm anthos.servicemesh.trustDomainAliases PROJECT_ID_1.svc.id.goog PROJECT_ID_2.svc.id.goog PROJECT_ID_3.svc.id.goog

      Puedes usar el mismo comando para configurar los clústeres en los otros proyectos.

      Los alias del dominio de confianza permiten que la CA de Mesh autentique las cargas de trabajo en los clústeres en otros proyectos. Además de configurar los alias del dominio de confianza, después de instalar Anthos Service Mesh, debes habilitar el balanceo de cargas entre clústeres.

  12. Muestra los valores de los métodos set de kpt:

    kpt cfg list-setters asm

    El resultado del comando es similar al siguiente: 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.11.8-asm.4
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.11.8-asm.4
anthos.servicemesh.trustDomainAliases                [example-project-12345.svc.id.goog,example-project-23456.svc.id.goog,example-project-98765.svc.id.goog]
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Verifica que los valores de los siguientes métodos set sean correctos:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • anthos.servicemesh.trustDomainAliases
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Puedes ignorar los valores de los otros métodos set.

CA de Istio

  1. Crea un directorio nuevo para los archivos de configuración de recursos del paquete de Anthos Service Mesh. Recomendamos que uses el nombre del clúster como el nombre del directorio.

  2. Cambia al directorio en el que deseas descargar el paquete de Anthos Service Mesh.

  3. Verifica la versión de kpt. Asegúrate de ejecutar una versión anterior a 1.x de kpt:

    kpt version

    El resultado debería ser similar al ejemplo siguiente:

    0.39.2

    Si tienes la versión 1.x de kpt o una superior, descarga la versión requerida:

    curl -L https://github.com/GoogleContainerTools/kpt/releases/download/v0.39.2/kpt_linux_amd64 > kpt_0_39_2
chmod +x kpt_0_39_2
alias kpt="$(readlink -f kpt_0_39_2)"

  4. Descarga el paquete :

    kpt pkg get \
https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages.git/asm@release-1.11 asm

  5. Configura el ID del proyecto en el que se creó el clúster:

    kpt cfg set asm gcloud.core.project ${PROJECT_ID}

  6. Configura el número de proyecto para el proyecto host de la flota:

    kpt cfg set asm gcloud.project.environProjectNumber ${FLEET_PROJECT_NUMBER}

  7. Configura el nombre del clúster:

    kpt cfg set asm gcloud.container.cluster ${CLUSTER_NAME}

  8. Establece la zona o región predeterminada:

    kpt cfg set asm gcloud.compute.location ${CLUSTER_LOCATION}

  9. Configura la etiqueta de la versión de Anthos Service Mesh que instalarás:

    kpt cfg set asm anthos.servicemesh.tag 1.11.8-asm.4

  10. Configura la revisión en los archivos de configuración de recursos del paquete de Anthos Service Mesh:

    kpt cfg set asm anthos.servicemesh.rev asm-1118-4

  11. Muestra los valores de los métodos set de kpt:

    kpt cfg list-setters asm

    El resultado del comando es similar al siguiente: 

                              NAME                                                       VALUE
anthos.servicemesh.canonicalServiceHub               gke.gcr.io/asm/canonical-service-controller:1.11.8-asm.4
anthos.servicemesh.controlplane.monitoring.enabled   true
anthos.servicemesh.hub                               gke.gcr.io/asm
anthos.servicemesh.hubMembershipID                   MEMBERSHIP_ID
anthos.servicemesh.tag                               1.11.8-asm.4
anthos.servicemesh.trustDomainAliases
base-dir                                             base
gcloud.compute.location                              us-central
gcloud.compute.network                               default
gcloud.compute.subnetwork                            default
gcloud.container.cluster                             example-cluster-1
gcloud.container.cluster.clusterSecondaryRange
gcloud.container.cluster.releaseChannel              REGULAR
gcloud.container.cluster.servicesSecondaryRange
gcloud.container.nodepool.max-nodes                  4
gcloud.core.project                                  example-project-12345
gcloud.project.environProjectID                      FLEET_PROJECT_ID
gcloud.project.environProjectNumber                  1234567890123
gcloud.project.projectNumber                         9876543210987

    Verifica que los valores de los siguientes métodos set sean correctos:

    • anthos.servicemesh.rev
    • anthos.servicemesh.tag
    • gcloud.compute.location
    • gcloud.container.cluster
    • gcloud.core.project
    • gcloud.project.environProjectNumber

    Puedes ignorar los valores de los otros métodos set.

Migra Anthos Service Mesh

CA de Mesh

  1. Verifica que el contexto kubeconfig actual apunte al clúster en el que deseas instalar Anthos Service Mesh:

    kubectl config current-context

    El resultado estará en el siguiente formato:

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    El contexto kubeconfig y los valores de los métodos set kpt deben coincidir. Si es necesario, ejecuta el comando gcloud container clusters get-credentials para configurar el contexto kubeconfig actual.

  2. Si es necesario, cambia al directorio istio-1.11.8-asm.4. El cliente istioctl depende de la versión. Asegúrate de usar la versión en el directorio istio-1.11.8-asm.4/bin.

  3. Ejecuta el siguiente comando para implementar el plano de control nuevo con el perfil asm-gcp-multiproject. Si deseas habilitar una función compatible opcional, incluye -f y el nombre del archivo YAML en la siguiente línea de comandos. Consulta Habilita funciones opcionales para obtener más información.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  --revision=asm-1118-4

    El argumento --revision agrega una etiqueta de revisión con el formato istio.io/rev=asm-1118-4 a istiod. El webhook automático de inyector de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. A fin de habilitar la inserción automática del sidecar para un espacio de nombres, debes etiquetarlo con una revisión que coincida con una implementación istiod.

    Los siguientes archivos se anulan la configuración del archivo istio-operator.yaml:

    • El archivo multiproject.yaml establece el perfil asm-gcp-multiproject.

    • El archivo multicluster.yaml configura los ajustes que necesita Anthos Service Mesh para una configuración de varios clústeres.

  4. Verifica que los Pods del plano de control en istio-system estén activos:

    kubectl get pods -n istio-system

    Salida de ejemplo:

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-1118-4-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Tienes dos Deployments y Services del plano de control y servicios que se ejecutan en paralelo.

  5. Implementa el controlador de servicios canónicos en tu clúster:

    kubectl apply -f asm/canonical-service/controller.yaml

    El controlador del servicio canónico agrupa las cargas de trabajo que pertenecen al mismo servicio lógico. Para obtener más información sobre los servicios canónicos, consulta la descripción general del servicio canónico.

CA de Istio

  1. Verifica que el contexto kubeconfig actual apunte al clúster en el que deseas instalar Anthos Service Mesh:

    kubectl config current-context

    El resultado estará en el siguiente formato:

    gke_PROJECT_ID_CLUSTER_LOCATION_CLUSTER_NAME

    El contexto kubeconfig y los valores de los métodos set kpt deben coincidir. Si es necesario, ejecuta el comando gcloud container clusters get-credentials para configurar el contexto kubeconfig actual.

  2. Si es necesario, cambia al directorio istio-1.11.8-asm.4. El cliente istioctl depende de la versión. Asegúrate de usar la versión en el directorio istio-1.11.8-asm.4/bin.

  3. Ejecuta el siguiente comando para implementar el plano de control nuevo con el perfil asm-gcp-multiproject. Si deseas habilitar una función compatible opcional, incluye -f y el nombre del archivo YAML en la siguiente línea de comandos. Consulta Habilita funciones opcionales para obtener más información.

    bin/istioctl install \
  -f asm/istio/istio-operator.yaml \
  -f asm/istio/options/citadel-ca.yaml \
  -f asm/istio/options/multiproject.yaml \
  -f asm/istio/options/multicluster.yaml \
  --revision=asm-1118-4

    El argumento --revision agrega una etiqueta de revisión con el formato istio.io/rev=asm-1118-4 a istiod. El webhook automático de inyector de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. A fin de habilitar la inserción automática del sidecar para un espacio de nombres, debes etiquetarlo con una revisión que coincida con una implementación istiod.

    Los siguientes archivos se anulan la configuración del archivo istio-operator.yaml:

    • El citadel-ca.yaml configura la CA de Istio como la autoridad certificadora.

    • El archivo multiproject.yaml establece el perfil asm-gcp-multiproject.

    • El archivo multicluster.yaml configura los ajustes que necesita Anthos Service Mesh para una configuración de varios clústeres.

  4. Verifica que los Pods del plano de control en istio-system estén activos:

    kubectl get pods -n istio-system

    Salida de ejemplo:

    NAME                                        READY   STATUS    RESTARTS   AGE
istio-ingressgateway-c56675fcd-86zdn        1/1     Running   0          2m9s
istio-ingressgateway-c56675fcd-vn4nv        1/1     Running   0          2m21s
istiod-asm-1118-4-6d5cfd4b89-xztlr           1/1     Running   0          3m44s
istiod-fb7f746f4-wcntn                      1/1     Running   0          50m

    Tienes dos Deployments y Services del plano de control y servicios que se ejecutan en paralelo.

  5. Implementa el controlador de servicios canónicos en tu clúster:

    kubectl apply -f asm/canonical-service/controller.yaml

    El controlador del servicio canónico agrupa las cargas de trabajo que pertenecen al mismo servicio lógico. Para obtener más información sobre los servicios canónicos, consulta la descripción general del servicio canónico.

Implementa y vuelve a implementar las cargas de trabajo

La instalación no estará completa hasta que habilites la inserción automática de proxy de sidecar (inserción automática). Las migraciones de OSS Istio y las actualizaciones siguen el proceso de actualización basado en la revisión (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización basada en revisiones, la versión nueva del plano de control se instala junto con el plano de control existente. Luego, transfiere algunas de tus cargas de trabajo a la versión nueva, lo que te permite supervisar el efecto de la actualización con un pequeño porcentaje de las cargas de trabajo antes de migrar todo el tráfico a la versión nueva.

Cuando ejecutaste istioctl install, estableciste una etiqueta de revisión en el formato istio.io/rev=asm-1118-4 en istiod. Para habilitar la inserción automática, agrega una etiqueta de revisión coincidente a tus espacios de nombres. El webhook de inyector de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. Después de agregar la etiqueta, reinicia los Pods en el espacio de nombres para que se inserten los sidecars.

  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 del comando es similar al siguiente: 

    NAME                                             READY   STATUS    RESTARTS   AGE   REV
istio-ingressgateway-65d884685d-6hrdk            1/1     Running   0          67m
istio-ingressgateway-65d884685d-94wgz            1/1     Running   0          67m
istio-ingressgateway-asm-182-2-8b5fc8767-gk6hb   1/1     Running   0          5s    asm-1118-4
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2   1/1     Running   0          20s   asm-1118-4
istiod-asm-176-1-67998f4b55-lrzpz                1/1     Running   0          68m   asm-1107-1
istiod-asm-176-1-67998f4b55-r76kr                1/1     Running   0          68m   asm-1107-1
istiod-asm-182-2-5cd96f88f6-n7tj9                1/1     Running   0          27s   asm-1118-4
istiod-asm-182-2-5cd96f88f6-wm68b                1/1     Running   0          27s   asm-1118-4

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

    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 resultado de ejemplo, el valor de la etiqueta de revisión para la versión anterior es asm-1107-1.

  2. Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, cambia REVISION por el valor que coincide con la nueva revisión de istiod.

    kubectl label namespace NAMESPACE istio.io/rev=REVISION 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.

  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.

  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. 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 versió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-ingressgateway. 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. Asegúrate de que el valor de REVISION en el siguiente comando sea correcto.

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

    6. Quita la versión nueva de istiod. Asegúrate de que el valor de REVISION en el siguiente comando sea correcto.

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

    7. Quita la versión nueva de la configuración IstioOperator.

      kubectl delete IstioOperator installed-state-REVISION -n istio-system

      El resultado esperado es similar al siguiente:

      istiooperator.install.istio.io "installed-state-REVISION" deleted

    8. Si no incluiste la marca --disable_canonical_service, la secuencia de comandos habilitó el controlador del servicio canónico. Recomendamos que lo habilites, pero si necesitas inhabilitarlo, consulta Habilita o inhabilita el controlador de servicio canónico.

¿Qué sigue?