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

Instalar Anthos Service Mesh en GKE

En esta guía, se explica cómo instalar, migrar o actualizar a la versión 1.7.8 de Anthos Service Mesh para una malla que contiene uno o más clústeres de GKE que se encuentran en el mismo proyecto. Debes usar una secuencia de comandos proporcionada por Google, que configura tu proyecto y tu clúster y, luego, instalar Anthos Service Mesh.

Puedes usar esta guía y la secuencia de comandos para los siguientes casos de uso:

Instalaciones nuevas de Anthos Service Mesh.
Actualizaciones desde Anthos Service Mesh 1.6 o una versión de parche 1.7. No se admiten las actualizaciones a versiones anteriores.
Migraciones de Istio 1.6 o 1.7 de código abierto a Anthos Service Mesh. No se admite la migración desde una versión anterior de Istio.
Migraciones desde la versión 1.6 del complemento Istio on GKE en Anthos Service Mesh. Antes de que puedas migrar a Anthos Service Mesh, debes actualizar a Istio 1.6 con Operator. Para ver los pasos de migración completos del complemento, consulta Migra a Anthos Service Mesh en la documentación de Istio on GKE.

Para una malla de varios clústeres en la que los clústeres se encuentran en diferentes proyectos, consulta Instalación y migración de varios clústeres o varios proyectos para GKE.

Antes de comenzar

En esta guía, suponemos que ya tienes lo siguiente:

Un proyecto de Google Cloud
Una cuenta de facturación de Cloud
Un clúster de GKE que cumple con los requisitos.

Si realizas la migración desde Istio, asegúrate de revisar Prepárate para la migración desde Istio.

Diferencias entre Anthos Service Mesh y Anthos

Los suscriptores de GKE Enterprise deben asegurarse de habilitar la API de GKE Enterprise.

Habilitar la API
Si no eres suscriptor de GKE Enterprise, puedes instalar Anthos Service Mesh, pero ciertos elementos y funciones de la IU de Google Cloud Console solo están disponibles para los suscriptores de GKE Enterprise. Si deseas obtener información sobre lo que está disponible para suscriptores y usuarios no suscritos, consulta las diferencias en la IU de GKE Enterprise y Anthos Service Mesh. Si quieres obtener información sobre los precios de Anthos Service Mesh para usuarios no suscritos, consulta Precios.

La secuencia de comandos habilita todas las otras API de Google requeridas para ti.

Requisitos

El clúster de GKE debe cumplir con los siguientes requisitos:
- Su tipo de máquina debe tener, al menos, cuatro CPU virtuales, como e2-standard-4. Si el tipo de máquina del clúster no tiene al menos cuatro CPU virtuales, cámbialo como se describe en Migra cargas de trabajo a diferentes tipos de máquina.
- La cantidad mínima de nodos depende del tipo de máquina. Anthos Service Mesh requiere al menos ocho CPU virtuales. Si el tipo de máquina tiene cuatro CPU virtuales, el clúster debe tener al menos dos nodos. Si el tipo de máquina tiene ocho CPU virtuales, el clúster solo necesita un nodo. Si necesitas agregar nodos, consulta Cambia el tamaño de un clúster.
- La secuencia de comandos habilita Workload Identity en tu clúster. Workload Identity es el método recomendado para llamar a las API de Google. Habilitar Workload Identity cambia la forma en que se protegen las llamadas de tus cargas de trabajo a las API de Google, como se describe en Limitaciones de Workload Identity.
- Aunque es una acción opcional, se recomienda inscribir el clúster en un canal de versiones. Te recomendamos que te inscribas en el canal de versiones regular, ya que otros se podrían basar en una versión de GKE que no es compatible con Anthos Service Mesh 1.7.8. Para obtener más información, consulta Entornos compatibles. Sigue las instrucciones en Inscribe un clúster existente en un canal de versiones si tienes una versión estática de GKE.
Para que se los incluya en la malla de servicios, los puertos de servicio deben tener un nombre, y ese nombre debe incluir el protocolo del puerto en la siguiente sintaxis: name: protocol[-suffix], en la que los corchetes indican un sufijo opcional que debe comenzar con un guion. Para obtener más información, consulta Asigna nombres a puertos de servicio.
Si instalas Anthos Service Mesh en un clúster privado, debes abrir el puerto 15017 en el firewall para que el webhook se use con la incorporación automática de sidecar y funcione de manera correcta. Para obtener más información, consulta Abre un puerto en un clúster privado.
Si creaste un perímetro de servicio en tu organización, es posible que debas agregar el servicio de CA de Mesh al perímetro. Para obtener más información, consulta Agrega la CA de Mesh a un perímetro de servicio.
Para las migraciones, istiod debe instalarse en el espacio de nombres istio-system.

