Agrega máquinas virtuales de Compute Engine a Anthos Service Mesh

En esta página, se describe cómo agregar máquinas virtuales (VM) de Compute Engine a Anthos Service Mesh en Google Kubernetes Engine (GKE). En esta página, se muestra cómo instalar 1.11.8 de Anthos Service Mesh con la opción que prepara el clúster para agregar una VM.

  • Si ya instalaste Anthos Service Mesh 1.9 or a 1.10 patch release, en esta página se muestra cómo actualizar a Anthos Service Mesh 1.11.8 con la opción necesaria para agregar una VM.

  • Si tienes Anthos Service Mesh 1.9 y no deseas actualizar, consulta la guía de Anthos Service Mesh 1.9 para obtener instrucciones sobre cómo agregar VM a Anthos Service Mesh 1.9.

  • Si tienes una versión anterior de Anthos Service Mesh, primero debes actualizar Anthos Service Mesh a 1.9 o una versión posterior.

En esta página, se proporciona la línea de comandos para instalar el plano de control en el clúster o el plano de control administrado por Google.

Introducción

Anthos Service Mesh te permite administrar, observar y proteger los servicios que se ejecutan en grupos de instancias administrados (MIG), junto con los servicios que se ejecutan en los clústeres de Google Kubernetes Engine (GKE) en el malla. Esto te permite hacer lo siguiente con las instancias de Compute Engine en tu malla:

  • Administrar el tráfico
  • Aplicar la mTLS.
  • Aplicar el control de acceso al tráfico del servicio.
  • Acceder de forma segura a los servicios de Google Cloud
  • Recopilar métricas, registros y datos de seguimiento
  • Supervisar los servicios con Google Cloud Console.

Esto permite que las aplicaciones heredadas que no sean adecuadas o que no estén listas para el uso de contenedores aprovechen las características de Anthos Service Mesh y permite integrar esas cargas de trabajo con el resto de tus servicios.

Cómo funciona

Anthos Service Mesh proporciona dos definiciones de recursos personalizadas (CRD) relacionadas para representar cargas de trabajo de máquinas virtuales:

  • WorkloadGroup representa un grupo lógico de cargas de trabajo de máquinas virtuales que tienen propiedades comunes. Esto es similar a una implementación en Kubernetes.
  • WorkloadEntry representa una instancia única de una carga de trabajo de máquina virtual. Esto es similar a un Pod en Kubernetes.
  • Un Service puede seleccionar el WorkloadGroup y hacer que Anthos Service Mesh enrute el tráfico a la instancia de VM de manera similar a un Pod. Esto permite que la VM actúe como cualquier otra carga de trabajo en la malla.

Debes crear una plantilla de instancias de Compute Engine para cada grupo de instancias de Compute Engine, que especifican un agente de proxy de servicio para cada instancia de Compute Engine en ese grupo. Durante la instalación, el agente inicia el proxy de servicio, configura la interceptación de tráfico y supervisa el estado del proxy de servicio durante la vida útil de la instancia de Compute Engine. El proxy se conecta con el plano de control de Anthos Service Mesh y, luego, registra de forma automática cada instancia de Compute Engine como una WorkloadEntry para el WorkloadGroup correspondiente. Esto permite que Anthos Service Mesh trate cada instancia como un extremo de servicio, como los pods de Kubernetes en el clúster. También puedes crear servicios de Kubernetes para cargas de trabajo de VM, como lo harías con los pods de Kubernetes.

Para escalar horizontalmente la cantidad de cargas de trabajo en las instancias de Compute Engine, a partir de un tamaño de MIG mínimo de cero, consulta Aplica el ajuste de escala automático en grupos de instancias.

El agente de proxy de servicio se basa en VM Manager para garantizar que el agente se instale en cada VM en el MIG. Para obtener más información sobre los grupos de instancias y la administración de VM, consulta Grupo de instancias administrado (MIG) y VM Manager.

Distribuciones de Linux compatibles

Versión del SO con asistencia
Debian 10
Debian 9
Centos 8
Centos 7

Consulta la compatibilidad con Debian o la compatibilidad con CentOS para obtener más información sobre las distribuciones de SO.

Limitaciones

  • El plano de control de la malla debe ser Anthos Service Mesh 1.9 o superior.
  • Solo se admiten los grupos de instancias administrados de Compute Engine creados a partir de una plantilla de instancias de Compute Engine.
  • El clúster y las VM deben estar en la misma red, en el mismo proyecto y usar una sola interfaz de red.
  • Puedes usar esta característica sin una suscripción a Anthos, pero ciertos elementos de la IU y las funciones de Google Cloud Console solo están disponibles para los suscriptores de Anthos. Si quieres obtener información sobre lo que está disponible para suscriptores y no suscriptores, consulta las diferencias en la IU de Anthos Service Mesh y Anthos.
  • Aunque puedes implementar el plano de control administrado por Google y el plano de datos administrado por Google en tu clúster, el plano de datos administrado por Google no administra los proxies en las VM.

