Actualiza Cloud Service Mesh

En esta página se explica cómo:

• Ejecuta asmcli para actualizar de Cloud Service Mesh a Cloud Service Mesh1.18.7.

• De manera opcional, implementa una puerta de enlace de entrada.

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

La versión de Cloud Service Mesh desde la que puedes actualizar difiere según la plataforma.

GKE

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

1.16+

Local

Puedes actualizar directamente Cloud Service Mesh 1.18.7-asm.26 en Google Distributed Cloud y Google Distributed Cloud a partir de las siguientes versiones:

1.16+

GKE en AWS

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

1.16+

GKE en Azure

GKE en Azure solo es compatible con Cloud Service Mesh 1.16. Actualizaciones desde no se admiten las versiones anteriores de Cloud Service Mesh.

Amazon EKS

Si tienes Cloud Service Mesh 1.7 instalado en EKS, deberás instalar Cloud Service Mesh 1.18 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh1.18 .

Microsoft AKS

Si tienes Cloud Service Mesh 1.7 instalado en AKS, deberás instalar Cloud Service Mesh 1.18 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh1.18 .

Antes de comenzar

Advertencia: Las herramientas de GitOps (como el Sincronizador de configuración, Argo CD, Terraform, y Jenkins) pueden interferir en la instalación, migración o de actualización de software. Para obtener mejores resultados, inhabilita tus herramientas de GitOps antes de instalar, migrar o actualizar Cloud Service Mesh.

Antes de comenzar, asegúrate de lo siguiente:

• Revisa los requisitos.
• Revisa la información en Planifica la actualización.
• Instala las herramientas necesarias
• Descarga asmcli.
• Otorga permisos de administrador del clúster.
• Valida el proyecto y el clúster.

Personalizaciones del plano de control

Si personalizaste la instalación anterior, necesitarás las mismas personalizaciones cuando actualizas a una nueva versión de Cloud Service Mesh o migras desde Istio. Si personalizaste la instalación agregando la marca --set values a istioctl install, debes agregar esa configuración a un archivo YAML IstioOperator, denominado archivo de superposición. Especifica el archivo de superposición mediante la opción --custom_overlay con el nombre del archivo cuando ejecutes la secuencia de comandos. La secuencia de comandos pasa el archivo de superposición a istioctl install.

Precaución: Omitir el archivo de configuración da como resultado una instalación correcta. Sin embargo, la malla de servicios tiene una configuración diferente a la que esperabas, ya que los valores omitidos se restablecen a los predeterminados cuando se vuelven a implementar el plano de control y la puerta de enlace de entrada.

Autoridad certificadora

Cambiar la autoridad certificadora (CA) durante una actualización causa tiempo de inactividad. Durante la actualización, el tráfico de mTLS se interrumpe hasta que todas las cargas de trabajo cambien al plano de control nuevo con la CA nueva.

Actualizar Anthos Service Mesh

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

1. Si actualizas una malla de varios clústeres en GKE que usa Autoridad certificadora de la malla de servicios de Cloud, ejecuta asmcli create-mesh para configurar malla de varios clústeres en la que se confía identidades para cargas de trabajo de flotas para el balanceo de cargas entre clústeres sin tiempo de inactividad durante la actualización.

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

3. De manera opcional, instala o actualiza una puerta de enlace de entrada. De forma predeterminada, asmcli no se instala istio-ingressgateway. Te recomendamos que implementes y administres el plano de control y las puertas de enlace por separado. Si necesitas que el istio-ingressgateway predeterminado esté instalado con el plano de control en el clúster, incluye el argumento --option legacy-default-ingressgateway.

4. Para completar la configuración de Cloud Service Mesh, debes habilitar la inserción automática del archivo adicional y, luego, implementar o volver a implementar las cargas de trabajo.

Configura la malla de varios clústeres para confiar en la identidad de la carga de trabajo de la flota

Si actualizas una malla de varios clústeres en GKE que usa la autoridad certificadora de Cloud Service Mesh como autoridad certificadora, debes ejecutar asmcli create-mesh antes de actualizar cada clúster. Este comando configura La autoridad certificadora de Cloud Service Mesh para usar el grupo de identidades para cargas de trabajo de la flota FLEET_PROJECT_ID.svc.id.goog, como dominio de confianza después de que 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 para cada clúster o la ruta del archivo kubeconfig.

URI del clúster

En el siguiente comando, se reemplaza FLEET_PROJECT_ID por el ID del proyecto del proyecto host de flota y el URI del clúster por el nombre, la zona o región y el ID del proyecto para 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, reemplaza: FLEET_PROJECT_ID por el ID del proyecto del proyecto host de la flota y PATH_TO_KUBECONFIG por la ruta de acceso a 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 funciones predeterminadas y la CA de Mesh

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 la autoridad certificadora de Cloud Service Mesh como autoridad certificadora.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y la AC de Cloud Service Mesh. Ingresa 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

