Anthos Service Mesh 1.14 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

Actualiza Anthos Service Mesh

En esta página se explica cómo:

Ejecuta asmcli para actualizar de Anthos Service Mesh a Anthos Service Mesh 1.14.6.
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 Anthos Service Mesh desde la que puedes actualizar difiere según la plataforma.

GKE

Puedes actualizar directamente a Anthos Service Mesh 1.14.6-asm.16 en Google Kubernetes Engine desde las siguientes versiones:

1.12 o posterior

Local

Puedes actualizar directamente a Anthos Service Mesh 1.14.6-asm.16 en GKE en VMware y Google Distributed Cloud Virtual for Bare Metal desde las siguientes versiones:

1.12 o posterior

GKE en AWS

Puedes actualizar directamente a Anthos Service Mesh 1.14.6-asm.16 en GKE on AWS desde las siguientes versiones:

1.12 o posterior

Amazon EKS

Si tienes Anthos Service Mesh 1.7 instalado en EKS, deberás instalar Anthos Service Mesh 1.14 en un clúster nuevo. No se admiten las actualizaciones desde Anthos Service Mesh 1.7 a Anthos Service Mesh 1.14.

Microsoft AKS

Si tienes Anthos Service Mesh 1.7 instalado en AKS, deberás instalar Anthos Service Mesh 1.14 en un clúster nuevo. No se admiten las actualizaciones desde Anthos Service Mesh 1.7 a Anthos Service Mesh 1.14.

Antes de comenzar

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, necesitas las mismas personalizaciones cuando actualices a una versión nueva de Anthos Service Mesh o si 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.

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 Anthos Service Mesh:

Si actualizas una malla de varios clústeres en GKE que usa la autoridad certificadora de Anthos Service Mesh (CA de Mesh), ejecuta asmcli create-mesh para configurar la malla de varios clústeres a fin de que confíe en la identidad de carga de trabajo de la flota para no tener tiempo de inactividad entre el balanceo de cargas de varios clústeres durante la actualización.
Ejecuta asmcli install para instalar Anthos 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.
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.
Para completar la configuración de Anthos Service Mesh, debes habilitar la inyecció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 CA de Mesh como autoridad certificadora, debes ejecutar asmcli create-mesh antes de actualizar cada clúster. Con este comando, se configura la CA de Mesh para usar 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 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 Anthos Service Mesh con las funciones compatibles predeterminadas en tu plataforma y habilitar la autoridad certificada (CA de Mesh) de Anthos Service Mesh como autoridad certificadora.

Nota de la plataforma: La CA de Mesh no es compatible con GKE en AWS, Amazon EKS ni Microsoft AKS. Si ejecutas asmcli install y especificas --ca mesh_ca en estas plataformas, la instalación fallará.

GKE

Ejecuta el siguiente comando para actualizar el plano de control con las funciones predeterminadas y con la CA de 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 CA de Istio como la autoridad certificadora. Cambiar las autoridades certificadora durante una actualización causa tiempo de inactividad. asmcli configura la CA de Mesh para usar la identidad de carga de trabajo de la flota.

Local

Ejecuta los siguientes comandos en GKE en VMware o en Google Distributed Cloud Virtual para Bare Metal a fin de actualizar el plano de control con las funciones predeterminadas y la CA de la malla. Ingresa los valores en los marcadores de posición proporcionados.

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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 Usa la CA de Istio como la autoridad certificadora. Cambiar las autoridades certificadoras durante una actualización causa tiempo de inactividad. asmcli configura la CA de Mesh para usar la identidad de carga de trabajo de la flota.

Actualiza las funciones predeterminadas con el Servicio de CA

En esta sección, se muestra cómo ejecutar asmcli para actualizar Anthos Service Mesh con las funciones compatibles 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 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 GKE en VMware o en Google Distributed Cloud Virtual for Bare Metal a fin de actualizar el plano de control con las funciones predeterminadas y Certificate Authority Service. Ingresa los valores en los marcadores de posición proporcionados.

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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 Anthos Service Mesh con las funciones compatibles predeterminadas en tu plataforma y habilitar la CA 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 GKE en VMware o en Google Distributed Cloud Virtual for Bare Metal 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.

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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 on AWS 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. Puedes optar por habilitar Ingress para la subred pública o privada.

Pública

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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.