Restricciones

Un proyecto de Google Cloud solo puede tener una malla asociada.

Elige una autoridad certificada

Para las instalaciones y migraciones nuevas, puedes usar la autoridad certificada de Anthos Service Mesh (CA de Mesh) o Citadel (ahora incorporada en istiod) como autoridad certificada (CA) para emitir certificados de mutual TLS (mTLS).

Por lo general, recomendamos que uses CA de Mesh por los siguientes motivos:

La CA de Mesh es un servicio altamente confiable y escalable que está optimizado para cargas de trabajo escaladas de forma dinámica en Google Cloud.
Con la CA de Mesh, Google administra la seguridad y la disponibilidad del backend de CA.
La CA de Mesh te permite tener una sola raíz de confianza entre clústeres.

En las instalaciones nuevas de Anthos Service Mesh, la secuencia de comandos habilita la CA de Mesh de forma predeterminada.

Sin embargo, hay casos en los que podrías considerar usar Citadel, como los que se mencionan a continuación:

Si tienes una CA personalizada.
Si realizas la migración desde Istio.

Si eliges Citadel, no hay tiempo de inactividad porque el tráfico de mTLS no se interrumpe durante la migración. Si eliges CA de Mesh, debes programar el tiempo de inactividad para la migración, ya que la raíz de confianza cambia de Citadel a la CA de Mesh. Para completar la migración a la raíz de confianza de la CA de Mesh, debes reiniciar todos los Pods en todos los espacios de nombres. Durante este proceso, los Pods antiguos no pueden establecer conexiones mTLS con los Pods nuevos.

En los certificados de CA de Mesh, se incluyen los siguientes datos sobre los servicios de tu aplicación:

El ID del proyecto de Google Cloud
El espacio de nombres de GKE
El nombre de la cuenta de servicio de GKE

Prepárate para una migración o actualización

Si realizas la migración desde Istio, asegúrate de revisar Prepárate para la migración desde Istio.

Si personalizaste la instalación anterior, necesitas las mismas personalizaciones cuando migras o actualizas a Anthos Service Mesh. Si personalizaste la instalación mediante el agregado de la marca --set values, te recomendamos que agregues esa configuración a un archivo de configuración IstioOperator. Especifica el archivo de configuración con --custom_overlay con el archivo de configuración cuando ejecutes la secuencia de comandos.

Instala las herramientas necesarias

Puedes ejecutar la secuencia de comandos en Cloud Shell o en tu máquina local que ejecuta Linux.

Para ejecutar la secuencia de comandos de forma local, haz lo siguiente:

Asegúrate de tener instaladas las siguientes herramientas:
- La CLI de Google Cloud
- Las herramientas de línea de comandos estándar: awk, curl, grep, sed, sha256sum y tr
- git
- kubectl
- jq
Autentica con la CLI de gcloud:
```
gcloud auth login
```
Actualiza los componentes:
```
gcloud components update
```
Asegúrate de que git esté en tu ruta para que kpt pueda encontrarlo.
Descarga la versión de kpt requerida.

Ejecuta la secuencia de comandos

En esta sección, se describe cómo descargar la secuencia de comandos, configurar los parámetros necesarios y opcionales, y ejecutar la secuencia de comandos. Para obtener una explicación detallada de lo que hace la secuencia de comandos, consulta Información sobre la secuencia de comandos.

Descarga la versión de la secuencia de comandos que instala Anthos Service Mesh 1.7.8 en el directorio de trabajo actual:
```
curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7 > install_asm
```
Aunque descargas la secuencia de comandos de una ubicación segura de Cloud Source Repositories, la secuencia de comandos también está disponible en GitHub en el repositorio anthos-service-mesh-packages para que puedas ver lo que hace antes de descargarlo. La versión de la secuencia de comandos install_asm en la rama release-1.7-asm instala Anthos Service Mesh 1.7.8.

Descarga el SHA-256 del archivo en el directorio de trabajo actual:

curl https://storage.googleapis.com/csm-artifacts/asm/install_asm_1.7.sha256 > install_asm.sha256

Con ambos archivos en el mismo directorio, verifica la descarga:
```
sha256sum -c --ignore-missing install_asm.sha256
```
Si la verificación se realiza de forma correcta, el comando genera este resultado: install_asm: OK.