Prerequisites

Antes de comenzar:

Revisa el proyecto de Cloud, las licencias de Anthos y los requisitos generales que se describen en Requisitos previos.

Requisitos del clúster

Antes de continuar, asegúrate de que tu clúster cumpla con los requisitos de GKE. Además, la compatibilidad con VM de Anthos Service Mesh requiere lo siguiente:

  • Especifica la CA de Mesh como la autoridad certificada (CA) cuando instalas Anthos Service Mesh.
  • No anulas Stackdriver para la telemetría. Stackdriver se configura de forma predeterminada cuando instalas Anthos Service Mesh.
  • El clúster está registrado en una flota. Sin embargo, si el clúster no está registrado, el proceso de instalación de la VM registra el clúster en el proyecto que especificaste.

Comenzar

Sigue los pasos que se indican en Comenzar para hacer lo siguiente:

Si no tienes instalado Anthos Service Mesh, continúa con la siguiente sección. Si tienes una instalación de Anthos Service Mesh existente, sigue los pasos en Instalaciones existentes.

Nueva instalación

Prepara el clúster de Anthos Service Mesh para VM mediante la preparación del plano de control de 1.11 Anthos Service Mesh o una versión posterior. El comando que ejecutes depende del tipo de plano de control de Anthos Service Mesh que desees instalar en el clúster.

En el clúster

Con el siguiente comando, se muestra cómo instalar el plano de control en el clúster de Anthos Service Mesh con --option vm que prepara el plano de control para agregar VM.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm
  • --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.
  • --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í.
  • --enable_all Permite que la secuencia de comandos haga lo siguiente:
    • 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 Mesh como autoridad certificada. asmcli configura la CA de Mesh para que use identidad de carga de trabajo de flota.
  • --option vm Prepara el clúster para incluir una VM en la malla de servicios.

Si tienes cargas de trabajo existentes que se ejecutan en el clúster, vuelve a implementar las cargas de trabajo y, luego, regresa a esta página para agregar tus VM.

Malla de servicios administrados

En el siguiente comando, se muestra cómo implementar el plano de control administrado por Google de Anthos Service Mesh con --option vm que prepara el plano de control para agregar las VM. Para obtener más información sobre otras opciones disponibles, consulta Aplica el plano de control administrado por Google. Aunque la documentación de Anthos Service Mesh administrada usa la secuencia de comandos install_asm en lugar de asmcli install, las opciones se especifican de la misma manera con ambas secuencias de comandos de instalación.

./asmcli install \
  --project_id PROJECT_ID \
  --cluster_name CLUSTER_NAME \
  --cluster_location CLUSTER_LOCATION \
  --output_dir DIR_PATH \
  --enable_all \
  --ca mesh_ca \
  --option vm \
  --managed
  • --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.
  • --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í.
  • --enable_all Permite que la secuencia de comandos haga lo siguiente:
    • 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 Mesh como autoridad certificada. asmcli configura la CA de Mesh para que use identidad de carga de trabajo de flota.
  • --option vm Prepara el clúster para incluir una VM en la malla de servicios.
  • --managed Implementa el plano de control administrado por Google.

Instalaciones existentes

Si ya se instaló Anthos Service Mesh en tu clúster, haz lo siguiente:

  1. Registra tu clúster en la flota si aún no lo hiciste.

  2. Ejecuta el siguiente comando a fin de preparar y verificar que la instalación de Anthos Service Mesh esté lista para las cargas de trabajo de VM. Debes ejecutar el mismo comando para los planos de control administrados por Google y en el clúster.

    ./asmcli experimental vm prepare-cluster \
    --project_id PROJECT_ID \
    --cluster_name CLUSTER_NAME \
    --cluster_location CLUSTER_LOCATION

    Si se ejecuta de forma correcta, el resultado del comando es el siguiente:

    The cluster is ready for adding VM workloads.
Please follow the Anthos Service Mesh for Compute Engine VM user guide to add
Compute Engine VMs to your mesh.

El comando realiza lo siguiente:

