Actualizar Cloud Service Mesh

En esta página se explica cómo:

  • Ejecuta asmcli para actualizar de Cloud Service Mesh a Cloud Service Mesh 1.19.10.

  • También puedes desplegar una pasarela de entrada.

  • Haz una actualización canary para migrar tus cargas de trabajo al nuevo plano de control.

La versión de Cloud Service Mesh desde la que puedes actualizar varía en función de la plataforma.

GKE

Puedes actualizar directamente a Cloud Service Mesh 1.19.10-asm.9 en Google Kubernetes Engine desde las siguientes versiones:

1.17+

On‑premise

Puedes actualizar directamente a Cloud Service Mesh 1.19.10-asm.9 en Google Distributed Cloud y Google Distributed Cloud desde las siguientes versiones:

1.17+

GKE en AWS

Puedes actualizar directamente a Cloud Service Mesh 1.19.10-asm.9 en GKE en AWS desde las siguientes versiones:

1.17+

GKE en Azure

GKE en Azure solo admite Cloud Service Mesh 1.16. No se admiten actualizaciones desde versiones anteriores de Cloud Service Mesh.

Amazon EKS

Si tienes Cloud Service Mesh 1.7 instalado en EKS, tendrás que instalar Cloud Service Mesh 1.19 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh1.19 .

Microsoft AKS

Si tienes Cloud Service Mesh 1.7 instalado en AKS, tendrás que instalar Cloud Service Mesh 1.19 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh1.19 .

Antes de empezar

Antes de empezar, asegúrate de que:

Personalizaciones del plano de control

Si has personalizado la instalación anterior, necesitarás las mismas personalizaciones al actualizar a una nueva versión de Cloud Service Mesh o al migrar desde Istio. Si has personalizado la instalación añadiendo la marca --set values a istioctl install, debes añadir esos ajustes a un archivo YAML IstioOperator, denominado archivo de superposición. Para especificar el archivo de superposición, usa la opción --custom_overlay con el nombre de archivo cuando ejecutes la secuencia de comandos. La secuencia de comandos transfiere el archivo de superposición a istioctl install.

Autoridad de certificación

Si se cambia la autoridad de certificación durante una actualización, se produce un tiempo de inactividad. Durante la actualización, el tráfico de mTLS se interrumpe hasta que todas las cargas de trabajo cambien al nuevo plano de control con la nueva CA.

Actualizar Anthos Service Mesh

A continuación se explica cómo actualizar Cloud Service Mesh:

  1. Si vas a actualizar una malla multiclúster en GKE que usa la autoridad de certificación de Cloud Service Mesh, ejecuta asmcli create-mesh para configurar la malla multiclúster de forma que confíe en la identidad de carga de trabajo de la flota para que el balanceo de carga entre clústeres no se interrumpa durante la actualización.

  2. Ejecuta asmcli install para instalar Cloud Service Mesh en un solo clúster. En las secciones siguientes se muestran ejemplos de líneas de comandos. Los ejemplos contienen argumentos obligatorios y argumentos opcionales que pueden resultarte útiles. Te recomendamos que siempre especifiques el argumento output_dir para que puedas localizar fácilmente las pasarelas de ejemplo y las herramientas, como istioctl. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos.

  3. También puedes instalar o actualizar una pasarela de entrada. De forma predeterminada, asmcli no instala istio-ingressgateway. Te recomendamos que implementes y gestiones el plano de control y las pasarelas por separado. Si necesitas que se instale istio-ingressgateway de forma predeterminada con el plano de control en clústeres, incluye el argumento --option legacy-default-ingressgateway.

  4. Para completar la configuración de Cloud Service Mesh, debes habilitar la inyección automática de sidecars y desplegar o volver a desplegar cargas de trabajo.

Configurar la malla de varios clústeres para que confíe en la identidad de cargas de trabajo de la flota

Si vas a actualizar una malla multiclúster en GKE que usa la autoridad de certificación de Cloud Service Mesh como autoridad de certificación, debes ejecutar asmcli create-mesh antes de actualizar cada clúster. Este comando configura la autoridad de certificación de Cloud Service Mesh para que use el grupo de identidades de carga de trabajo de la flota, FLEET_PROJECT_ID.svc.id.goog, como dominio de confianza después de la actualización. El comando asmcli create-mesh:

  • Registra todos los clústeres en la misma flota.
  • Configura la malla para que confíe en la identidad de carga de trabajo de la flota.
  • Crea secretos remotos.

Puedes especificar el URI de cada clúster o la ruta del archivo kubeconfig.

URI del clúster

