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

1.20 (más reciente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

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

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 la consola de Google Cloud.

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

ASM 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 el tráfico de ASM se enrute 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 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 aumentar o reducir la cantidad de cargas de trabajo en instancias de Compute Engine, comenzando por un tamaño mínimo del MIG de cero, consulta 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 función sin una suscripción a GKE Enterprise, pero ciertos elementos y funciones de la IU en la consola de Google Cloud solo están disponibles para los suscriptores de GKE Enterprise. Si deseas obtener información sobre lo que está disponible para suscriptores y no suscritos, consulta Diferencias de IU de GKE Enterprise y Anthos Service Mesh.

Requisitos previos

Antes de comenzar, verifica los siguientes requisitos previos.

Clústeres

En esta página, se incluye la opción de instalar Anthos Service Mesh como parte de sus pasos o actualizar un clúster que ya tiene Anthos Service Mesh instalado. En cualquier caso, estos pasos requieren Anthos Service Mesh 1.9 o una versión posterior y un clúster que cumpla con estos requisitos. Además, la asistencia de VM de Anthos Service Mesh tiene más requisitos:

El plano de control debe instalarse en un clúster que controles. Los planos de control administrados por Google no son compatibles. Para obtener más información, consulta Planos de control administrados por Google.
Usa la CA de Mesh como autoridad certificadora.
Usa Stackdriver para la telemetría.
Tiene la implementación Canonical Service habilitada, que el proceso de instalación de Anthos Service Mesh habilita de forma automática.

Tu clúster debe estar registrado en una flota. Sin embargo, si aún no se registró, el proceso de instalación de VM puede registrarlo por ti en tu proyecto especificado.

Si eres suscriptor de GKE Enterprise, habilita la API de GKE Enterprise.

Habilitar la API

Herramientas de la CLI

El proceso de instalación requiere las siguientes herramientas, que ya están instaladas si usas Google Cloud Shell:

gcloud
kubectl
kpt
curl
jq
awk
printf
tr
grep
tail

Descarga la secuencia de comandos

En esta sección, se describe cómo descargar la secuencia de comandos para la integración de VM.

Descarga la secuencia de comandos de VM para Anthos Service Mesh 1.9.8 en el directorio de trabajo actual:
```
curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9 > asm_vm
```

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

curl https://storage.googleapis.com/csm-artifacts/asm/asm_vm_1.9.sha256 > asm_vm.sha256

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

Para mayor compatibilidad, el archivo asm_vm.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 asm_vm. 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 asm_vm
```

Primeros pasos

En esta sección, se explican los pasos para agregar instancias de Compute Engine a Anthos Service Mesh.

Configure su entorno

Usa gcloud para configurar tu herramienta de kubectl para apuntar al clúster que especificaste, ya que algunos de los pasos siguientes requieren que realices cambios directamente en el clúster.

Nota: Usa --region en lugar de --zone, si el clúster es un clúster regional.
```
gcloud container clusters get-credentials CLUSTER_NAME --zone CLUSTER_LOCATION --project PROJECT_ID
```

Prepara tu clúster

Prepara el clúster de Anthos Service Mesh para VM mediante la preparación del plano de control de Anthos Service Mesh 1.9 o una versión posterior.

Selecciona el siguiente paso en función de si Anthos Service Mesh 1.9 o una versión posterior ya está instalada en tu clúster.

No instalada

Si Anthos Service Mesh 1.9 o una versión posterior no se instaló en tu clúster, en el siguiente ejemplo se muestra cómo agregar las opciones vm y hub-meshca para modificar los pasos de instalación habituales de Anthos Service Mesh proporcionados en Instalación, migración y actualización de GKE. También se explica cómo descargar la secuencia de comandos install_asm que se usa en el siguiente ejemplo.

Después de descargar la secuencia de comandos install_asm, puedes instalar Anthos Service Mesh en tu clúster si incluyes las marcas --option hub-meshca, --option vm y --enable_all. Si quieres obtener más información, consulta Habilita la CA de Mesh con la flota y Marcas de habilitación.

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

Instalada

Si Anthos Service Mesh 1.9 o una versión posterior ya está instalada en tu clúster y tiene Mesh de CA con la flota habilitada, actualiza el plano de control de Anthos Service Mesh para admitir cargas de trabajo basadas en VM. La secuencia de comandos también te ayuda a verificar si tu instalación de Anthos Service Mesh en el clúster está lista para las cargas de trabajo de VM. En particular, el subcomando prepare_cluster actualiza todas las revisiones de Anthos Service Mesh 1.9 o de versiones posteriores a fin de estar listas para las cargas de trabajo de VM.

Si la CA de Mesh con la flota no está habilitada en la instalación de Anthos Service Mesh 1.9 ni de versiones posteriores, vuelve a instalarlo o actualízalo mediante la inclusión de las marcas --option hub-meshca y --option vm en la secuencia de comandos install_asm.

./asm_vm prepare_cluster \
--project_id PROJECT_ID \
--cluster_name CLUSTER_NAME \
--cluster_location CLUSTER_LOCATION

En los pasos anteriores, se realizaron las siguientes acciones:

Habilitar el registro automático de VM: Para ello, se debe configurar la variable PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION como verdadera. Cuando esta función esté habilitada, las instancias de VM nuevas se registrarán con el WorkloadGroup y se crearán nuevas CR de 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 install_asm incluirán esto de forma predeterminada.
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.
Instala la CRD IdentityProvider y registra 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.
Registrar el clúster en una flota y habilitar Workload Identity si usas --enable_all o --enable_registration en la secuencia de comandos install_asm.
Habilitar la función Service Mesh en la flota. Esta administrará las políticas necesarias para permitir que las VM se comuniquen de forma segura con la malla.

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 la secuencia de comandos asm_vm. La secuencia de comandos solo genera la configuración necesaria para el agente del proxy de servicio. Para incluir más opciones de configuración en tu plantilla de instancias, crea una plantilla de instancias de origen y agrégala a la secuencia de comandos.

Para agregar VM a tu malla, sigue estos pasos:

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.
- SOURCE_INSTANCE_TEMPLATE es el nombre de la plantilla en la que se basará la plantilla generada. Opcional.
Crea el espacio de nombres para las cargas de trabajo de la VM si aún no existe:
```
kubectl create ns WORKLOAD_NAMESPACE
```
Etiqueta el espacio de nombres con la revisión del plano de control. 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
```

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

Ejecuta la secuencia de comandos asm_vm con las siguientes opciones y marcas a fin de crear una plantilla de instancias para tus instancias de Compute Engine de Anthos Service Mesh.

La secuencia de comandos verifica 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 tienes una plantilla de instancias existente en la que deseas que se base la secuencia de comandos, puedes especificar la opción --source_instance_template. Si deseas agregar VM no predeterminadas a Anthos Service Mesh, crea una plantilla de instancias con la distribución del SO deseada y úsala como el valor de la marca --source_instance_template en la secuencia de comandos asm_vm. 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.

./asm_vm create_gce_instance_template \
ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE

Opciones

Opción	Descripción
`-p\|--project_id PROJECT_ID`	Es 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 los clústeres de zona única) o la región (para los clústeres regionales) en la que se creó el clúster.
`-w\|--workload_name WORKLOAD_NAME`	El nombre de la carga de trabajo que representan las instancias de Compute Engine.
`--workload_namespace WORKLOAD_NAMESPACE`	Opcional. El espacio de nombres de la carga de trabajo. El valor predeterminado es “default”.
`-s\|--source_instance_template SOURCE_INSTANCE_TEMPLATE_NAME`	Opcional. Una plantilla de instancias existente para usar como base de la plantilla de instancias de Compute Engine de Anthos Service Mesh. Si no se especifica, se crea una plantilla de instancias con valores predeterminados.