En el clúster

  1. Habilita el registro automático de VM. Para ello, se configuran las variables PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION y PILOT_ENABLE_CROSS_CLUSTER_WORKLOAD_ENTRY como verdaderas. Cuando esta función esté habilitada, las instancias de VM nuevas se registrarán con el WorkloadGroup y se crearán nuevas CR WorkloadEntry para enrutar el tráfico a las VM. Todos los planos de control de Anthos Service Mesh 1.9 o de versiones posteriores instalados con asmcli tendrán el registro automático de VM habilitado de forma predeterminada.

  2. Instalar una puerta de enlace de expansión: esta puerta de enlace se llama eastwest y se define en el paquete de configuración de Anthos Service Mesh. Esto también expondrá el plano de control a las VM.

  3. Instalar la CRD IdentityProvider y registrar una CR IdentityProvider de Google para permitir que las VM se autentiquen en el plano de control de Anthos Service Mesh y se comuniquen de forma segura con el resto de la malla de servicios.

  4. Registrar el clúster en una flota y habilitar Workload Identity si usas --enable_all o --enable_registration en la secuencia de comandos asmcli.

  5. Habilitar la función Service Mesh en la flota. Esta función administrará las políticas necesarias para permitir que las VM se comuniquen de forma segura con la malla.

Malla de servicios administrados

  1. Habilitar el registro automático de VM: todos los planos de control administrados por Google de Anthos Service Mesh tendrán habilitado el registro automático de VM de forma predeterminada.

  2. Instalar la CRD IdentityProvider y registrar una CR IdentityProvider de Google para permitir que las VM se autentiquen en el plano de control de Anthos Service Mesh y se comuniquen de forma segura con el resto de la malla de servicios.

  3. Registrar el clúster en una flota y habilitar Workload Identity si usas --enable_all o --enable_registration en la secuencia de comandos asmcli.

  4. Habilitar la función Service Mesh en la flota. Esta función administrará las políticas necesarias para permitir que las VM se comuniquen de forma segura con la malla.

Instala puertas de enlace de entrada

Anthos Service Mesh te brinda la opción de implementar y administrar puertas de enlace como parte de tu malla de servicios. Una puerta de enlace describe un balanceador de cargas que opera en el perímetro de la malla que recibe conexiones HTTP/TCP entrantes o salientes. Las puertas de enlace son proxies de Envoy que te brindan un control detallado sobre el tráfico que entra y sale de la malla.

  1. Crea un espacio de nombres para la puerta de enlace de entrada si aún no tienes uno. Las puertas de enlace son cargas de trabajo de usuarios y, como práctica recomendada, no deben implementarse en el espacio de nombres del plano de control. Reemplaza GATEWAY_NAMESPACE por el nombre de tu espacio de nombres.

    kubectl create namespace GATEWAY_NAMESPACE

  2. Habilita la inserción automática en la puerta de enlace mediante la aplicación de una etiqueta de revisión en el espacio de nombres de la puerta de enlace. El webhook de inyector de sidecar usa la etiqueta de revisión para asociar los proxies insertados con una revisión de plano de control en particular. La etiqueta de revisión que uses depende de si implementaste Anthos Service Mesh o el plano de control en el clúster.

    En el clúster

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

      kubectl get deploy -n istio-system -l app=istiod -o \
  jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'

    2. Aplica la etiqueta de revisión a los espacios de nombres. En el siguiente comando, REVISION es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.

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

    Malla de servicios administrados

    Aplica la etiqueta de revisión asm-managed al espacio de nombres:

    kubectl label namespace GATEWAY_NAMESPACE \
  istio-injection- istio.io/rev=asm-managed --overwrite

    Esta etiqueta corresponde al canal de versiones administrado de Anthos Service Mesh correspondiente a la versión de Anthos Service Mesh.

    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. Puedes implementar la configuración de la puerta de enlace de entrada de ejemplo que se ubica en el directorio samples/gateways/istio-ingressgateway/ tal como está o modificarla según sea necesario.

    kubectl apply -n GATEWAY_NAMESPACE \
  -f DIR_PATH/samples/gateways/istio-ingressgateway

Obtén más información sobre las prácticas recomendadas para las puertas de enlace.

Agrega tus VM

En esta sección, agregarás instancias de Compute Engine a tu malla en función de la plantilla de instancias que creas con gcloud. gcloud solo genera la configuración necesaria para el agente del proxy de servicio. Con el fin de incluir más opciones de configuración en la plantilla de instancias, usa la guía de referencia de gcloud a fin de obtener más información.