En el siguiente comando, sustituye FLEET_PROJECT_ID por el ID del proyecto host de la flota y el URI del clúster por el nombre, la zona o la región y el ID del proyecto de cada clúster.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PROJECT_ID_1/CLUSTER_LOCATION_1/CLUSTER_NAME_1 \
    PROJECT_ID_2/CLUSTER_LOCATION_2/CLUSTER_NAME_2 # \
    # Add a line for each cluster in the mesh

Archivo kubeconfig

En el siguiente comando, sustituye FLEET_PROJECT_ID por el ID del proyecto host de la flota y PATH_TO_KUBECONFIG por la ruta de cada archivo kubeconfig.

./asmcli create-mesh \
    FLEET_PROJECT_ID \
    PATH_TO_KUBECONFIG_1 \
    PATH_TO_KUBECONFIG_2 # \
    # Add a line for each cluster in the mesh

Actualizar con las funciones predeterminadas y la Mesh CA

En esta sección se muestra cómo ejecutar asmcli para actualizar Cloud Service Mesh con las funciones admitidas predeterminadas de tu plataforma y habilitar la autoridad de certificación de Cloud Service Mesh como autoridad de certificación.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y la autoridad de certificación de Cloud Service Mesh. Introduce tus valores en los marcadores de posición proporcionados.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca
  • --project_id, --cluster_name y --cluster_location: especifica el ID del proyecto en el que se encuentra el clúster, el nombre del clúster y la zona o la región del clúster.
  • --fleet_id El ID del proyecto del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster al registrarlo.
  • --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 secuencia de comandos:
    • 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 Usa la autoridad de certificación de Cloud Service Mesh como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura la autoridad de certificación de Cloud Service Mesh para usar Workload Identity de la flota.

Otros clústeres de GKE Enterprise

Ejecuta los siguientes comandos en otros clústeres de GKE Enterprise para actualizar el plano de control con las funciones predeterminadas y la autoridad de certificación de Cloud Service Mesh. Introduce los valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa la autoridad de certificación de Cloud Service Mesh como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura la autoridad de certificación de Cloud Service Mesh para usar la identidad de carga de trabajo de la flota.

Mejorar las funciones predeterminadas con el Servicio de Autoridades de Certificación

En esta sección se muestra cómo ejecutar asmcli para actualizar Cloud Service Mesh con las funciones admitidas predeterminadas de tu plataforma y habilitar Certificate Authority Service.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y el servicio de autoridad de certificación. Introduce tus valores en los marcadores de posición proporcionados.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
  • --project_id, --cluster_name y --cluster_location: especifica el ID del proyecto en el que se encuentra el clúster, el nombre del clúster y la zona o la región del clúster.
  • --fleet_id El ID del proyecto del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster al registrarlo.
  • --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 secuencia de comandos:
    • 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 gcp_cas Usa el Servicio de Autoridades de Certificación como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura el Servicio de Autoridades de Certificación para usar la identidad de carga de trabajo de la flota.
  • --ca_pool El identificador completo del servicio de autoridad de certificación CA Pool.

On‑premise

Ejecuta los siguientes comandos en Google Distributed Cloud o Google Distributed Cloud para actualizar el plano de control con las funciones predeterminadas y el servicio de autoridad de certificación. Introduce tus valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
 --kubeconfig KUBECONFIG_FILE \
 --fleet_id FLEET_PROJECT_ID \
 --output_dir DIR_PATH \
 --enable_all \
 --ca gcp_cas \
 --platform multicloud \
 --ca_pool projects/PROJECT_NAME/locations/ca_region/caPools/CA_POOL
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 gcp_cas Usa el Servicio de Autoridades de Certificación como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura el Servicio de Autoridades de Certificación para usar la identidad de carga de trabajo de la flota.
    • --ca_pool El identificador completo del servicio de autoridad de certificación CA Pool.

Actualizar las funciones predeterminadas con la CA de Istio

En esta sección se muestra cómo ejecutar asmcli para actualizar Cloud Service Mesh con las funciones compatibles predeterminadas de tu plataforma y habilitar Istio CA.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y la CA de Istio. Introduce tus valores en los marcadores de posición proporcionados.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca citadel
  • --project_id, --cluster_name y --cluster_location: especifica el ID del proyecto en el que se encuentra el clúster, el nombre del clúster y la zona o la región del clúster.
  • --fleet_id El ID del proyecto del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster al registrarlo.
  • --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 secuencia de comandos:
    • 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 Usa la AC de Istio. Si cambia las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad.

On‑premise