• --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 región del clúster.
• --fleet_id El ID del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster cuando este se registró.
• --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í.
  Nota: Toma nota de este directorio --output_dir. Deberás hacer referencia a ella cuando implementes puertas de enlace.
• --enable_all permite que la secuencia de comandos 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 Usa la autoridad certificadora de Cloud Service Mesh como la autoridad certificadora. Cambiar las autoridades certificadoras durante una la actualización causa tiempo de inactividad. asmcliconfigura autoridad certificadora de la malla de servicios de Cloud flota Workload Identity

Otros clústeres de GKE Enterprise

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

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, las ubicaciones de archivos kubeconfig relativas que usan un "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usar la autoridad certificadora de Cloud Service Mesh como de la autoridad certificadora. Cambiar las autoridades certificadoras durante una actualización causa tiempo de inactividad. asmcliconfigura autoridad certificadora de la malla de servicios de Cloud flota Workload Identity

Actualiza las funciones predeterminadas con el Servicio de CA

En esta sección, se muestra cómo ejecutar asmcli para actualizar Cloud Service Mesh con el funciones compatibles predeterminadas para tu plataforma y habilita Certificate Authority Service.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y Certificate Authority Service. Ingresa 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 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 región del clúster.
• --fleet_id El ID del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster cuando este se registró.
• --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í.
  Nota: Toma nota de este directorio --output_dir. Deberás hacer referencia a ella cuando implementes puertas de enlace.
• --enable_all permite que la secuencia de comandos 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 gcp_cas: Usa Certificate Authority Service como la autoridad certificadora. Cambiar las autoridades certificadoras durante una actualización provoca tiempo de inactividad. asmcli configura Certificate Authority Service para usar la identidad de carga de trabajo de flota
• --ca_pool El identificador completo del grupo de CA de Certificate Authority Service.

Local

Ejecuta los siguientes comandos en Google Distributed Cloud o Google Distributed Cloud para actualizar el plano de control con la configuración y Certificate Authority Service. Ingresa los valores en los marcadores de posición proporcionados.

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además: las ubicaciones de archivos kubeconfig relativas que usan el símbolo "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 gcp_cas: Usa Certificate Authority Service como la autoridad certificadora. Cambiar las autoridades certificadoras durante una actualización provoca tiempo de inactividad. asmcli configura Certificate Authority Service para usar la identidad de carga de trabajo de flota
   • --ca_pool El identificador completo del grupo de CA de Certificate Authority Service.

Actualiza 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 en tu plataforma y habilitar la AC de Istio.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y con la CA de Istio. Ingresa 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 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 región del clúster.
• --fleet_id El ID del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster cuando este se registró.
• --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í.
  Nota: Toma nota de este directorio --output_dir. Deberás hacer referencia a ella cuando implementes puertas de enlace.
• --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio. Cambiar las autoridades certificadoras durante una actualización causa tiempo de inactividad.

Local

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

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además: las ubicaciones de archivos kubeconfig relativas que usan el símbolo "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio como la autoridad certificada.
   • --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.

AWS

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

Pública

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, las ubicaciones de archivos kubeconfig relativas que usan un "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio como la autoridad certificada.
   • --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.

Privada

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

   kubectl config use-context CLUSTER_NAME
   

2. Guarda el siguiente YAML en un archivo llamado 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, las ubicaciones de archivos kubeconfig relativas que usan un "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio como la autoridad certificada.
   • --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.

Amazon EKS

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

Nota de la plataforma: Si tienes Cloud Service Mesh 1.7 instalado en EKS, deberás instalar Cloud Service Mesh 1.18 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh 1.18 .

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además: las ubicaciones de archivos kubeconfig relativas que usan el símbolo "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio como la autoridad certificada.
   • --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.

Microsoft AKS

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

Nota: Si tienes Cloud Service Mesh 1.7 instalado en AKS, deberás hacer lo siguiente: instalar Cloud Service Mesh 1.18 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh 1.18 .

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, las ubicaciones de archivos kubeconfig relativas que usan un "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usa la CA de Istio como la autoridad certificada.
   • --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.

Actualiza con funciones opcionales

Un archivo de superposición es un archivo YAML que contiene un recurso personalizado (CR) IstioOperator que pasas a asmcli para configurar el plano de control. Puedes anular la configuración predeterminada del plano de control y habilitar una función opcional si pasas el archivo YAML a asmcli. Puedes agregar capas a más superposiciones, y cada archivo superpuesto 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 agregar 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. Ingresa 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 región del clúster.
• --fleet_id El ID del proyecto host de la flota. Si no incluyes esta opción, asmcli usará el proyecto en el que se creó el clúster cuando este se registró.
• --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í.
  Nota: Toma nota de este directorio --output_dir. Deberás hacer referencia a ella cuando implementes puertas de enlace.