Para agregar VM a tu malla, sigue estos pasos:

  1. Configura las siguientes variables de entorno para usarlas en pasos posteriores. Configura estas variables para cada carga de trabajo de VM:

    • WORKLOAD_NAME es el nombre de la carga de trabajo de la que forma parte la VM, que debe ser un subdominio DNS-1123 compatible que contenga caracteres alfanuméricos en minúscula.
    • WORKLOAD_VERSION es la versión de la carga de trabajo de la que forma parte la VM. Opcional.
    • WORKLOAD_SERVICE_ACCOUNT es la cuenta de servicio de GCP que ejecuta la VM.
    • WORKLOAD_NAMESPACE es el espacio de nombres de la carga de trabajo.
    • ASM_INSTANCE_TEMPLATE es el nombre de la plantilla de instancias que se creará. El nombre de la plantilla de instancias de Compute Engine no permite guiones bajos.

  2. Crea el espacio de nombres para las cargas de trabajo de la VM si aún no existe:

    kubectl create ns WORKLOAD_NAMESPACE

  3. Etiqueta el espacio de nombres con la revisión del plano de control.

    En el clúster

    Para ver un ejemplo de cómo encontrar la revisión del plano de control que se muestra como REVISION en el siguiente ejemplo, consulta Implementa y vuelve a implementar las cargas de trabajo.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite

    Malla de servicios administrados

    Para ver un ejemplo de cómo configurar la revisión asm-managed en el siguiente ejemplo, consulta Implementa aplicaciones.

    kubectl label ns WORKLOAD_NAMESPACE istio-injection- istio.io/rev=asm-managed --overwrite

  4. Crea el WorkloadGroup para que se registren las VM:

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: WORKLOAD_NAME
  namespace: WORKLOAD_NAMESPACE
spec:
  metadata:
    labels:
      app.kubernetes.io/name: WORKLOAD_NAME
      app.kubernetes.io/version: WORKLOAD_VERSION
    annotations:
      security.cloud.google.com/IdentityProvider: google
  template:
    serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF
    Campo Descripción
    name El nombre de la carga de trabajo de la que forma parte la VM.
    namespace El espacio de nombres del que forma parte la carga de trabajo.
    app.kubernetes.io/name Las etiquetas recomendadas para aplicaciones de Kubernetes. Puedes usar tus propias etiquetas para las cargas de trabajo de VM.
    app.kubernetes.io/version Las etiquetas recomendadas para aplicaciones de Kubernetes. Puedes usar tus propias etiquetas para las cargas de trabajo de VM.
    serviceAccount La identidad de la cuenta de servicio que usan la VM y el proyecto, que se usará como parte de la identidad de la carga de trabajo en el formato SPIFFE. Para obtener más información, consulta Cuentas de servicio.
    security.cloud.google.com/IdentityProvider El proveedor de identidad que usará la VM, que ya debería estar registrado en el clúster. Para las VM de Compute Engine, debe configurarse como google. El IdentityProvider le indica al plano de control cómo autenticar la credencial de la VM y dónde extraer la cuenta de servicio de la VM.

  5. Usa el comando gcloud beta compute instance-templates create con la marca --mesh a fin de crear una plantilla de instancias para las instancias de Compute Engine de Anthos Service Mesh.

    gcloudverifica los requisitos previos del clúster, agrega etiquetas de VM para Anthos Service Mesh, genera la configuración de metadatos personalizados para el agente del proxy de servicio y crea una plantilla de instancias nueva.

    Si tu plantilla de instancias existente incluye una secuencia de comandos de inicio que requiere conectividad de red, la secuencia de comandos debe ser resistente a los problemas de conectividad de red transitorios. Consulta la aplicación de demostración para ver un ejemplo de cómo agregar resiliencia a la interrupción de red temporal.

    Para obtener más información sobre cómo crear plantillas de instancias, consulta Crea plantillas de instancias.

    gcloud beta compute instance-templates create \
ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  6. Configura las siguientes variables de entorno para cada MIG que crees:

    • INSTANCE_GROUP_NAME es el nombre del grupo de instancias de Compute Engine que se creará.
    • ASM_INSTANCE_TEMPLATE es el nombre de la plantilla de instancias que se creará. El nombre de la plantilla de instancias de Compute Engine no permite guiones bajos.
    • INSTANCE_GROUP_ZONE es la zona del grupo de instancias de Compute Engine que se creará.
    • PROJECT_ID es el ID del proyecto en el que se creó el clúster.
    • SIZE es el tamaño del grupo de instancias que se creará. Se puede cambiar después de crear el grupo de instancias.
    • WORKLOAD_NAME es el nombre de la carga de trabajo de la que forma parte la VM.
    • WORKLOAD_NAMESPACE es el espacio de nombres de la carga de trabajo.

  7. Crea un grupo de instancias administrado para las cargas de trabajo de VM con las variables creadas en los pasos anteriores:

    gcloud compute instance-groups managed create INSTANCE_GROUP_NAME \