Ejecuta los siguientes comandos en Google Distributed Cloud o Google Distributed Cloud para actualizar el plano de control con las funciones predeterminadas y la AC de Istio. Introduce tus valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa Istio CA como autoridad de certificación.
    • --ca_cert El certificado intermedio
    • --ca_key La clave del certificado intermedio
    • --root_cert El certificado raíz
    • --cert_chain La cadena de certificados

AWS

Ejecuta los siguientes comandos en GKE on AWS para actualizar el plano de control con las funciones predeterminadas y la CA de Istio. Introduce tus valores en los marcadores de posición proporcionados. Puedes habilitar Ingress para la subred pública o la privada.

Público

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa Istio CA como autoridad de certificación.
    • --ca_cert El certificado intermedio
    • --ca_key La clave del certificado intermedio
    • --root_cert El certificado raíz
    • --cert_chain La cadena de certificados

Privado

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Guarda el siguiente archivo YAML con el nombre istio-operator-internal-lb.yaml:

    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

  3. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
  --custom_overlay istio-operator-internal-lb.yaml
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa Istio CA como autoridad de certificación.
    • --ca_cert El certificado intermedio
    • --ca_key La clave del certificado intermedio
    • --root_cert El certificado raíz
    • --cert_chain La cadena de certificados

Amazon EKS

Ejecuta los siguientes comandos en Amazon EKS para actualizar el plano de control con las funciones predeterminadas y la CA de Istio. Introduce tus valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa Istio CA como autoridad de certificación.
    • --ca_cert El certificado intermedio
    • --ca_key La clave del certificado intermedio
    • --root_cert El certificado raíz
    • --cert_chain La cadena de certificados

Microsoft AKS

Ejecuta los siguientes comandos en Amazon EKS para actualizar el plano de control con las funciones predeterminadas y la CA de Istio. Introduce tus valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa Istio CA como autoridad de certificación.
    • --ca_cert El certificado intermedio
    • --ca_key La clave del certificado intermedio
    • --root_cert El certificado raíz
    • --cert_chain La cadena de certificados

Cambiar a una versión superior con funciones opcionales

Un archivo de superposición es un archivo YAML que contiene un IstioOperator recurso personalizado (CR) que se pasa a asmcli para configurar el plano de control. Puedes anular la configuración predeterminada del plano de control y habilitar una función opcional pasando el archivo YAML a asmcli. Puedes añadir más superposiciones y cada archivo de superposición anula la configuración de las capas anteriores.

GKE

Ejecuta el siguiente comando para instalar el plano de control con una función opcional. Para añadir varios archivos, especifica --custom_overlay y el nombre del archivo. Por ejemplo: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml Introduce los valores en los marcadores de posición proporcionados.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE
  • --project_id, --cluster_name y --cluster_location: especifica el ID del proyecto en el que se encuentra el clúster, el nombre del clúster y la zona o la región del clúster.
  • --fleet_id El ID del proyecto del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster al registrarlo.
  • --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 secuencia de comandos:
    • 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 Usa la autoridad de certificación de Cloud Service Mesh como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura la autoridad de certificación de Cloud Service Mesh para usar Workload Identity de la flota.
  • --custom_overlay Especifica el nombre del archivo de superposición.

Fuera de Google Cloud

Ejecuta los siguientes comandos en Google Distributed Cloud, GKE en AWS, Amazon EKS o Microsoft AKS. Introduce tus valores en los marcadores de posición proporcionados.

  1. Define el contexto actual en tu clúster de usuario:

    kubectl config use-context CLUSTER_NAME

  2. Ejecuta asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca \
  --custom_overlay OVERLAY_FILE
    • --fleet_id El ID del proyecto del proyecto host de la flota.
    • --kubeconfig La ruta completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, no funcionarán las ubicaciones de archivos kubeconfig relativas que usen `~`.
    • --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í.
    • --platform multicloud Especifica que la plataforma es algo distinto Google Cloud, como una plataforma local o multicloud.
    • --enable_all Permite que la secuencia de comandos:
      • 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 Usa la autoridad de certificación de Cloud Service Mesh como autoridad de certificación. Si cambias las autoridades de certificación durante una actualización, se producirá un tiempo de inactividad. asmcliconfigura la autoridad de certificación de Cloud Service Mesh para usar Workload Identity de la flota.
    • --custom_overlay Especifica el nombre del archivo de superposición.

Actualizar pasarelas

Si tienes pasarelas implementadas, también tendrás que actualizarlas. Para llevar a cabo una actualización sencilla, consulta la sección Actualizaciones in situ de la guía Instalar y actualizar pasarelas.