• --enable_all permite que la secuencia de comandos 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 Usar la autoridad certificadora de Cloud Service Mesh como de la autoridad certificadora. Cambiar las autoridades certificadoras durante una la actualización causa tiempo de inactividad. asmcliconfigura autoridad certificadora de la malla de servicios de Cloud flota Workload Identity
• --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. Ingresa los valores en los marcadores de posición proporcionados.

Nota de la plataforma: Si tienes instalado Cloud Service Mesh 1.7 en EKS, deberás instalar Cloud Service Mesh 1.18 en un clúster nuevo. No se admiten las actualizaciones de Cloud Service Mesh 1.7 a Cloud Service Mesh 1.18 .

1. Configura 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 host de la flota.
   • --kubeconfig La ruta de acceso completa al archivo kubeconfig. La variable de entorno $PWD no funciona aquí. Además, las ubicaciones de archivos kubeconfig relativas que usan un "~" no funcionarán.
   • --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í.
   • --platform multicloud especifica que la plataforma es algo distinto de Google Cloud, como el entorno local o las múltiples nubes.
   • --enable_all permite que la secuencia de comandos 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 Usar la autoridad certificadora de Cloud Service Mesh como de la autoridad certificadora. Cambiar las autoridades certificadoras durante una actualización provoca tiempo de inactividad. asmcli configura la autoridad certificadora de Cloud Service Mesh para usar la identidad de carga de trabajo de la flota.
   • --custom_overlay Especifica el nombre del archivo de superposición.

Actualiza puertas de enlace

Si tienes puertas de enlace implementadas, también deberás actualizarlas. Para realizar una actualización simple, sigue la sección sobre actualizaciones locales en la guía Instala y actualiza puertas de enlace.

Advertencia: Si instalaste Cloud Service Mesh con cualquier otro método que no sea asmcli, la la puerta de enlace de entrada predeterminada instalada se quitará, a menos que pases el argumento --option legacy-default-ingressgateway.

Cambia al nuevo plano de control

1. Obtén 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-1187-26-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1178-20
   istiod-asm-1187-26-67998f4b55-r76kr           1/1     Running   0          68m   asm-1178-20
   istiod-1178-20-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1187-26
   istiod-1178-20-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1187-26

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

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

2. Agrega la etiqueta de revisión a un espacio de nombres de la aplicación 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. Dado que el comportamiento de la inserción automática indefinido cuando un espacio de nombres tiene el istio-injection y el etiqueta de revisión, todos los comandos kubectl label en Cloud Service Mesh de la documentación garantizan de forma explícita que solo se establezca uno.

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

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

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

      1. Si actualizaste desde una versión anterior de Cloud Service Mesh, en la siguiente comando, asegúrate de que OLD_REVISION coincide 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. Borra el recurso validatingwebhookconfiguration de la revisión anterior:

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

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

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

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

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

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

   6. Si no incluiste la marca --disable_canonical_service, asmcli 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.

   7. Si tienes puertas de enlace implementadas, asegúrate de cambiar la etiqueta de revisión en el espacio de nombres o 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 locales de la guía Instala y actualiza puertas de enlace.

Implementa y vuelve a implementar las cargas de trabajo

La instalación (o actualización) no se completará 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.

La secuencia de comandos establece una etiqueta de revisión en el formato istio.io/rev=asm-1187-26 en istiod. Para habilitar la inserción automática, agrega una etiqueta de revisión coincidente a tus espacios de nombres. El webhook de inserción 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-1187-26
   istio-ingressgateway-asm-182-2-8b5fc8767-hn4w2      1/1     Running   0          20s   asm-1187-26
   istiod-asm-1187-26-67998f4b55-lrzpz          1/1     Running   0          68m   asm-1178-20
   istiod-asm-1187-26-67998f4b55-r76kr          1/1     Running   0          68m   asm-1178-20
   istiod-asm-1178-20-5cd96f88f6-n7tj9 1/1     Running   0          27s   asm-1187-26
   istiod-asm-1178-20-5cd96f88f6-wm68b 1/1     Running   0          27s   asm-1187-26

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

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

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

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

   Resultado esperado: service/istio-ingressgateway patched

3. 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. Dado que el comportamiento de la inserción automática indefinido cuando un espacio de nombres tiene el istio-injection y el etiqueta de revisión, todos los comandos kubectl label en Cloud Service Mesh de la documentación garantizan de forma explícita que solo se establezca uno.

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

   kubectl rollout restart deployment -n NAMESPACE

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

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

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

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

   4. Borra el Deployment istio-ingressgateway anterior. El comando que que se ejecutará depende de si estás migrando desde Istio o actualizando de 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
      

   5. Borra la versió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 la siguiente comando, asegúrate de que OLD_REVISION coincide 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 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 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

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

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

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

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

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

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