Para mayor compatibilidad, el archivo install_asm.sha256 incluye la suma de verificación dos veces a fin de permitir que cualquier versión de la secuencia de comandos cambie su nombre a install_asm. Si recibes un error que indica que --ignore-missing no existe, vuelve a ejecutar el comando anterior sin la marca --ignore-missing.
Haz que la secuencia de comandos sea ejecutable:
```
chmod +x install_asm
```
Configura las opciones y especifica las marcas para ejecutar la secuencia de comandos. Siempre debes incluir las siguientes opciones: project_id, cluster_name, cluster_location y mode. Según el mode, es posible que debas incluir la opción ca.
- Las opciones project_id, cluster_name y cluster_location identifican el clúster en el que se instalará Anthos Service Mesh.
- El mode es install, migrate o upgrade.
- La ca especifica la autoridad certificada como mesh_ca o citadel.
En la siguiente sección, se proporcionan ejemplos típicos de la ejecución de la secuencia de comandos. Para obtener una descripción completa de los argumentos de la secuencia de comandos, consulta Opción y marcas.
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.

Ejemplos

En esta sección, se muestran ejemplos de ejecución de la secuencia de comandos en cada mode y algunos argumentos adicionales que pueden resultarte útiles. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos.

Solo validación

En el siguiente ejemplo, se muestra la ejecución de la secuencia de comandos con la opción --only_validate. Con esta opción, la secuencia de comandos no realiza ningún cambio en tu clúster y no instala Anthos Service Mesh. La secuencia de comandos valida lo siguiente:

Tu entorno tiene las herramientas necesarias.
Tienes el permiso requerido en el proyecto especificado.
El clúster cumple con los requisitos mínimos.
El proyecto tiene habilitadas todas las API de Google requeridas.

De forma predeterminada, la secuencia de comandos descarga y extrae el archivo de instalación, y descarga el paquete de configuración asm de GitHub a un directorio temporal. Antes de salir, la secuencia de comandos genera un mensaje que proporciona el nombre del directorio temporal. Puedes especificar un directorio existente para las descargas con la opción --output_dir DIR_PATH. La opción --output_dir te permite usar la herramienta de línea de comandos de istioctl si la necesitas. Además, los archivos de configuración para habilitar funciones opcionales se incluyen en el directorio asm/istio/options.

Ejecuta el siguiente comando para validar tu configuración y descargar el archivo de instalación, y el paquete asm en el directorio OUTPUT_DIR:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --output_dir DIR_PATH \
  --only_validate

Si la operación es exitosa, la secuencia de comandos mostrará lo siguiente:

./install_asm \
install_asm: Setting up necessary files...
install_asm: Creating temp directory...
install_asm: Generating a new kubeconfig...
install_asm: Checking installation tool dependencies...
install_asm: Downloading ASM..
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 57.0M  100 57.0M    0     0  30.6M      0  0:00:01  0:00:01 --:--:-- 30.6M
install_asm: Downloading ASM kpt package...
fetching package /asm from https://github.com/GoogleCloudPlatform/anthos-service-mesh-packages to asm
install_asm: Checking for project PROJECT_ID...
install_asm: Confirming cluster information...
install_asm: Confirming node pool requirements...
install_asm: Fetching/writing GCP credentials to kubeconfig file...
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
install_asm: Checking Istio installations...
install_asm: Checking required APIs...
install_asm: Successfully validated all requirements to install ASM from this computer.

Si una de las pruebas no pasa la validación, la secuencia de comandos mostrará un mensaje de error. Por ejemplo, si tu proyecto no tiene habilitadas todas las API de Google necesarias, verás el siguiente error:

ERROR: One or more APIs are not enabled. Please enable them and retry, or
re-run the script with the '--enable_apis' flag to allow the script to enable
them on your behalf.

Instalación

El siguiente comando ejecuta la secuencia de comandos para una instalación nueva, habilita la CA de Mesh (la CA predeterminada para las instalaciones nuevas, por lo que no necesitas la opción ca en este caso) y permite que la secuencia de comandos habilite las API de Google requeridas.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis

Instalación con Citadel como la CA

Esta sección explica cómo:

Generar certificados y claves que usa Anthos Service Mesh para firmar tus cargas de trabajo.
Ejecuta la secuencia de comandos para una instalación y habilita Citadel como la CA.

Te recomendamos que uses Citadel como la CA solo cuando necesites una CA personalizada.

Para obtener la mayor seguridad, recomendamos enfáticamente que mantengas una CA raíz sin conexión y uses las CA subordinadas a fin de emitir CA para cada clúster. Para obtener más información, consulta Conecta certificados de CA. En esta configuración, todas las cargas de trabajo en la malla de servicios usan la misma CA raíz. Cada CA de Anthos Service Mesh usa una clave y un certificado intermedios de firma de CA firmados por la CA raíz. Cuando existen varias CA dentro de una malla, se establece una jerarquía de confianza entre las CA. Puedes repetir estos pasos a fin de aprovisionar certificados y claves para cualquier cantidad de autoridades certificadoras.