--template ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE \
--project=PROJECT_ID \
--size=SIZE

    Para escalar horizontalmente la cantidad de cargas de trabajo en las instancias de Compute Engine, a partir de un tamaño de MIG zonal o regional de cero, consulta Aplica el ajuste de escala automático en grupos de instancias. Para obtener más información sobre cómo crear grupos, consulta gcloud compute instance-groups managed create.

    Cuando se inicie la instancia, se autenticará de forma automática con el plano de control de Anthos Service Mesh en tu clúster y el plano de control registrará cada VM como una WorkloadEntry.

  8. Cuando la instancia de VM del MIG termina de iniciarse, puedes ver las VM registradas en el espacio de nombres de la carga de trabajo con el siguiente comando:

    kubectl get workloadentry -n WORKLOAD_NAMESPACE

  9. Agrega un servicio de Kubernetes para exponer las cargas de trabajo de VM agregadas antes. Asegúrate de que el servicio seleccione la etiqueta correspondiente en la VM WorkloadGroup registrada antes para que enrute el tráfico correctamente.

    En el siguiente ejemplo, se crea un servicio de Kubernetes llamado WORKLOAD_NAME en el espacio de nombres WORKLOAD_NAMESPACE que expone las cargas de trabajo de la VM con la etiqueta app.kubernetes.io/name: WORKLOAD_NAME en el puerto HTTP 80.

    kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: WORKLOAD_NAME
  namespace: WORKLOAD_NAMESPACE
  labels:
    asm_resource_type: VM
spec:
  ports:
  - port: 80
    name: http
  selector:
    app.kubernetes.io/name: WORKLOAD_NAME
EOF

    Para obtener más detalles sobre cómo crear un servicio de Kubernetes, consulta https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service.

  10. Para usar una aplicación de muestra en tu VM, consulta Implementa una aplicación de muestra.

Vuelve a implementar las cargas de trabajo después de una actualización del plano de control en el clúster

Si actualizaste Anthos Service Mesh en la sección anterior y tienes cargas de trabajo que se ejecutan en tu clúster, cámbialas al nuevo plano de control.

Para las cargas de trabajo de VM, crea una plantilla de instancias nueva y realiza una actualización progresiva a las VM en tu MIG:

  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 del comando es similar al siguiente: Ten en cuenta que el resultado de las migraciones es un poco diferente al de las actualizaciones. 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-1118-4-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-1118-4-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=85d86774f7

    1. En el resultado, en la columna LABELS, observa el valor de la etiqueta de revisión istiod de la versión nueva, que está después del prefijo istio.io/rev=. En este ejemplo, el valor es asm-1118-4.

    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 en la etiqueta de revisión para la versión anterior de istiod es default.

  2. 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 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. Crea una plantilla de instancias nueva con gcloud. Asegúrate de incluir la misma configuración si tenías una plantilla de instancias para la misma carga de trabajo.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  4. Realiza una actualización progresiva en tu MIG existente para la carga de trabajo.

    Para obtener más información, consulta Inicia una actualización progresiva básica.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE

  5. Prueba la carga de trabajo de la VM para asegurarte de que funciona según lo esperado.

Actualiza aplicaciones de VM

Si tienes alguna actualización para tu aplicación, incluidos los cambios en WorkloadGroup o los cambios en tu plantilla de instancias de origen, se requiere una nueva plantilla de instancias para actualizar el MIG de tus cargas de trabajo de VM.

Cuando se aplica el cambio WorkloadGroup o se crea la plantilla de instancias de origen nueva, crearás una plantilla de instancias nueva para Anthos Service Mesh y realizarás una actualización progresiva a las VM en tu MIG.

  1. Crea una plantilla de instancias nueva con gcloud.

    gcloud beta compute instance-templates create NEW_ASM_INSTANCE_TEMPLATE \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=WORKLOAD_NAMESPACE/WORKLOAD_NAME \
--project PROJECT_ID

  2. Realiza una actualización progresiva en tu MIG existente para la carga de trabajo. Para obtener más información sobre cómo usar la actualización progresiva de MIG, consulta Inicia una actualización progresiva básica.

    gcloud compute instance-groups managed rolling-action start-update INSTANCE_GROUP_NAME \
--version=template=NEW_ASM_INSTANCE_TEMPLATE \
--zone=INSTANCE_GROUP_ZONE

  3. Prueba la carga de trabajo de la VM para asegurarte de que funcione como se espera.

Implementar una aplicación de muestra