Privado

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```

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

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

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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 Usa la CA de Istio como la autoridad certificadora. Cambiar las autoridades certificadora durante una actualización causa tiempo de inactividad. asmcli configura la CA de Mesh para usar la identidad de carga de trabajo de la flota.
--custom_overlay Especifica el nombre del archivo de superposición.

Fuera de Google Cloud

Ejecuta los siguientes comandos en GKE en VMware, Google Distributed Cloud Virtual for Bare Metal, GKE on AWS, Amazon EKS o Microsoft AKS. Ingresa los valores en los marcadores de posición proporcionados.

Configura el contexto actual en tu clúster de usuario:
```
kubectl config use-context CLUSTER_NAME
```
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 "~" 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 Usa la CA de Istio como la autoridad certificadora. Cambiar las autoridades certificadora durante una actualización causa tiempo de inactividad. asmcli configura la CA de 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.

Cambia al nuevo plano de control

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-1146-16-67998f4b55-lrzpz           1/1     Running   0          68m   asm-1139-10
istiod-asm-1146-16-67998f4b55-r76kr           1/1     Running   0          68m   asm-1139-10
istiod-1139-10-1-5cd96f88f6-n7tj9    1/1     Running   0          27s   asm-1146-16
istiod-1139-10-1-5cd96f88f6-wm68b    1/1     Running   0          27s   asm-1146-16
```
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-1146-16.
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-1139-10.
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. Debido a que la inserción automática falla si un espacio de nombres tiene las etiquetas istio-injection y de revisión, todos los comandos kubectl label en la documentación de Anthos Service Mesh especifican ambas etiquetas de forma explícita.

Reinicia los Pods para activar la reinserción:

kubectl rollout restart deployment -n NAMESPACE

Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.
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 debes usar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh.
  Migra
  Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión:
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Actualizar
  1. Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, asegúrate de que OLD_REVISION coincida con la etiqueta de revisión de la versión anterior de istiod:
    
    kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
  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-1146-16 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.

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

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-1146-16.
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-1139-10.

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
Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection (si existe). En el siguiente comando, cambia REVISION por el valor que coincide con la nueva revisión de istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```
Si ves "istio-injection not found" en el resultado, puedes ignorarlo. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection antes. Debido a que la inserción automática falla si un espacio de nombres tiene las etiquetas istio-injection y de revisión, todos los comandos kubectl label en la documentación de Anthos Service Mesh especifican ambas etiquetas de forma explícita.

Reinicia los Pods para activar la reinserción:

kubectl rollout restart deployment -n NAMESPACE

Prueba la aplicación para verificar que las cargas de trabajo funcionen de forma correcta.
Si tienes cargas de trabajo en otros espacios de nombres, repite los pasos para etiquetar el espacio de nombres y reiniciar los pods.
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 el Deployment istio-ingressgateway anterior. El comando que debes ejecutar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh:
  Migra
  Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.
  
  kubectl delete deploy/istio-ingressgateway -n istio-system
  
  Actualizar
  Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, reemplaza OLD_REVISION por la etiqueta de revisión para la versión anterior de istio-ingressgateway.
  
  kubectl delete deploy -l app=istio-ingressgateway,istio.io/rev=OLD_REVISION -n istio-system --ignore-not-found=true
5. Borra la versión anterior de istiod. El comando que debes usar depende de si migras desde Istio o actualizas desde una versión anterior de Anthos Service Mesh.
  Migra
  Si migraste desde Istio, la istio-ingressgateway anterior no tiene una etiqueta de revisión.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod -n istio-system --ignore-not-found=true
  
  Actualizar
  Si actualizaste desde una versión anterior de Anthos Service Mesh, en el siguiente comando, asegúrate de que OLD_REVISION coincida con la etiqueta de revisión de la versión anterior de istiod.
  
  kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION -n istio-system --ignore-not-found=true
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.

Actualiza Anthos Service Mesh

GKE

Local

GKE en AWS

Amazon EKS

Microsoft AKS

Antes de comenzar

Personalizaciones del plano de control

Autoridad certificadora

Actualizar Anthos Service Mesh

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

URI del clúster

Archivo kubeconfig

Actualizar con funciones predeterminadas y la CA de Mesh

GKE

Local

Actualiza las funciones predeterminadas con el Servicio de CA

GKE

Local

Actualiza las funciones predeterminadas con la CA de Istio

GKE

Local

AWS

Pública

Privado

Amazon EKS

Microsoft AKS

Actualiza con funciones opcionales

GKE

Fuera de Google Cloud

Actualiza puertas de enlace

Cambia al nuevo plano de control

Completa la transición

Migra

Actualizar

Revertir

Implementa y vuelve a implementar las cargas de trabajo

Completa la transición

Migra

Actualizar

Migra

Actualizar

Revertir