Crea un directorio para los certificados y las claves:
```
mkdir -p certs && \
pushd certs
```
Genera un certificado raíz y una clave:
```
make -f ../tools/certs/Makefile.selfsigned.mk root-ca
```
Esto genera los siguientes archivos:
- root-cert.pem: El certificado raíz
- root-key.pem: La clave raíz
- root-ca.conf: La configuración para openssl a fin de generar el certificado raíz
- root-cert.csr: La CSR para el certificado raíz
Genera un certificado intermedio y una clave:
```
make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts
```
Con esta acción, se generan estos archivos en un directorio llamado cluster1:
- ca-cert.pem: Los certificados intermedios
- ca-key.pem: La clave intermedia
- cert-chain.pem: La cadena de certificados que usa Istio
- root-cert.pem: El certificado raíz
Nota: Puedes reemplazar cluster1 por un nombre diferente. Por ejemplo, make mycluster-certs crea un directorio llamado mycluster.

Si sigues estos pasos en una computadora sin conexión, copia el directorio generado en la computadora en la que ejecutas la secuencia de comandos.

Ejecuta la secuencia de comandos y, luego, incluye los archivos que generaste para los certificados y la clave.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --enable_all

Instalación con un archivo de superposición

Un archivo de superposición es un archivo YAML que contiene un recurso personalizado (CR) IstioOperator que pasas a install_asm 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 install_asm. Puedes agregar capas a más superposiciones, y cada archivo superpuesto anula la configuración de las capas anteriores.

Si especificas más de un CR en un archivo YAML, install_asm divide el archivo en varios archivos YAML temporales, uno para cada CR. La secuencia de comandos divide los CR en archivos separados porque istioctl install solo aplica el primer CR en un archivo YAML que contiene más de un CR.

En el siguiente ejemplo, se realiza una instalación y se incluye un archivo de superposición para personalizar la configuración del plano de control. En el siguiente comando, cambia OVERLAY_FILE por el nombre del archivo YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --custom_overlay OVERLAY_FILE

Instalación con una opción

En el siguiente ejemplo, se realiza una instalación y se incluye el archivo egressgateways.yaml del paquete asm, lo que habilita una puerta de enlace de salida. Ten en cuenta que no incluyes la extensión .yaml. La secuencia de comandos recupera el archivo para que no tengas que descargar primero el paquete asm.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_apis \
  --option egressgateways

Puedes usar --option para habilitar una función opcional. Si necesitas realizar modificaciones en cualquiera de los archivos del directorio asm/istio/options en el paquete asm, descarga el paquete asm, realiza los cambios y, luego, incluye el archivo --custom_overlay.

Para descargar el paquete asm en el directorio de trabajo actual, de manera que puedas realizar modificaciones en los archivos, haz lo siguiente:

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

Si ejecutaste el ejemplo Solo validar donde especificaste la opción --output_dir, los archivos de configuración están en el directorio de salida especificado en asm/istio/options.

Migración desde Istio

Si migras desde Istio con Citadel como la CA, puedes continuar usando Citadel después de migrar a Anthos Service Mesh. El siguiente comando ejecuta la secuencia de comandos para una migración y habilita Citadel como la CA. Esta migración solo implementa el plano de control. No cambia la CA raíz ni afecta a las cargas de trabajo existentes.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m migrate \
  -c citadel \
  --enable_apis

Migra con un archivo de superposición

En el siguiente ejemplo, se realiza una migración y se incluye un archivo de superposición para personalizar la configuración del plano de control. En el siguiente comando, cambia OVERLAY_FILE por el nombre del archivo YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode migrate \
  --ca citadel \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Actualiza

El siguiente comando ejecuta la secuencia de comandos para la actualización. La secuencia de comandos no te permite cambiar a otra CA, por lo que no es necesario incluir la opción ca.

./install_asm \
  -p PROJECT_ID \
  -n CLUSTER_NAME \
  -l CLUSTER_LOCATION \
  -m upgrade \
  --enable_apis

Actualiza con un archivo superpuesto

En el siguiente ejemplo, se realiza una actualización y se incluye un archivo de superposición para personalizar la configuración del plano de control. En el siguiente comando, cambia OVERLAY_FILE por el nombre del archivo YAML.

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode upgrade \
  --enable_all \
  --custom_overlay OVERLAY_FILE

Opciones y marcas

En esta sección, se describen los argumentos disponibles para la secuencia de comandos.

Opciones