Para demostrar que tu configuración de malla nueva funciona de forma correcta, puedes instalar la aplicación de muestra de Bookinfo. En este ejemplo, se ejecuta una base de datos de MySQL en la VM y el servicio de calificaciones lee los valores de las calificaciones de la base de datos.

Instala Bookinfo en el clúster

Sigue estos pasos para implementar los servicios de la aplicación Bookinfo con los proxies de sidecar incorporados en cada servicio. La aplicación Bookinfo se implementará en el espacio de nombres default.

  1. En la línea de comandos de la computadora en la que instalaste Anthos Service Mesh, ve a la raíz del directorio de instalación de Anthos Service Mesh que creaste en el paso Descarga la secuencia de comandos.

  2. Para habilitar la inserción automática de sidecar, elige la siguiente instrucción según el tipo de plano de control de Anthos Service Mesh.

    En el clúster

    Usa el siguiente comando para ubicar la etiqueta en istiod, que contiene el valor de la etiqueta de revisión que se usará en pasos posteriores.

    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-1118-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1118-4,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1118-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1118-4,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-1118-4.

    Malla de servicios administrados

    Usa la revisión asm-managed para agregar VM.

  3. Aplica la etiqueta de revisión al espacio de nombres default.

    En el clúster

    En el siguiente comando, REVISION es el valor de la etiqueta de revisión istiod que anotaste en el paso anterior.

    kubectl label namespace default 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.

    Malla de servicios administrados

    kubectl label namespace default istio-injection- istio.io/rev=asm-managed --overwrite

  4. Implementa tu aplicación en el espacio de nombres predeterminado mediante kubectl:

    kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml

  5. Confirma que la aplicación se implementó correctamente ejecutando los siguientes comandos:

    kubectl get services

    Resultado esperado:

    NAME                       CLUSTER-IP   EXTERNAL-IP         PORT(S)              AGE
details                    10.0.0.31    <none>        9080/TCP             6m
kubernetes                 10.0.0.1     <none>        443/TCP              7d
productpage                10.0.0.120   <none>        9080/TCP             6m
ratings                    10.0.0.15    <none>        9080/TCP             6m
reviews                    10.0.0.170   <none>        9080/TCP             6m

    y

    kubectl get pod

    Resultado esperado:

    NAME                                        READY     STATUS    RESTARTS   AGE
details-v1-1520924117-48z17                 2/2       Running   0          6m
productpage-v1-560495357-jk1lz              2/2       Running   0          6m
ratings-v1-734492171-rnr5l                  2/2       Running   0          6m
reviews-v1-874083890-f0qf0                  2/2       Running   0          6m
reviews-v2-1343845940-b34q5                 2/2       Running   0          6m
reviews-v3-1813607990-8ch52                 2/2       Running   0          6m

  6. Finalmente, define el enrutamiento de la puerta de enlace para la aplicación:

    kubectl apply -f samples/bookinfo/networking/bookinfo-gateway.yaml

    Resultado esperado:

    gateway.networking.istio.io/bookinfo-gateway created
virtualservice.networking.istio.io/bookinfo created

  7. Confirma que se pueda acceder a la página del producto. En el siguiente comando, GATEWAY_NAMESPACE es el espacio de nombres de la puerta de enlace de Istio.

    export INGRESS_HOST=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n GATEWAY_NAMESPACE get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].port}')
export GATEWAY_URL="${INGRESS_HOST}:${INGRESS_PORT}"
curl -s "http://${GATEWAY_URL}/productpage" | grep -o "<title>.*</title>"

    Resultado esperado:

    <title>Simple Bookstore App</title>

Crea instancias de Compute Engine y, luego, instala MySQL

En este paso, crearás una plantilla de instancias de Compute Engine para la instancia de MySQL que se ejecuta en la VM. Para ver pasos más detallados, consulta Bookinfo con una máquina virtual.

  1. Crea una secuencia de comandos de inicio para instalar MySQL y agrega una base de datos de calificaciones durante el inicio. Ten en cuenta que, si usas CentOS, el mariadb-server tardará hasta 10 minutos en estar listo.

    Debian

    cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns is ready"
    break
  fi
  sleep 1
done

sudo apt-get update && sudo apt-get install -y mariadb-server

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/mysql/mariadb.conf.d/50-server.cnf

cat <<EOD | sudo mysql
# Grant access to root
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

# Grant root access to other IPs
CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit
EOD

sudo systemctl restart mysql

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

    En CentOS

    cat << "EOF" > init-mysql
#!/bin/bash

# Wait until Envoy is ready before installing mysql
while true; do
  rt=$(curl -s 127.0.0.1:15000/ready)
  if [[ $? -eq 0 ]] && [[ "${rt}" -eq "LIVE" ]]; then
    echo "envoy is ready"
    break
  fi
  sleep 1