Cambiar al nuevo plano de control

  1. Obtiene la etiqueta de revisión que está en istiod.

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

    El resultado del comando es similar al siguiente.

    NAME                                                 READY   STATUS    RESTARTS   AGE   REV
istiod-asm-11910-9-67998f4b55-lrzpz           1/1     Running   0          68m   asm-11910-9
istiod-asm-11910-9-67998f4b55-r76kr           1/1     Running   0          68m   asm-11910-9
istiod-1187-26-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-11910-9
istiod-1187-26-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-11910-9

    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.

    2. También debe tener en cuenta el valor de la etiqueta de revisión de la versión antigua de istiod. Lo necesitas para eliminar la versión antigua de istiod cuando termines de mover las cargas de trabajo a la nueva versión. En el ejemplo de salida, el valor de la etiqueta de revisión de la versión antigua es asm-11910-9.

  2. Añade la etiqueta de revisión a un espacio de nombres de aplicación y quita la etiqueta istio-injection (si existe). En el siguiente comando, cambia REVISION por el valor que coincida 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. 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.

  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.

  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. 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. Mover la etiqueta predeterminada:

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME>

    4. Elimina la versió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

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

      2. Elimina el recurso validatingwebhookconfiguration de la revisión antigua:

        kubectl delete validatingwebhookconfiguration istio-validator-OLD_REVISION-istio-system -n istio-system --ignore-not-found

    5. Quita la versión antigua 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. 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

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

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

      kubectl rollout restart deployment -n NAMESPACE

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

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

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

    6. Si no has incluido la marca --disable_canonical_service, asmcli se ha habilitado el controlador del servicio canónico. Te recomendamos que lo dejes habilitado, pero si necesitas inhabilitarlo, consulta Habilitar e inhabilitar el controlador del servicio canónico.

    7. Si tienes pasarelas implementadas, asegúrate de cambiar la etiqueta de revisión en el espacio de nombres o en la implementación para que coincida con la versión anterior de istiod. Sigue el mismo proceso que se describe en la sección "Actualizaciones in situ" de la guía Instalar y actualizar pasarelas.

Desplegar y volver a desplegar cargas de trabajo

La instalación (o actualización) no se completará hasta que habilites la inyección automática de proxy sidecar. Las migraciones desde Istio OSS y las actualizaciones siguen el proceso de actualización basado en revisiones (denominado "actualizaciones canary" en la documentación de Istio). Con una actualización basada en revisiones, la nueva versión del plano de control se instala junto al plano de control actual. Después, mueve algunas de tus cargas de trabajo a la nueva versión, lo que te permite monitorizar 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 nueva versión.

La secuencia de comandos define una etiqueta de revisión con el formato istio.io/rev=asm-11910-9 en istiod. Para habilitar la inyección automática, añade una etiqueta de revisión coincidente a tus espacios de nombres. El webhook del inyector de sidecar usa la etiqueta de revisión para asociar los sidecars inyectados con una revisión istiod concreta. Después de añadir la etiqueta, reinicia los pods del espacio de nombres para que se inserten los sidecars.

  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 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-11910-9
istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-11910-9
istiod-asm-11910-9-67998f4b55-lrzpz          1/1     Running   0          68m   asm-11910-9
istiod-asm-11910-9-67998f4b55-r76kr          1/1     Running   0          68m   asm-11910-9
istiod-asm-1187-26-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-11910-9
istiod-asm-1187-26-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-11910-9

    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.

    2. También debe tener en cuenta el valor de la etiqueta de revisión de la versión antigua de istiod. Lo necesitas para eliminar la versión antigua de istiod cuando termines de mover las cargas de trabajo a la nueva versión. En el ejemplo de salida, el valor de la etiqueta de revisión de la versión antigua es asm-11910-9.

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

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

    Resultado esperado: service/istio-ingressgateway patched

  3. Añade 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 coincida 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. 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.

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

    kubectl rollout restart deployment -n NAMESPACE

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

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

  7. 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. Mueve la etiqueta predeterminada.

      <OUTPUT_DIR>/istioctl tag set default --revision <NEW REVISION NAME> --overwrite

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

    5. Elimina la versió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

    6. Quita la versión antigua 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. 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

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

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

      kubectl rollout restart deployment -n NAMESPACE

    4. Elimina la nueva implementación de istio-ingressgateway. 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

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

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

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

    7. Si no has incluido la marca --disable_canonical_service, el script ha habilitado el controlador del servicio canónico. Te recomendamos que lo dejes habilitado, pero si necesitas inhabilitarlo, consulta Habilitar e inhabilitar el controlador del servicio canónico.