-p|--project_id CLUSTER_PROJECT_ID: El ID del proyecto en el que se creó el clúster.
-n|--cluster_name CLUSTER_NAME: Es el nombre del clúster.
-l|--cluster_location CLUSTER_LOCATION: Es la zona (para clústeres de una sola zona) o la región (para clústeres regionales) en la que se creó el clúster.
-m|--mode {install|migrate|upgrade}: Ingresa install si quieres instalar Anthos Service Mesh. Ingresa migrate si migras desde Istio. Ingresa upgrade para actualizar una instalación existente de Anthos Service Mesh a una versión nueva.
-c|--ca {mesh_ca|citadel}: En el caso de las instalaciones, si quieres usar la CA de Mesh, no tienes que incluir esta opción porque la secuencia de comandos predeterminada es la CA de Mesh. Para las actualizaciones, no necesitas incluir esta opción, ya que la secuencia de comandos no te permite cambiar la CA. En el caso de las migraciones, debes especificar citadel o mesh_ca. Si puedes programar el tiempo de inactividad para la migración, te recomendamos que uses mesh_ca. Para obtener más información sobre qué CA usar, consulta Elige una autoridad certificadora. Si deseas ver opciones adicionales que debes especificar cuando usas Citadel, consulta Opciones para un certificado personalizado para Citadel.
--co|--custom_overlay YAML_FILE: El nombre del archivo YAML de recurso personalizado (CR) IstioOperator para habilitar una característica que no está habilitada de forma predeterminada. La secuencia de comandos debe poder ubicar el archivo YAML, por lo que este debe estar en el mismo directorio que la secuencia de comandos, o puedes especificar una ruta de acceso relativa. Para agregar varios archivos, especifica --co|--custom_overlay y el nombre del archivo, por ejemplo: --co overlay_file1.yaml --co overlay_file2.yaml --co overlay_file3.yaml
-o|--option OPTION_FILE: El nombre de un archivo YAML del paquete anthos-service-mesh que contiene el CR IstioOperator para habilitar una característica opcional. Cuando incluyas uno de estos archivos, no necesitas descargar primero el paquete anthos-service-mesh ni especificar la extensión .yaml. Si necesitas modificar alguno de los archivos, descarga el paquete anthos-service-mesh, realiza los cambios y usa la opción --custom_overlay. Para agregar varios archivos, especifica -o|--option y el nombre del archivo, por ejemplo: -o option_file1 -o option_file2 -o option_file3
-s|--service_account ACCOUNT: El nombre de una cuenta de servicio que se usa para instalar Anthos Service Mesh. Si no se especifica, se usa la cuenta de usuario activa en la configuración de gcloud actual. Si necesitas cambiar la cuenta de usuario activa, ejecuta gcloud auth login.
-k|--key_file FILE_PATH: Es el archivo de claves de una cuenta de servicio. Omite esta opción si no usas una cuenta de servicio.
-D|--output_dir DIR_PATH: Si no se especifica, la secuencia de comandos crea un directorio temporal en el que descarga archivos y configuraciones necesarios para instalar Anthos Service Mesh. Especifica la marca --output-dir para designar un directorio existente que se usará en su lugar. Una vez completado, el directorio especificado contiene los subdirectorios asm y istio-1.7.8-asm.10. El directorio asm contiene la configuración de la instalación. El directorio istio-1.7.8-asm.10 tiene el contenido extraído del archivo de instalación, que contiene istioctl, muestras y manifiestos.

Marcas

-e|--enable_apis: Permite que la secuencia de comandos habilite las API de Google que requiere Anthos Service Mesh. Sin esta marca, la secuencia de comandos se cierra si las API necesarias no están habilitadas. Para obtener una lista de las API que habilita la secuencia de comandos, consulta set_up_project.
-v|--verbose: Imprime comandos antes y después de la ejecución.
--dry_run: Imprime comandos, pero no los ejecutes.
--only_validate: Ejecuta la validación, pero no instales Anthos Service Mesh.
--print_config: En lugar de instalar Anthos Service Mesh, imprime todos los YAML compilados en resultados estándar (stdout). Todos los demás resultados se escriben en error estándar (stderr), incluso si, por lo general, van con stdout. La secuencia de comandos omite todas las validaciones y la configuración cuando especificas esta marca.
--disable_canonical_service: De forma predeterminada, la secuencia de comandos implementa el controlador del servicio canónico en tu clúster. Si no deseas que la secuencia de comandos implemente el controlador, especifica --disable_canonical_service. Para obtener más información, consulta Habilita o inhabilita el controlador del servicio canónico.
-h|--help: Muestra un mensaje de ayuda que describe las opciones y las marcas, y se cierra.
--version: Imprime la versión de install_asm y se cierra. Si el comando no muestra una versión, descarga la versión más reciente de install_asm_1.7.

Opciones para un certificado personalizado para Citadel

