Instala Anthos Service Mesh

En esta página, se explica cómo ejecutar la secuencia de comandos a fin de instalar la versión 1.8.6 de Anthos Service Mesh en un clúster de GKE para una malla que contiene uno o más clústeres que se encuentran en el mismo proyecto de Google Cloud.

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.

Esta página está destinada a instalaciones de Anthos Service Mesh: para nuevas instalaciones o para volver a instalar la misma versión con otra configuración.

Si bien la secuencia de comandos para las instalaciones nuevas es similar en las reinstalaciones de la misma versión, las actualizaciones y las migraciones de Istio, esos casos de uso implican una planificación adicional. Para obtener más información, consulta las siguientes páginas:

Antes de comenzar

Antes de comenzar la instalación, asegúrate de haber hecho lo siguiente:

La secuencia de comandos requiere que tengas los permisos necesarios o que incluyas las marcas --enable_all o --enable_gcp_iam_roles para permitir que la secuencia de comandos habilite el permiso para ti. Del mismo modo, para permitir que la secuencia de comandos habilite las API requeridas y actualice el clúster, especifique la marca --enable_all o más marcas de habilitación más detalladas.

Instala Anthos Service Mesh

  1. 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 install. Si quieres usar Citadel como la CA, debes especificar la opción --ca y algunas otras opciones, como se describe en Instalación con Citadel como CA. Para obtener una descripción completa de los argumentos de la secuencia de comandos, consulta Opción y marcas.

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

En la siguiente sección, se proporcionan ejemplos típicos de la ejecución de la secuencia de comandos. Consulta la barra de navegación de la derecha para ver una lista de los ejemplos.

Ejemplos

En esta sección, se muestran ejemplos sobre cómo ejecutar la secuencia de comandos para una instalación con 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 proyecto o clúster y no instala Anthos Service Mesh. Cuando especificas --only_validate, la secuencia de comandos falla si incluyes alguna de las marcas --enable_*.

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 run
the script with the '--enable_gcp_apis' flag to allow the script to enable them
on your behalf.

Si recibiste un mensaje de error sobre la necesidad de ejecutar la secuencia de comandos con una marca de habilitación, puedes incluir la marca específica del mensaje de error o la marca --enable_all cuando se ejecuta la secuencia de comandos sin --only_validate. Si lo prefieres, puedes actualizar tu proyecto y clúster antes de ejecutar la secuencia de comandos como se describe en las secciones Configura tu proyecto y Configura tu clúster de la guía de instalación de varios proyectos.

Instalación

El siguiente comando ejecuta la secuencia de comandos para una instalación nueva, habilita la CA de Mesh, que es la CA predeterminada para las instalaciones, por lo que no necesitas la opción --ca en este caso. La marca --enable_all permite que la secuencia de comandos habilite las API de Google obligatorias, configure los permisos de Identity and Access Management, y realice las actualizaciones necesarias en tu clúster, que incluye habilitar Workload Identity de GKE.

Si planeas usar la CA de Mesh, puedes usar el grupo de identidad de carga de trabajo de la flota como una alternativa a la identidad de la carga de trabajo de GKE. Para ver un ejemplo, consulta Habilita la CA de Mesh con el grupo de identidad de la carga de trabajo de la flota.

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

También puedes incluir lo siguiente:

  • --output_dir DIR_PATH Si no ejecutaste el ejemplo Solo validar, incluye esta opción para especificar un directorio existente en el que la secuencia de comandos descarga el paquete asm y el archivo de instalación de Anthos Service Mesh, que contiene istioctl, muestras y manifiestos. De lo contrario, la secuencia de comandos descarga el paquete asm y el archivo de instalación en un directorio temporal.

  • --enable-registration Esta marca permite que la secuencia de comandos registre el clúster en el proyecto en el que este se encuentra. Si no incluyes esta marca, sigue los pasos en Registra un clúster para registrarlo de forma manual.

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.

  1. Crea un directorio para los certificados y las claves:

    mkdir -p certs && \
    pushd certs
  2. 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
  3. 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

    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.

  4. 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_all \
  --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_all \
  --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.8-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.

Habilita la CA de Mesh con la flota