Marcas

Flag	Descripción
`-v\|--verbose`	Imprime comandos antes y después de la ejecución.
`--dry_run`	Imprime comandos, pero no los ejecuta.
`--only_validate`	Ejecuta la validación, pero no crea una nueva plantilla de instancias de Compute Engine.
`-h\|--help`	Muestra un mensaje de ayuda que describe las opciones y las marcas, y se cierra.

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.
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 aumentar o reducir 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 la creación de 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.
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
```
Nota: Si se borran los recursos personalizados WorkloadGroup o IdentityProvider, la VM no podrá comunicarse con la malla.
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.
Para usar una aplicación de muestra en tu VM, consulta Implementa una aplicación de muestra.

Actualización del plano de control de Anthos Service Mesh

Actualiza tu plano de control de Anthos Service Mesh a una versión nueva mediante las instrucciones que se muestran en Actualiza Anthos Service Mesh a la versión más reciente. Después de instalar una versión nueva del plano de control de Anthos Service Mesh, vuelve a implementar las cargas de trabajo de Kubernetes con las instrucciones que se indican en Implementa y vuelve a implementar las cargas de trabajo.

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:

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-198-6-85d86774f7-flrt2   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=85d86774f7
istiod-asm-198-6-85d86774f7-tcwtn   1/1     Running   0          26m   app=istiod,istio.io/rev=asm-198-6,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-198-6.
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.
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.
Crea una plantilla de instancias nueva con la secuencia de comandos asm_vm. Asegúrate de usar un nombre nuevo de plantilla de instancias y, además, incluye la misma plantilla de instancias de origen si tenías una para la misma carga de trabajo.

Nota: La marca --source_instance_template es opcional. Si tienes una plantilla de origen, debes incluirla. Si no tienes una plantilla de origen, no incluyas la marca.
```
./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template SOURCE_INSTANCE_TEMPLATE
```
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
```
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.