Si especificaste citadel y usas una CA personalizada, incluye las siguientes opciones:

--ca_cert FILE_PATH: Es el certificado intermedio.
--ca_key FILE_PATH: Es la clave para el certificado intermedio.
--root_cert FILE_PATH: Es el certificado raíz.
--cert_chain FILE_PATH: Es la cadena de certificados.

Para obtener más información, consulta Conecta Certificados de CA existentes.

Implementa y vuelve a implementar las cargas de trabajo

La instalación no estará completa hasta que habilites la inserción automática de proxy de sidecar (inserción automática).

En las instalaciones nuevas, debes habilitar la inserción automática y reiniciar los pods de las cargas de trabajo que se estaban ejecutando en tu clúster antes de instalar Anthos Service Mesh.
Las migraciones y actualizaciones siguen el proceso de actualización del plano de control dual (denominado “actualizaciones canary” en la documentación de Istio). Con una actualización del plano de control dual, la secuencia de comandos instala una versión nueva de istiod junto con el istiod existente. Luego, transfiere algunas de las cargas de trabajo a la versión nueva. Este proceso te permite supervisar el efecto de la versión nueva con un pequeño porcentaje de las cargas de trabajo antes de migrar todo el tráfico a la versión nueva.
Antes de implementar las cargas de trabajo nuevas, asegúrate de habilitar la incorporación del proxy de sidecar para que Anthos Service Mesh pueda supervisar y asegurar el tráfico.

Para habilitar la inserción automática, debes obtener la etiqueta de revisión que la secuencia de comandos aplicó a istiod y etiquetar los espacios de nombres con la etiqueta de revisión. Se proporcionan detalles en las siguientes secciones.

Obtén la etiqueta de revisión

La secuencia de comandos agrega una etiqueta de revisión en el formato istio.io/rev=asm-178-10 a istiod. Para habilitar la inserción automática, agrega una etiqueta de revisión coincidente a tus espacios de nombres. El webhook de inyector de sidecar usa la etiqueta de revisión para asociar los sidecars insertados con una revisión istiod particular. Después de agregar la etiqueta, los pods existentes en el espacio de nombres deben reiniciarse para que se incorporen los archivos adicionales.