done

# Wait until DNS is ready before installing mysql
while true; do
  curl -I productpage.default.svc:9080
  if [[ $? -eq 0 ]]; then
    echo "dns is ready"
    break
  fi
  sleep 1
done

sudo yum update -y && sudo yum install -y mariadb-server

# Wait until mysql is ready
while true; do
  rt=$(which mysql)
  if [[ ! -z "${rt}" ]]; then
    echo "mysql is ready"
    break
  fi
  sleep 1
done

sudo sed -i '/bind-address/c\bind-address  = 0.0.0.0' /etc/my.cnf.d/mariadb-server.cnf

sudo systemctl restart mariadb

cat > grantaccess.sql << EOD

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION;

CREATE USER 'root'@'%' IDENTIFIED BY 'password';
GRANT ALL PRIVILEGES ON *.* TO 'root'@'%' WITH GRANT OPTION;
FLUSH PRIVILEGES;
EOD

until sudo mysql < grantaccess.sql; do
   sleep 1
done

sudo systemctl restart mariadb

curl -LO https://raw.githubusercontent.com/istio/istio/release-1.11/samples/bookinfo/src/mysql/mysqldb-init.sql

mysql -u root -ppassword < mysqldb-init.sql
EOF

  2. Crea un WorkloadGroup para la carga de trabajo de MySQL

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: WorkloadGroup
metadata:
  name: mysql
  namespace: default
spec:
  metadata:
    labels:
      app.kubernetes.io/name: mysql
    annotations:
      security.cloud.google.com/IdentityProvider: google
  template:
    serviceAccount: WORKLOAD_SERVICE_ACCOUNT
EOF

  3. Usa gcloud a fin de crear una plantilla de instancias nueva a fin de preparar las instancias para la malla y, luego, incluir la secuencia de comandos de inicio creada con anterioridad.

    Debian

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=debian-cloud --image-family=debian-10 --boot-disk-size=10GB

    En CentOS

    gcloud beta compute instance-templates create asm-mysql-instance-template \
--mesh gke-cluster=CLUSTER_LOCATION/CLUSTER_NAME,workload=default/mysql \
--project PROJECT_ID \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud --image-family=centos-8 --boot-disk-size=20GB

  4. Crea un MIG de Compute Engine con la plantilla de instancias recién creada.

    gcloud compute instance-groups managed create mysql-instance \
--template asm-mysql-instance-template \
--zone=us-central1-c \
--project=PROJECT_ID \
--size=1

Creación de servicio

Crea un servicio de Kubernetes para el servicio de MySQL mediante el siguiente comando:

kubectl apply -f - << EOF
apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: default
  labels:
    asm_resource_type: VM
spec:
  ports:
  - name: mysql
    port: 3306
    protocol: TCP
    targetPort: 3306
  selector:
    app.kubernetes.io/name: mysql
EOF

Usa el panel de la IU de Anthos

Para ver el nuevo servicio basado en VM que creaste, haz clic en Anthos > Service Mesh en la barra de navegación principal de la izquierda. Se mostrará una tabla de los servicios que se ejecutan en la malla. El servicio que agregaste debería aparecer en la tabla, con un valor de Type de VM y algunas métricas de alto nivel. Para ver más información de telemetría de tu servicio basado en VM, haz clic en el nombre del servicio y se mostrará el panel del nivel del servicio.

Si quieres obtener más información para usar el panel de IU de Anthos, consulta Explora Anthos Service Mesh en Cloud Console.

Administra el tráfico a las cargas de trabajo de la VM

Puedes cambiar las reglas de red para controlar cómo fluye el tráfico dentro y fuera de las VM.

Controla el tráfico a un nuevo servicio de calificaciones (de pod a VM)

Crea otro servicio de calificaciones en Bookinfo que usará la instancia de MySQL creada anteriormente como fuente de datos y especifica una regla de enrutamiento que obligue al servicio de revisión a usar el servicio de calificación nuevo.

  1. Crea un servicio de calificación nuevo para usar la instancia de MySQL.

    kubectl apply -f - << EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ratings-v2-mysql-vm
  labels:
    app: ratings
    version: v2-mysql-vm
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ratings
      version: v2-mysql-vm
  template:
    metadata:
      labels:
        app: ratings
        version: v2-mysql-vm
    spec:
      serviceAccountName: bookinfo-ratings
      containers:
      - name: ratings
        image: docker.io/istio/examples-bookinfo-ratings-v2:1.16.2
        imagePullPolicy: IfNotPresent
        env:
          - name: DB_TYPE
            value: "mysql"
          - name: MYSQL_DB_HOST
            value: mysql.default.svc.cluster.local
          - name: MYSQL_DB_PORT
            value: "3306"
          - name: MYSQL_DB_USER
            value: root
          - name: MYSQL_DB_PASSWORD
            value: password
        ports:
        - containerPort: 9080