Crea una plantilla de instancias nueva con la secuencia de comandos asm_vm. Asegúrate de usar un nombre de plantilla de instancias nuevo y, además, incluye la plantilla de instancia de origen nueva si creaste una para la actualización de la aplicación.

./asm_vm create_gce_instance_template \
NEW_ASM_INSTANCE_TEMPLATE \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name WORKLOAD_NAME \
--workload_namespace WORKLOAD_NAMESPACE \
--source_instance_template NEW_SOURCE_INSTANCE_TEMPLATE

Realiza una actualización progresiva en tu MIG existente para la carga de trabajo. Si deseas obtener más información para 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
```
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.

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.

Para habilitar la inserción automática del sidecar, usa el siguiente comando a fin de localizar 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-198-6-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-198-6,istio=istiod,pod-template-hash=5788d57586
istiod-asm-198-6-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-198-6,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-198-6.

Aplica la etiqueta de revisión al espacio de nombres default. 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.
Implementa tu aplicación en el espacio de nombres predeterminado mediante kubectl:
```
kubectl apply -f samples/bookinfo/platform/kube/bookinfo.yaml
```

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

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

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

Confirma que se pueda acceder a la página del producto.

export INGRESS_HOST=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
export INGRESS_PORT=$(kubectl -n istio-system 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.

Crea una plantilla de instancias de Compute Engine que incluya una secuencia de comandos de inicio para instalar MySQL y agrega una base de datos de calificaciones en 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

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.9/samples/bookinfo/src/mysql/mysqldb-init.sql

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

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image=debian-10-buster-v20201014 \
--image-project=debian-cloud \
--boot-disk-size=10GB

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

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.9/samples/bookinfo/src/mysql/mysqldb-init.sql

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

gcloud compute \
--project=PROJECT_ID \
instance-templates create mysql-instance-template \
--machine-type=e2-medium \
--metadata-from-file=startup-script=init-mysql \
--image-project=centos-cloud \
--image-family=centos-8 \
--boot-disk-size=30GB

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

Usa la secuencia de comandos de VM anterior a fin de crear una plantilla de instancias nueva para preparar las instancias para tu malla.

./asm_vm create_gce_instance_template \
asm-mysql-instance-template \
--project_id PROJECT_ID \
--cluster_location CLUSTER_LOCATION \
--cluster_name CLUSTER_NAME \
--workload_name mysql \
--source_instance_template mysql-instance-template

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.

Crea un servicio de Kubernetes con 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.

Para obtener más información sobre cómo usar el panel de IU de Anthos, consulta Explora Anthos Service Mesh en la consola de Cloud.

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.

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

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

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

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

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.
Para ver la página web de Bookinfo, ingresa la siguiente dirección en tu navegador:
```
http://EXTERNAL_IP/productpage
```
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.

Soluciona problemas

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