Establece el contexto actual para kubectl:
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --project=PROJECT_ID
```
Nota: A menos que hayas configurado una zona o región predeterminada, debes proporcionar la región (--region=REGION) o la zona (--zone=ZONE) en el comando.
Muestra las etiquetas en istiod para obtener la etiqueta de revisión establecida por la secuencia de comandos:
```
kubectl -n istio-system get pods -l app=istiod --show-labels
```
El resultado del comando es similar al siguiente: Ten en cuenta que el resultado de las instalaciones, migraciones y actualizaciones nuevas es un poco diferente. El siguiente resultado de ejemplo es de una migración.
```
NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-7744bc8dd7-qhlss             1/1     Running   0          49m   app=istiod,istio.io/rev=default,istio=pilot,pod-template-hash=7744bc8dd7
istiod-asm-178-10-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-178-10-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-178-10,istio=istiod,pod-template-hash=85d86774f7
```
En el resultado, en la columna LABELS, observa el valor de la etiqueta de revisión istiod, que está después del prefijo istio.io/rev=. En este ejemplo, el valor es asm-178-10, pero puedes tener un valor diferente.

Para las actualizaciones y migraciones, también toma nota del valor en la etiqueta de revisión de la versión istiod anterior. Necesitas esto para borrar la versión anterior de istiod cuando termines la migración o actualización. En el resultado de ejemplo, el valor en la etiqueta de revisión de la versión anterior de istiod es default, pero puedes tener un valor diferente.

Habilita la inserción automática

Sigue estos pasos para las instalaciones, migraciones y actualizaciones nuevas a fin de habilitar la inserción automática.

Obtén el valor en la etiqueta de revisión para istiod.
Agrega la etiqueta de revisión a un espacio de nombres y quita la etiqueta istio-injection. En el siguiente comando, cambia REVISION por el valor que coincide con la revisión en istiod.
```
kubectl label namespace NAMESPACE istio.io/rev=REVISION istio-injection- --overwrite
```

Reinicia los Pods para activar la reinserción:

kubectl rollout restart deployment -n NAMESPACE

Verifica que tus pods estén configurados para apuntar a la nueva versión de istiod.
```
kubectl get pods -n NAMESPACE -l istio.io/rev=REVISION
```
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.

Para la migración y actualizaciones, sigue estos pasos:

Si estás seguro de que tu aplicación funciona como se esperaba, avanza la siguiente sección para completar la transición a la versión nueva de istiod.
Si hay un problema con tu aplicación, sigue los pasos en Realiza una reversión a la versión anterior.

Completa la transición

Para las migraciones y actualizaciones, debes quitar la versión anterior de istiod. 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.

Obtén el valor en la etiqueta de revisión para la versión anterior de istiod.
Borra la versión anterior de istiod. En el siguiente comando, reemplaza OLD_REVISION por la revisión del paso anterior.
```
kubectl delete Service,Deployment,HorizontalPodAutoscaler,PodDisruptionBudget istiod-OLD_REVISION  -n istio-system --ignore-not-found=true
```
Importante: Si migraste desde el complemento Istio on GKE, debes mantener habilitado el complemento en el clúster. Si inhabilitas el complemento, se borrará el espacio de nombres istio-system y todos los recursos que contenga.

Realiza una reversión a la versión anterior

En las migraciones y actualizaciones, si encontraste un problema cuando probaste tu aplicación con la versión nueva de istiod, sigue estos pasos para revertir a la versión anterior:

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

Vuelve a implementar la versión anterior de istio-ingressgateway:

kubectl -n istio-system rollout undo deploy istio-ingressgateway

Quita el nuevo istiod:

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

Si no incluiste la marca --disable_canonical_service, la secuencia de comandos habilitó el controlador del servicio canónico. Sigue los pasos en Habilita o inhabilita el controlador del servicio canónico para inhabilitarla.

Reinstalar la misma versión

La secuencia de comandos install_asm llama a istioctl install a fin de implementar los componentes del plano de control de Anthos Service Mesh (istiod y istio-ingressgateway) para las instalaciones, las actualizaciones y las migraciones de Istio. Dado que la secuencia de comandos usa istioctl install, si necesitas personalizar Anthos Service Mesh para habilitar una función opcional, deberás reinstalar el plano de control con la nueva configuración.

Se realizó un cambio en la secuencia de comandos install_asm para que puedas reinstalar la misma versión de Anthos Service Mesh. Cuando reinstalas la misma versión para habilitar una función opcional, se reemplaza la configuración del plano de control existente. Debido a esto, si personalizaste la instalación existente, debes incluir las mismas opciones de --option o --custom_overlay de la instalación anterior y las --option o --custom_overlay para las funciones que deseas habilitar.

Ten en cuenta que, si habilitas Cloud Trace o cambias una configuración de seguimiento, también debes volver a implementar cargas de trabajo para que los proxies de sidecar se vuelven a incorporar con la configuración del plano de control actualizada.

Cuando vuelves a instalar la misma versión, especificas --mode install como en las instalaciones. Para obtener información sobre la instalación mediante la secuencia de comandos, consulta Instala Anthos Service Mesh.

Si especificas más de un recurso personalizado (CR) IstioOperator en un archivo YAML, install_asm divide el archivo en varios archivos YAML temporales, uno para cada CR. La secuencia de comandos divide los CR en archivos separados porque istioctl install solo aplica el primer CR en un archivo YAML que contiene más de un CR.

Visualiza los paneles de Anthos Service Mesh

Después de implementar las cargas de trabajo en el clúster con los proxies de sidecar incorporados, puedes explorar las páginas de Anthos Service Mesh en la consola de Google Cloud para ver todas las funciones de observabilidad que ofrece Anthos Service Mesh. Ten en cuenta que los datos de telemetría toman uno o dos minutos en aparecer en la consola de Google Cloud después de implementar las cargas de trabajo.

El acceso a Anthos Service Mesh en la consola de Google Cloud se controla mediante la Administración de identidades y accesos (IAM). Para acceder a las páginas de Anthos Service Mesh, el propietario del proyecto debe otorgar a los usuarios la función de editor o visualizador del proyecto, o los roles más restrictivas que se describen en Controla el acceso a Anthos Service Mesh en la consola de Google Cloud.

En la consola de Google Cloud, ve a Anthos Service Mesh.

Ir a Anthos Service Mesh
Selecciona el proyecto de Google Cloud en la lista desplegable de la barra de menú.
Si tienes más de una malla de servicios, selecciona la malla en la lista desplegable Malla de servicios.

Para obtener más información, consulta Explora Anthos Service Mesh en la consola de Google Cloud.

Además de las páginas de Anthos Service Mesh, las métricas relacionadas con tus servicios (como la cantidad de solicitudes que recibe un servicio específico) se envían a Cloud Monitoring, donde aparecen en el Explorador de métricas.

Para ver las métricas, sigue estos pasos:

En la consola de Google Cloud, ve a la página Monitoring.

Ir a Monitoring
Selecciona Recursos > Explorador de métricas.

Para obtener una lista completa de las métricas, consulta Métricas de Istio en la documentación de Cloud Monitoring.

Registra tu clúster

Debes registrar tu clúster en la flota del proyecto para obtener acceso a la interfaz de usuario unificada en la consola de Google Cloud. Una flota proporciona una forma unificada de ver y administrar los clústeres y sus cargas de trabajo, incluidos los clústeres fuera de Google Cloud.

A fin de obtener información para registrar tu clúster, consulta Registra clústeres en la flota.

Información sobre la secuencia de comandos

Aunque descargues la secuencia de comandos desde una ubicación segura de Cloud Source Repositories, la secuencia de comandos también está disponible en GitHub para que puedas ver lo que hace antes de descargarla. La secuencia de comandos valida que tu clúster cumpla con los requisitos y automatiza todos los pasos que harías de manera manual en Instala Anthos Service Mesh en GKE.

Con Anthos Service Mesh 1.7.8, debes usar la versión de la secuencia de comandos install_asm en la rama release-1.7-asm. Para obtener una explicación del control de versiones y el proceso de lanzamiento, consulta Control de versiones y versiones.

`validate_args` y `validate_dependencies`

validate_args() {
  if [[ "${MODE}" == "install" && -z "${CA}" ]]; then
    CA="mesh_ca"
  fi

  local MISSING_ARGS=0
  while read -r REQUIRED_ARG; do
    if [[ -z "${!REQUIRED_ARG}" ]]; then
      MISSING_ARGS=1
      warn "Missing value for ${REQUIRED_ARG}"
    fi
    readonly "${REQUIRED_ARG}"
  done <<EOF

validate_dependencies() {
  validate_cli_dependencies
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi

  validate_gcp_resources
  # configure kubectl does have side effects but we've generated a temprorary
  # kubeconfig so we're not breaking the promise that --only_validate gives
  configure_kubectl
  validate_k8s
  validate_expected_control_plane

  if [[ "${MODE}" = "migrate" ]]; then
    validate_istio_version
  elif [[ "${MODE}" = "upgrade" ]]; then
    validate_asm_version
    validate_ca_consistency
  fi

  if [[ "${ENABLE_APIS}" -eq 0 || "${ONLY_VALIDATE}" -eq 1 ]]; then
    exit_if_apis_not_enabled
  fi
}

Las funciones validate_args y validate_dependencies realizan las siguientes funciones:

Verifican que estén instaladas todas las herramientas necesarias.
Verifican que el ID del proyecto, el nombre del clúster y la ubicación del clúster que ingresaste como valores de parámetros sean válidos.
Garantizan que el clúster cumpla con el tipo de máquina mínimo requerido y la cantidad de nodos.

`set_up_project`

Si incluiste la marca --enable_apis, la función set_up_project habilita las API necesarias:

required_apis() {
    cat << EOF
container.googleapis.com
compute.googleapis.com
monitoring.googleapis.com
logging.googleapis.com
cloudtrace.googleapis.com
meshca.googleapis.com
meshtelemetry.googleapis.com
meshconfig.googleapis.com
iamcredentials.googleapis.com
gkeconnect.googleapis.com
gkehub.googleapis.com
cloudresourcemanager.googleapis.com
stackdriver.googleapis.com
EOF
}

`set_up_cluster`

set_up_cluster(){
  if [[ "${PRINT_CONFIG}" -eq 1 ]]; then
    return 0
  fi
  add_cluster_labels
  enable_workload_identity

  init_meshconfig

  enable_stackdriver_kubernetes
  bind_user_to_cluster_admin
  ensure_istio_namespace_exists
}

La función set_up_cluster realiza las siguientes actualizaciones en el clúster:

Habilita Workload Identity, que es la forma recomendada para acceder de forma segura a los servicios de Google Cloud desde las aplicaciones de GKE.
Habilita Cloud Monitoring y Cloud Logging en GKE.
Configura la etiqueta mesh_id en el clúster, que se requiere para que las métricas se muestren en las páginas de Anthos Service Mesh en la consola de Google Cloud.
Establece una etiqueta como asmv=asm-178-10 para que puedas saber si la secuencia de comandos modificó el clúster.
Vincula la cuenta de servicio o el usuario de GCP que ejecuta la secuencia de comandos a la función de administrador del clúster en tu clúster.

`install_asm`

install_asm() {

  local PARAMS
  PARAMS="-f ${OPERATOR_MANIFEST} -f ${MULTICLUSTER_MANIFEST}"
  while read -d ',' -r yaml_file; do
    PARAMS="${PARAMS} -f ${yaml_file}"
  done <<EOF

La función install_asm realiza lo siguiente:

Descarga el paquete kpt en un directorio temporal.
Ejecuta los métodos set de kpt para configurar el archivo istio-operator.yaml.
Instala Anthos Service Mesh.