La vista previa de la CA de Mesh en la flota está limitada a las nuevas instalaciones de Anthos Service Mesh en GKE. Las actualizaciones y migraciones no son compatibles durante la vista previa.

En este ejemplo, se muestra cómo habilitar la CA de Mesh para usar el grupo de identidad de carga de trabajo de la flota. La CA de Mesh de la flota te permite unir clústeres en proyectos de Google Cloud separados a un solo dominio de confianza, que corresponde a la flota.

Para habilitar la CA de Mesh con la flota, sigue estos pasos:

Si aún no registraste tu clúster, asegúrate de incluir la marca --enable-registration, como se muestra en el siguiente ejemplo:

./install_asm \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --mode install \
  --enable_all \
  --enable-registration \
  --option hub-meshca

Este comando ejecuta la secuencia de comandos para una instalación nueva, configura tu proyecto y clúster con las opciones que requiere Anthos Service Mesh, registra el clúster en el proyecto en el que se encuentra el clúster y configura la CA de Mesh para que use la flota de identidad de carga de trabajo de ejecución.

Implementa y vuelve a implementar las cargas de trabajo

Anthos Service Mesh usa proxies de sidecar para mejorar la seguridad, confiabilidad y observabilidad de la red. Con Anthos Service Mesh, estas funciones se abstraen del contenedor principal de la aplicación y se implementan en un proxy común fuera del proceso, que se entrega como un contenedor separado en el mismo pod.

La instalación no se completará hasta que habilites la inserción automática de proxy de sidecar y reinicies los Pods para las cargas de trabajo que se estaban ejecutando en tu clúster antes de instalar Anthos Service Mesh.

Para habilitar la inserción automática, debes etiquetar tus espacios de nombres con la etiqueta de revisión que se estableció en istiod cuando instalaste Anthos Service Mesh. 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 al espacio de nombres deben reiniciarse para que se incorporen los archivos adicionales.

Antes de implementar cargas de trabajo nuevas en un espacio de nombres nuevo, asegúrate de configurar la inserción automática para que Anthos Service Mesh pueda supervisar y proteger el tráfico.

Para habilitarla, usa este comando:

  1. Usa el siguiente comando para encontrar la etiqueta de revisión en istiod:

    kubectl -n istio-system get pods -l app=istiod --show-labels
    

    El resultado es similar al siguiente:

    NAME                                READY   STATUS    RESTARTS   AGE   LABELS
    istiod-asm-186-8-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586
    istiod-asm-186-8-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-186-8,istio=istiod,pod-template-hash=5788d57586

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

  2. Aplica la etiqueta de revisión y quita la etiqueta istio-injection si existe. En el siguiente comando, NAMESPACE es el nombre del espacio de nombres en el que deseas habilitar la inserción automática y REVISION es la etiqueta de revisión que anotaste en el paso anterior.

    kubectl label namespace NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
    

    Puedes ignorar el mensaje "istio-injection not found" en el resultado. Esto significa que el espacio de nombres no tenía la etiqueta istio-injection, que debería aparecer en las nuevas instalaciones de Anthos Service Mesh o en implementaciones nuevas. Debido a que la inserción automática falla si un espacio de nombres tiene tanto la istio-injection como la etiqueta de revisión, todos los comandos kubectl label de la documentación de Anthos Service Mesh incluyen la acción de quitar la etiqueta istio-injection.

  3. Si las cargas de trabajo se estaban ejecutando en tu clúster antes de instalar Anthos Service Mesh, reinicia los Pods para activar la reinserción.

    La forma de reiniciar los pods depende de tu aplicación y del entorno en el que se encuentra el clúster. Por ejemplo, en el entorno de etapa de pruebas, puedes borrar todos los pods, lo que hace que se reinicien. Sin embargo, en tu entorno de producción, es posible que tengas un proceso que implemente una implementación azul-verde para que puedas reiniciar los pods de forma segura y evitar la interrupción del tráfico.

    Puedes usar kubectl para realizar un reinicio progresivo:

    kubectl rollout restart deployment -n NAMESPACE
    
  4. 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
    

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.

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

    Ir a Anthos Service Mesh

  2. Selecciona el proyecto de Google Cloud de la lista desplegable de la barra de menú.

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

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

    Ir a Monitoring

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

¿Qué sigue?