EOF

  2. Crea una regla de enrutamiento.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: ratings
spec:
  hosts:
  - ratings
  http:
  - route:
    - destination:
        host: ratings
        subset: v2-mysql-vm
EOF

  3. Aplica reglas de destino para los servicios creados.

    kubectl apply -f - << EOF
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v3
    labels:
      version: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: ratings
spec:
  host: ratings
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  - name: v2-mysql
    labels:
      version: v2-mysql
  - name: v2-mysql-vm
    labels:
      version: v2-mysql-vm
EOF

Valida la implementación de la aplicación

Para comprobar que la aplicación Bookinfo funcione, envía tráfico a la puerta de enlace de entrada.

  • Si instalaste Anthos Service Mesh en GKE, obtén la dirección IP externa de la puerta de enlace de entrada que creaste en los pasos anteriores:

    kubectl get svc istio-ingressgateway -n GATEWAY_NAMESPACE

    Resultado:

    NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE
istio-ingressgateway   LoadBalancer   10.19.247.233   35.239.7.64   80:31380/TCP,443:31390/TCP,31400:31400/TCP   27m

    En este ejemplo, la dirección IP del servicio de entrada es 35.239.7.64.

Prueba la aplicación

  1. Verifica que la app Bookinfo se ejecute con curl:

    curl -I http://EXTERNAL_IP/productpage

    Si la respuesta muestra 200, significa que la aplicación funciona de forma correcta con Anthos Service Mesh.

  2. Para ver la página web de Bookinfo, ingresa la siguiente dirección en tu navegador:

    http://EXTERNAL_IP/productpage

  3. Verifica que en la página principal de la aplicación Bookinfo se muestren cinco estrellas de Reviewer1 y cuatro estrellas de Reviewer2.

Aplica funciones de seguridad en las cargas de trabajo de la VM

Aplicar funciones de seguridad en las cargas de trabajo de VM es lo mismo que aplicarlas en las cargas de trabajo de Kubernetes. Para obtener más información, consulta Seguridad de Istio.

Después de completar los pasos anteriores, la VM de Compute Engine tendrá un certificado de carga de trabajo emitido por Google. En el certificado, el valor SubjectAlternativeName muestra la identidad de la carga de trabajo de Anthos de la VM con el formato spiffe://<workload_identity_pool>/ns/WORKLOAD_NAMESPACE/sa/WORKLOAD_SERVICE_ACCOUNT.

Para obtener más información, consulta Grupo de Workload Identity.

Habilita el modo estricto mTLS para la malla

Aplica el siguiente YAML para aplicar el mTLS estricto en toda la malla.

kubectl apply -f - << EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF

Autorización para el tráfico de servicio a servicio

Usa AuthorizationPolicy para controlar el acceso entre las aplicaciones en tu VM de Compute Engine y otras cargas de trabajo de malla (p. ej., en el clúster de GKE).

Ejemplo: Rechazar las cargas de trabajo de Kubernetes para acceder a las VM de Compute Engine

La siguiente política de autorización rechaza una carga de trabajo de Kubernetes ratings para acceder a las cargas de trabajo de la VM de Compute Engine que entregan el servidor MySQL ratings.

  kubectl apply -f - << EOF
  apiVersion: security.istio.io/v1beta1
  kind: AuthorizationPolicy
  metadata:
    name: mysql-deny
    namespace: default
  spec:
    selector:
      matchLabels:
        app.kubernetes.io/name: mysql
    action: DENY
    rules:
    - from:
      - source:
          principals: ["cluster.local/ns/default/sa/bookinfo-ratings"]
  EOF

Después de aplicar el AuthorizationPolicy de ejemplo, deberías ver un mensaje de error Ratings service is currently unavailable en la sección de opiniones sobre libros de la página del producto.

Instala el agente de Cloud Monitoring

Puedes instalar el agente de Cloud Monitoring para recopilar y supervisar las métricas del sistema y de las aplicaciones de las instancias de VM. Esto te permite supervisar métricas clave, por ejemplo, el uso de memoria y CPU en el agente.

Para obtener más información, consulta Documentación del agente de Cloud Monitoring.

Solución de problemas

Para obtener sugerencias sobre cómo solucionar problemas, consulta Resuelve problemas de asistencia de VM.