Descripción general

Una malla de servicios de Cloud es una arquitectura que permite una comunicación administrada, observable y segura entre tus servicios, lo que facilita la creación de aplicaciones empresariales sólidas conformadas por muchos microservicios en la infraestructura seleccionada. Administra los requisitos comunes de la ejecución de un servicio, como la supervisión, las redes y la seguridad, con herramientas coherentes y potentes, lo que permite que los desarrolladores y operadores de servicios se concentren en crear y administrar aplicaciones excelentes para sus usuarios.

El modelo de administración de tráfico de Cloud Service Mesh se basa en los siguientes dos componentes:

• Plano de control: administra y configura los proxies de Envoy para enrutar el tráfico y aplicar políticas.
• Plano de datos: abarca toda la comunicación de red entre microservicios, que realizan los proxies de Envoy durante el tiempo de ejecución.

Estos componentes habilitan las funciones de administración de tráfico de malla, incluidas las siguientes:

• Descubrimiento de servicios
• Balanceo de cargas
• Control y enrutamiento de tráfico

Objetivos

En este lab, aprenderás a realizar las siguientes tareas:

• Configurar y usar puertas de enlace de Istio
• Aplicar reglas de destino predeterminadas para todas las versiones disponibles
• Aplicar servicios virtuales para enrutar el tráfico a una sola versión de forma predeterminada
• Enrutar el tráfico a una versión específica de un servicio según la identidad del usuario
• Cambiar gradualmente el tráfico de una versión de un microservicio a otra
• Usar el panel de Cloud Service Mesh para ver el enrutamiento a varias versiones
• Configurar las prácticas recomendadas de redes, como reintentos, disyuntores y tiempos de espera

Configuración y requisitos

En esta tarea, realizarás los pasos de inicialización para tu lab.

En cada lab, recibirás un proyecto de Google Cloud y un conjunto de recursos nuevos por tiempo limitado y sin costo adicional.

1. Accede a Google Skills en una ventana de incógnito.

2. Ten en cuenta el tiempo de acceso del lab (por ejemplo, 1:15:00) y asegúrate de finalizarlo en el plazo asignado. No existe una función de pausa. Si lo necesitas, puedes reiniciar el lab, pero deberás hacerlo desde el comienzo.

3. Cuando tengas todo listo, haz clic en Comenzar lab.

4. Anota las credenciales del lab (el nombre de usuario y la contraseña). Las usarás para acceder a la consola de Google Cloud.

5. Haz clic en Abrir la consola de Google.

6. Haz clic en Usar otra cuenta, copia las credenciales para este lab y pégalas en el mensaje emergente que aparece. Si usas otras credenciales, se generarán errores o incurrirás en cargos.

7. Acepta las condiciones y omite la página de recursos de recuperación.

Después de completar los pasos iniciales de acceso, aparecerá el panel del proyecto.

8. Haz clic en Seleccionar un proyecto, destaca tu ID del proyecto de Google Cloud y haz clic en ABRIR para seleccionar tu proyecto.

Activa Google Cloud Shell

Google Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud.

Google Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. En la consola de Cloud, en la barra de herramientas superior derecha, haz clic en el botón Abrir Cloud Shell.

   

2. Haz clic en Continuar.

El aprovisionamiento y la conexión al entorno demorarán unos minutos. Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. Por ejemplo:

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con el completado de línea de comando.

• Puedes solicitar el nombre de la cuenta activa con este comando:

gcloud auth list

Resultado:

Credentialed accounts: - @.com (active)

Resultado de ejemplo:

Credentialed accounts: - google1623327_student@qwiklabs.net

• Puedes solicitar el ID del proyecto con este comando:

gcloud config list project

Resultado:

[core] project =

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: La documentación completa de gcloud está disponible en la guía de descripción general de gcloud CLI .

Tarea 1: Revisar los casos de uso de administración del tráfico

El uso de distintas opciones de configuración habilita las diferentes capacidades de administración de tráfico.

Ejemplo: División del tráfico

Enruta el tráfico a distintas versiones de un servicio.

Ejemplo: Tiempos de espera

Establece un tiempo de espera; es decir, la cantidad de tiempo que Istio esperará para recibir una respuesta a una solicitud. El tiempo de espera para solicitudes HTTP es de 15 segundos, pero se puede anular.

Ejemplo: Reintentos

Un reintento ocurre cuando se trata de completar una operación más de una vez a causa de un error. Ajusta la cantidad máxima de reintentos o de intentos posibles dentro del plazo de espera predeterminado o anulado.

Ejemplo: Inyección de errores mediante inserción de retrasos

La inyección de errores es un método de prueba que introduce errores en un sistema para garantizar que pueda soportar las condiciones de error y recuperarse de ellas.

En este ejemplo, se incluye un retraso de 5 segundos en el 10% de las solicitudes realizadas a la versión "v1" del microservicio ratings.

Ejemplo: Inyección de errores mediante inserción de anulaciones

En el ejemplo anterior, se muestra un código de error HTTP 400 para el 10% de las solicitudes realizadas a la versión "v1" del servicio ratings.

Ejemplo: Enrutamiento condicional basado en etiquetas de origen

Una regla puede indicar que solo se aplica a las llamadas realizadas desde cargas de trabajo (Pods) que implementan la versión "v2" del servicio reviews.

Ejemplo: Enrutamiento condicional (basado en encabezados de solicitud)

La regla anterior solo se aplicará a una solicitud entrante si incluye un encabezado "end-user" personalizado con la cadena "atharvak".

Tarea 2: Completar la configuración del lab

El entorno de este lab ya se configuró de forma parcial.

• Se creó un clúster de GKE llamado gke.
• Se instaló Cloud Service Mesh.
• Se implementó Bookinfo (la aplicación de muestra de varios servicios).

Configura el acceso de kubectl al clúster

1. Establece la variable de entorno de la zona:

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

2. En Cloud Shell, configura las variables de entorno del nombre del clúster:

   export CLUSTER_NAME=gke

3. Ejecuta el siguiente comando para configurar el acceso a la línea de comandos de kubectl:

   export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT

   Si se te solicita, haz clic en el botón Autorizar.

Verifica la instalación del clúster y de Cloud Service Mesh

4. Controla que tu clúster esté en funcionamiento:

   gcloud container clusters list

   Resultado:

   NAME: gke LOCATION: {{{ project_0.default_zone| "Zone" }}} MASTER_VERSION: 1.24.8-gke.2000 MASTER_IP: 35.222.150.207 MACHINE_TYPE: e2-standard-4 NODE_VERSION: 1.24.8-gke.2000 NUM_NODES: 2 STATUS: RUNNING

5. Asegúrate de que los Pods de Kubernetes para el plano de control de Cloud Service Mesh estén implementados:

   kubectl get pods -n asm-ingress

Resultado:

NAME READY STATUS RESTARTS AGE istio-ingressgateway-69fc5475fd-4wglw 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-stb7x 1/1 Running 0 22m istio-ingressgateway-69fc5475fd-vkxp4 1/1 Running 0 22m

El estado del Pod debería ser Running o Completed.

6. Asegúrate de que los servicios de Kubernetes correspondientes al plano de control de Cloud Service Mesh estén implementados:

   kubectl get service -n asm-ingress

Resultado:

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE istio-ingressgateway LoadBalancer 34.118.232.124 34.75.207.190 15021:32645/TCP,80:31091/TCP,443:32092/TCP 30m

Verifica la implementación de Bookinfo

8. Confirma que la aplicación se haya implementado correctamente con este comando:

   kubectl get pods

   Resultado:

   NAME READY STATUS details-v1-1520924117-48z17 2/2 Running productpage-v1-560495357-jk1lz 2/2 Running ratings-v1-734492171-rnr5l 2/2 Running reviews-v1-874083890-f0qf0 2/2 Running reviews-v2-1343845940-b34q5 2/2 Running reviews-v3-1813607990-8ch52 2/2 Running Nota: Como puedes ver, cada Pod tiene dos contenedores: el contenedor de la aplicación y el proxy sidecar de Istio.

9. Revisa los servicios de la aplicación en ejecución:

   kubectl get services

   Resultado:

   NAME TYPE CLUSTER-IP EXTERNAL-IP ... details ClusterIP 10.7.248.49 kubernetes ClusterIP 10.7.240.1 productpage ClusterIP 10.7.248.22 ratings ClusterIP 10.7.247.26 reviews ClusterIP 10.7.246.22

Tarea 3: Instalar puertas de enlace para habilitar la entrada

En un entorno de Kubernetes, se usa el recurso Ingress correspondiente para especificar qué servicios se deben exponer fuera del clúster. En Cloud Service Mesh, se usa un recurso Gateway, un mejor enfoque (que también funciona en Kubernetes y otros entornos). Un recurso Gateway permite que las funciones de la malla, como la supervisión, el mTLS y las reglas de capacidades de enrutamiento avanzadas, se apliquen al tráfico que ingresa al clúster.

Las puertas de enlace superan las limitaciones de Ingress de Kubernetes porque separan la capa 7 de la especificación de las capas 4-6. El recurso Gateway configura las funciones de las capas 4 a 6 como los puertos que se expondrán o el protocolo que se usará. Luego, los propietarios del servicio vinculan VirtualService para configurar opciones de enrutamiento de tráfico L7, como el enrutamiento basado en rutas, encabezados, pesos, etcétera.

Existen dos opciones para implementar puertas de enlace: compartidas o dedicadas. Las puertas de enlace compartidas usan una sola puerta de enlace centralizada que utilizan muchas aplicaciones, posiblemente en varios espacios de nombres. En el siguiente ejemplo, el recurso Gateway en el espacio de nombres de entrada delega la propiedad de las rutas a los espacios de nombres de la aplicación, pero conserva el control sobre la configuración de TLS. Esto funciona bien cuando se usan certificados TLS compartidos o infraestructura compartida. En este lab, usaremos esta opción.

Las puertas de enlace dedicadas ofrecen control y propiedad total a un solo espacio de nombres, ya que un espacio de nombres de la aplicación tiene su propia puerta de enlace dedicada. Esto funciona bien para las aplicaciones que requieren aislamiento por motivos de seguridad o rendimiento.

Instala una puerta de enlace de entrada en tu clúster

1. Crea un espacio de nombres para la puerta de enlace:

   kubectl create namespace ingress

2. Etiqueta el espacio de nombres de la puerta de enlace con una etiqueta de revisión para la inserción automática:

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

   El webhook de inserción de sidecar usa la etiqueta de revisión para asociar los proxies insertados con una revisión de plano de control en particular.

   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 Service Mesh o en implementaciones nuevas.

   Debido a que la inserción automática falla si un espacio de nombres tiene tanto la etiqueta istio-injection como la de revisión, todos los comandos kubectl label de la documentación de Service Mesh incluyen la acción de quitar la etiqueta istio-injection.

3. Descarga y aplica los archivos de configuración de la puerta de enlace. Estos incluyen los Pods y los servicios que primero recibirán las solicitudes entrantes desde fuera del clúster:

cat <<'EOF' > ingress.yaml apiVersion: v1 kind: ServiceAccount metadata: name: istio-ingressgateway namespace: ingress --- apiVersion: v1 kind: Service metadata: name: istio-ingressgateway namespace: ingress labels: app: istio-ingressgateway istio: ingressgateway spec: ports: # El puerto de estado expone un extremo /healthz/ready que se puede usar con las verificaciones de estado del Ingress de GKE - name: status-port port: 15021 protocol: TCP targetPort: 15021 # Cualquier puerto que se exponga en los recursos de la puerta de enlace se deben exponer aquí. - name: http2 port: 80 - name: https port: 443 selector: istio: ingressgateway app: istio-ingressgateway type: LoadBalancer --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: istio-ingressgateway namespace: ingress rules: - apiGroups: - "" resources: - secrets verbs: - get - watch - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: istio-ingressgateway namespace: ingress roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: istio-ingressgateway subjects: - kind: ServiceAccount name: istio-ingressgateway --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: istio-ingressgateway namespace: ingress spec: maxUnavailable: 1 selector: matchLabels: istio: ingressgateway app: istio-ingressgateway --- apiVersion: apps/v1 kind: Deployment metadata: name: istio-ingressgateway namespace: ingress spec: replicas: 1 selector: matchLabels: app: istio-ingressgateway istio: ingressgateway template: metadata: annotations: # Esto es necesario para insertar la puerta de enlace con la # configuración obligatoria. inject.istio.io/templates: gateway labels: app: istio-ingressgateway istio: ingressgateway spec: containers: - name: istio-proxy image: auto # La imagen se actualizará automáticamente cada vez que se inicie el Pod. serviceAccountName: istio-ingressgateway --- apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: istio-ingressgateway namespace: ingress spec: maxReplicas: 5 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 80 minReplicas: 3 scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: istio-ingressgateway EOF kubectl apply -n ingress -f ingress.yaml

4. Después de crear la implementación, verifica que los servicios nuevos funcionen:

   kubectl get pod,service -n ingress

   Observa que el recurso es un LoadBalancer. Esta puerta de enlace de entrada utiliza un balanceador de cargas TCP externo en GCP.

5. Implementa el recurso Gateway para especificar el puerto y el protocolo que se usarán. En este caso, la puerta de enlace habilita el tráfico HTTP a través del puerto 80:

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: bookinfo-gateway namespace: ingress spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" EOF

   El recurso Gateway debe estar ubicado en el mismo espacio de nombres que la implementación de la puerta de enlace.

6. Implementa el recurso VirtualService para enrutar el tráfico desde los Pods y el servicio de la puerta de enlace que acabas de crear a la aplicación BookInfo:

   cat <<EOF | kubectl apply -f - apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: bookinfo spec: hosts: - "*" gateways: - ingress/bookinfo-gateway http: - match: - uri: exact: /productpage - uri: prefix: /static - uri: exact: /login - uri: exact: /logout - uri: prefix: /api/v1/products route: - destination: host: productpage port: number: 9080 EOF

   El recurso VirtualService debe estar ubicado en el mismo espacio de nombres que la aplicación. Observa que establece el servicio productpage como el destino predeterminado.

7. Verifica que se hayan creado los recursos Gateway y VirtualService, y observa que el VirtualService apunte al Gateway:

   kubectl get gateway,virtualservice

8. Guarda esta IP externa en tu entorno de Cloud Shell:

   export GATEWAY_URL=$(kubectl get svc -n ingress istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}') echo The gateway address is $GATEWAY_URL

Nota: Si la dirección de la puerta de enlace está vacía, espera entre 1 y 2 minutos y vuelve a intentar el último comando. Haz esto hasta que tengas una dirección en tu variable $GATEWAY_URL.

Genera un poco de tráfico en segundo plano

Genera un poco de tráfico en segundo plano en la aplicación para que, cuando explores el panel de Service Mesh, haya algunos datos interesantes para consultar.

1. En Cloud Shell, instala siege, una herramienta de generación de carga:

   sudo apt install siege

2. Usa siege para crear tráfico en tus servicios.

   siege http://${GATEWAY_URL}/productpage

Accede a la aplicación BookInfo

1. En Cloud Shell, haz clic en el ícono +, ubicado en la barra de menú, para abrir otra pestaña.

2. Establece la variable de entorno de la zona:

   CLUSTER_ZONE={{{ project_0.default_zone| "Zone added at lab start" }}}

3. Inicializa la pestaña nueva de Cloud Shell:

   export CLUSTER_NAME=gke export GCLOUD_PROJECT=$(gcloud config get-value project) gcloud container clusters get-credentials $CLUSTER_NAME \ --zone $CLUSTER_ZONE --project $GCLOUD_PROJECT export GATEWAY_URL=$(kubectl get svc istio-ingressgateway \ -o=jsonpath='{.status.loadBalancer.ingress[0].ip}' -n ingress)

4. Confirma que la aplicación Bookinfo responda. Para ello, envíale una solicitud curl desde algún Pod que esté dentro del clúster; por ejemplo, desde ratings:

   kubectl exec -it \ $(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}') \ -c ratings -- curl productpage:9080/productpage \ | grep -o "<title>.*</title>"

   Resultado:

   <title>Simple Bookstore App</title>

5. Comprueba que la aplicación Bookinfo responda a una solicitud curl enviada desde fuera del clúster. Para ello, usa la IP externa que guardaste antes:

   curl -I http://${GATEWAY_URL}/productpage

   Resultado:

   HTTP/1.1 200 OK content-type: text/html; charset=utf-8 content-length: 5293 server: istio-envoy date: Wed, 01 Feb 2023 13:28:58 GMT x-envoy-upstream-service-time: 27

6. Abre la aplicación Bookinfo en tu navegador. Ejecuta este comando en Cloud Shell para obtener la URL completa:

   echo http://${GATEWAY_URL}/productpage

¡Felicitaciones! Expusiste un extremo HTTP para el servicio productpage de Bookinfo al tráfico externo. Los recursos de configuración de Gateway permiten que el tráfico externo ingrese a la malla de servicios y hacen que las funciones de políticas y administración del tráfico estén disponibles para los servicios perimetrales.

Haz clic en Revisar mi progreso para verificar el objetivo. Instalar puertas de enlace para habilitar la entrada.

Tarea 4: Usar el panel de Service Mesh para ver el enrutamiento a varias versiones

Hay algunos aspectos que se deben tener en cuenta a la hora de consultar datos en el panel de Service Mesh.

La primera es que, en la mayoría de las páginas, los datos tardan entre 1 y 2 minutos en aparecer. Esto significa que, si consultas una página, es posible que no se muestren los datos esperados antes de que haya pasado este plazo. En caso de no verlos, espera aproximadamente un minuto y, luego, actualiza la página.

La página Topología también tiene una gran demora inicial antes de mostrar los datos. El conjunto inicial de datos puede tardar hasta más de 5 minutos en estar disponible. Si ves un mensaje que indica que no hay datos, espera un momento y, luego, actualiza la página y regresa a la vista de topología.

En los párrafos anteriores, se te indica que esperes Y actualices la página. Como puedes ver, no solo los datos tardan un poco en llegar, sino que muchas páginas no mostrarán los datos disponibles sin que las actualices. Por lo tanto, si esperas que los datos estén disponibles y no los ves, asegúrate de actualizar la página en el navegador.

Consulta la información de enrutamiento en la vista de tabla

1. En el menú de navegación, selecciona Kubernetes Engine > Funciones > Malla de servicios.

   

Nota: Si no se muestra la vista de topología, actualiza la ventana del navegador.

2. Haz clic en el servicio productpage y, luego, selecciona Servicios conectados en el menú de la izquierda.

3. Selecciona la pestaña Saliente y observa los dos servicios que los Pods productpage llaman.

4. Haz clic en el servicio reviews.

   

5. Observa las estadísticas del servicio y luego selecciona el vínculo Infraestructura en el menú de la izquierda.

Puedes observar que hay varios Pods con ejecuciones de diferentes versiones de la lógica de reviews, que reciben tráfico enviado a este servicio.

6. Haz clic en Tráfico, en el menú de la izquierda, para consultar otra vista de su distribución.

   

   Puedes ver que hay una distribución relativamente uniforme del tráfico entre los tres Pods de backend que ejecutan las diferentes versiones de la lógica de la aplicación.

Consulta la información de enrutamiento en la vista de topología

1. Haz clic en el logotipo de Service Mesh, en la esquina superior izquierda, para volver a la página principal del panel.

Nota: Si aparece un mensaje de error que indica que no hay datos disponibles para usar en el gráfico o si ves un gráfico que no tiene todo el tráfico que deseas, espera entre 1 y 2 minutos y vuelve a intentarlo.

2. Reorganiza el gráfico de malla para que puedas ver con facilidad la siguiente información:

   • El servicio productpage dando lugar a la implementación productpage
   • La implementación productpage dando lugar al servicio reviews
   • El servicio reviews dando lugar a tres versiones de reviews

   

3. Haz clic en el nodo del servicio reviews y consulta los QPS relativos para cada versión de backend.

   

Tarea 5: Aplicar reglas de destino predeterminadas para todas las versiones disponibles

En esta tarea, definirás todas las versiones disponibles, llamadas subconjuntos, en reglas de destino.

1. Revisa la configuración que se encuentra en GitHub. Esta configuración define 4 recursos DestinationRule, 1 para cada servicio.

2. Aplica la configuración con el siguiente comando en Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/destination-rule-all.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' destination-rule-all.yaml kubectl apply -f destination-rule-all.yaml

   Resultado:

   destinationrule.networking.istio.io/productpage created destinationrule.networking.istio.io/reviews created destinationrule.networking.istio.io/ratings created destinationrule.networking.istio.io/details created

3. Comprueba que se hayan definido 4 recursos DestinationRule.

   kubectl get destinationrules

   Resultado:

   NAME HOST AGE details details 1m productpage productpage 1m ratings ratings 1m reviews reviews 1m

4. Revisa los detalles de las reglas de destino:

   kubectl get destinationrules -o yaml

   Observa que los subconjuntos, subsets, están definidos dentro de la especificación, spec, de una DestinationRule.

5. Espera entre 1 y 2 minutos y, luego, vuelve al panel de Service Mesh.

6. Observa las vistas de tabla y topología, y confirma que el tráfico se siga distribuyendo de manera uniforme entre las tres versiones de backend. Puedes hacer clic en MOSTRAR CRONOGRAMA para ajustar el período del gráfico. Esto te permite centrarte con más facilidad en los datos que te interesan.

Haz clic en Revisar mi progreso para verificar el objetivo. Aplicar reglas de destino.

Tarea 6: Aplicar servicios virtuales para enrutar el tráfico a una sola versión de forma predeterminada

En esta tarea, aplicarás servicios virtuales para cada servicio que enrute todo el tráfico a la versión "v1" de la carga de trabajo correspondiente.

1. Revisa la configuración que se encuentra en GitHub. Esta configuración define 4 recursos VirtualService, 1 para cada servicio.

2. Aplica la configuración con el siguiente comando en Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-all-v1.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-all-v1.yaml kubectl apply -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

   Como la propagación de la configuración tiene una coherencia eventual, espera unos segundos hasta que los servicios virtuales tengan efecto.

3. Comprueba que se hayan definido las 4 rutas de los recursos VirtualService con este comando:

   kubectl get virtualservices

   Resultado:

   NAME GATEWAYS HOSTS AGE bookinfo ["ingress/bookinfo-gateway"] ["*"] 19m details ["details"] 6s productpage ["productpage"] 7s ratings ["ratings"] 6s reviews ["reviews"] 7s

4. En Cloud Shell, obtén la dirección IP externa de la puerta de enlace de entrada:

   echo $GATEWAY_URL

5. Usa la IU de Bookinfo para probar la nueva configuración de enrutamiento.

   • Abre el sitio de Bookinfo en su navegador. La URL es http://[GATEWAY_URL]/productpage, en la que GATEWAY_URL corresponde a la dirección IP externa de la entrada.

   • Actualiza la página un par de veces para enviar varias solicitudes.

   Observa que la parte de la página sobre las opiniones de libros no muestra ninguna estrella de calificación, sin importar cuántas veces la actualices. Esto se debe a que configuraste la malla para enrutar todo el tráfico del servicio reviews a la versión reviews:v1, que no accede al servicio star ratings.

6. Espera entre 1 y 2 minutos y, luego, regresa al panel de Service Mesh. Para ello, navega a Menú de navegación > Kubernetes Engine > Malla de servicios > reviews > Infraestructura.

7. Selecciona MOSTRAR CRONOGRAMA y enfoca el gráfico en los últimos 5 minutos de tráfico. Deberías ver que el tráfico pasa de estar distribuido de forma uniforme a enrutarse a la carga de trabajo de la versión 1 todo el tiempo.

   

   También puedes ver la nueva distribución del tráfico en la pestaña Tráfico o la vista de topología, aunque ambas opciones tardan un par de minutos adicionales en mostrar los datos.

Haz clic en Revisar mi progreso para verificar el objetivo. Aplicar servicios virtuales.

Tarea 7: Enrutar el tráfico a una versión específica de un servicio según la identidad del usuario

En esta tarea, cambiarás la configuración de enrutamiento para que todo el tráfico de un usuario específico se envíe a una versión determinada del servicio. En este caso, todo el tráfico del usuario Jason se enrutará al servicio reviews:v2, la versión que incluye la función de calificación por estrellas.

Nota: Istio no tiene información integrada ni especial con respecto a la identidad del usuario. Este ejemplo es posible porque el servicio productpage agrega un encabezado "end-user" personalizado a todas las solicitudes HTTP salientes que se realizan al servicio reviews.

1. Revisa la configuración que se encuentra en GitHub. Esta configuración define 1 recurso VirtualService.

2. Aplica la configuración con el siguiente comando en Cloud Shell:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-test-v2.yaml kubectl apply -f virtual-service-reviews-test-v2.yaml

   Resultado:

   virtualservice.networking.istio.io/reviews configured

3. Confirma que se haya creado la regla con este comando:

   kubectl get virtualservice reviews

   Resultado:

   NAME GATEWAYS HOSTS AGE reviews ["reviews"] 35m

4. Usa la IU de Bookinfo para probar la nueva configuración de enrutamiento:

   • Vuelve a /productpage de la aplicación Bookinfo.

   • Esta vez, haz clic en Acceder y usa jason como nombre de usuario, con cualquier contraseña.

   • Observa que la IU muestra las estrellas del servicio ratings.

   Puedes salir y probar acceder como otros usuarios. Dejarás de ver estrellas con opiniones.

A fin de visualizar mejor el efecto del nuevo enrutamiento de tráfico, puedes crear una nueva carga en segundo plano de solicitudes autenticadas para el servicio.

5. Inicia una nueva sesión de Siege y produce solo el 20% del tráfico generado anteriormente, pero con todas las solicitudes autenticadas como jason:

   curl -c cookies.txt -F "username=jason" -L -X \ POST http://$GATEWAY_URL/login cookie_info=$(grep -Eo "session.*" ./cookies.txt) cookie_name=$(echo $cookie_info | cut -d' ' -f1) cookie_value=$(echo $cookie_info | cut -d' ' -f2) siege -c 5 http://$GATEWAY_URL/productpage \ --header "Cookie: $cookie_name=$cookie_value"

6. Espera entre 1 y 2 minutos, actualiza la página en la que se muestra la telemetría de infraestructura, ajusta la línea de tiempo para que muestre la hora actual y, luego, revisa el panel de Service Mesh. Allí, deberías ver que aproximadamente el 85% de las solicitudes de los últimos minutos se enviaron a la versión 1 porque no están autenticadas. Alrededor del 15% se enviaron a la versión dos porque se generaron como jason.

7. En Cloud Shell, presiona Ctrl + C para cancelar la sesión de Siege.

8. Quita los servicios virtuales de la aplicación para realizar la limpieza de este ejercicio:

   kubectl delete -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

9. Puedes esperar entre 1 y 2 minutos, actualizar el panel de Service Mesh, ajustar la línea de tiempo para mostrar la hora actual y confirmar que el tráfico se haya balanceado de manera uniforme entre todas las versiones.

   

Haz clic en Revisar mi progreso para verificar el objetivo. Configuración de enrutamiento específica del usuario.

Tarea 8: Cambiar gradualmente el tráfico de una versión de un microservicio a otra

En esta tarea, migrarás de forma gradual el tráfico de una versión de un microservicio a otra. Por ejemplo, puedes usar este enfoque para migrar tráfico de una versión anterior a una nueva.

Enviarás el 50% del tráfico a reviews:v1 y el otro 50% a reviews:v3. Luego, completarás la migración con el envío del 100% del tráfico a reviews:v3.

En Service Mesh, debes configurar una secuencia de reglas que enruten un porcentaje del tráfico a un servicio o a otro para lograr este objetivo.

1. En Cloud Shell, enruta todo el tráfico a la versión "v1" de cada servicio con este comando:

   kubectl apply -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Vuelve a /productpage de la aplicación Bookinfo y confirma que no ves estrellas con opiniones. Todo el tráfico se enruta al backend de la "v1".

3. Espera 1 minuto, actualiza el panel de Service Mesh, ajusta la línea de tiempo para que muestre la hora actual y confirma que todo el tráfico se haya enrutado al backend de la versión "v1".

4. Transfiere el 50% del tráfico de reviews:v1 de opiniones a reviews:v3.

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-50-v3.yaml kubectl apply -f virtual-service-reviews-50-v3.yaml

   Resultado:

   virtualservice.networking.istio.io/reviews configured

5. Vuelve a /productpage de la aplicación Bookinfo.

6. Actualiza la vista para enviar varias solicitudes.

   Observa una distribución aproximadamente uniforme de opiniones sin estrellas de la versión "v1" y opiniones con estrellas rojas de la versión "v3", la cual accede al servicio de calificaciones.

7. Espera 1 minuto, actualiza la página, ajusta la línea de tiempo para que muestre la hora actual y confirma en el panel de Service Mesh que el tráfico al servicio reviews se divide en un 50/50 entre "v1" y "v3".

   

8. Transfiere el 50% restante del tráfico a reviews:v3.

9. Suponiendo que decides que el servicio reviews:v3 es estable, enruta el 100% del tráfico a esa versión del servicio. Para ello, aplica este servicio virtual:

   wget https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking//virtual-service-reviews-v3.yaml sed -i 's#istio\.io/v1#istio\.io/v1alpha3#g' virtual-service-reviews-v3.yaml kubectl apply -f virtual-service-reviews-v3.yaml

   Resultado:

   virtualservice.networking.istio.io/reviews configured

10. Usa la IU de Bookinfo para probar la nueva configuración de enrutamiento.

11. Vuelve a /productpage de la aplicación Bookinfo.

12. Actualiza /productpage. Siempre verás opiniones sobre los libros con sus correspondientes calificaciones por estrellas de color rojo.

13. Espera 1 minuto, actualiza la página y, luego, confirma que el panel de Service Mesh muestre que todo el tráfico enviado al servicio reviews se haya dirigido a "v3".

    

14. Quita los servicios virtuales de la aplicación para realizar la limpieza de este ejercicio.

    kubectl delete -f virtual-service-all-v1.yaml

    Resultado:

    virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

En esta tarea, migraste el tráfico de una versión del servicio reviews anterior a una nueva mediante la característica de enrutamiento ponderado de Service Mesh. Esto es muy diferente de migrar las versiones con las funciones de implementación de las plataformas de organización de contenedores, que usan el escalamiento de instancias para administrar el tráfico.

Haz clic en Revisar mi progreso para verificar el objetivo. Migrar el tráfico de la versión "v1" a la versión "v3".

Tarea 9: Agregar tiempos de espera para evitar esperar indefinidamente las respuestas del servicio

Se puede especificar un tiempo de espera para las solicitudes HTTP con el campo de tiempo de espera de la regla de enrutamiento. De forma predeterminada, el tiempo de espera de la solicitud está inhabilitado, pero en esta tarea anularás el tiempo de espera del servicio de opiniones a 1 segundo. Sin embargo, para ver su efecto, también introduces un retraso artificial de 2 segundos en las llamadas al servicio de calificaciones. Comenzaremos por incluir el retraso.

1. En Cloud Shell, enruta todo el tráfico a la versión "v1" de cada servicio con este comando:

   kubectl apply -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Enruta las solicitudes a la versión "v2" del servicio de opiniones, es decir, una versión que llama al servicio de calificaciones:

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

3. Agrega un retraso de 2 segundos a las llamadas al servicio de calificaciones:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: ratings spec: hosts: - ratings http: - fault: delay: percent: 100 fixedDelay: 2s route: - destination: host: ratings subset: v1 EOF

4. Abre la URL de Bookinfo http://$GATEWAY_URL/productpage en tu navegador. Deberías ver que la aplicación Bookinfo funciona con normalidad (con las estrellas de calificación), pero hay un retraso de 2 segundos cada vez que actualizas la página. (Si la aplicación Bookinfo no funciona con normalidad, cambia el retraso a 1 segundo y vuelve a intentarlo).

5. Navega a las opiniones o las métricas para ver que la latencia aumenta repentinamente a 2 segundos. (Si cambiaste el retraso a 1 segundo, la latencia debería aumentar repentinamente a 1 segundo).

   

6. Ahora, agrega un tiempo de espera de solicitud de medio segundo para las llamadas al servicio de opiniones:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: reviews spec: hosts: - reviews http: - route: - destination: host: reviews subset: v2 timeout: 0.5s EOF

7. Actualiza la página web de Bookinfo.

Ahora deberías ver que se devuelve en aproximadamente 1 segundo, en lugar de 2, y que las opiniones no están disponibles.

Nota: La respuesta tarda 1 segundo, aunque el tiempo de espera se configuró en medio segundo, porque hay un reintento hard-coded en el servicio de productpage, por lo que llama al servicio reviews con tiempo de espera dos veces antes de devolver la respuesta. Si quieres cambiar el parámetro de configuración de reintentos, configura el VirtualService ejecutando el comando que se muestra a continuación. kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: productpage spec: hosts: - productpage http: - route: - destination: host: productpage subset: v1 retries: attempts: 1 perTryTimeout: 2s EOF

8. Quita los servicios virtuales de la aplicación para realizar la limpieza de este ejercicio.

   kubectl delete -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io "productpage" deleted virtualservice.networking.istio.io "reviews" deleted virtualservice.networking.istio.io "ratings" deleted virtualservice.networking.istio.io "details" deleted

En esta tarea, usaste Istio para establecer el tiempo de espera de las solicitudes de llamadas al microservicio de revisiones en medio segundo. De forma predeterminada, el tiempo de espera de la solicitud está inhabilitado. Dado que el servicio reviews llama posteriormente al servicio de calificaciones cuando controla solicitudes, usaste Istio para inyectar un retraso de 2 segundos en las llamadas a calificaciones para que el servicio reviews tardara más de medio segundo en completarse y, en consecuencia, pudieras ver el tiempo de espera en acción.

Observaste que, en lugar de mostrar opiniones, la página de productos de Bookinfo (que llama al servicio reviews para propagar la página) mostraba el mensaje "Lo sentimos, las opiniones sobre productos no están disponibles para este libro en este momento". Este fue el resultado de recibir el error de tiempo de espera del servicio reviews.

Haz clic en Revisar mi progreso para verificar el objetivo. Agregar tiempos de espera para el servicio de calificación.

Tarea 10: Agregar disyuntores para mejorar la resiliencia de tus microservicios

En esta tarea, se muestra cómo configurar la interrupción de circuitos para las conexiones, las solicitudes y la detección de valores atípicos.

La interrupción de circuitos es un patrón importante para crear aplicaciones de microservicios resilientes. La interrupción de circuitos te permite escribir aplicaciones que limitan el impacto de las fallas, los aumentos repentinos de la latencia y otros efectos no deseados de las peculiaridades de la red.

En esta tarea, configurarás reglas de interrupción de circuitos y, luego, probarás la configuración "activando" intencionalmente el disyuntor.

1. En Cloud Shell, enruta todo el tráfico a la versión "v1" de cada servicio con este comando:

   kubectl apply -f virtual-service-all-v1.yaml

   Resultado:

   virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created

2. Crea una regla de destino para aplicar la configuración de interrupción de circuitos cuando se llame al servicio productpage:

   kubectl apply -f - <<EOF apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: productpage spec: host: productpage subsets: - name: v1 labels: version: v1 trafficPolicy: connectionPool: tcp: maxConnections: 1 http: http1MaxPendingRequests: 1 maxRequestsPerConnection: 1 outlierDetection: consecutive5xxErrors: 1 interval: 1s baseEjectionTime: 3m maxEjectionPercent: 100 EOF

3. En Cloud Shell, ve a la primera pestaña y ejecuta Ctrl+C para detener el comando siege.

4. Crea un cliente para enviar tráfico al servicio productpage.

El cliente es un cliente de prueba de carga simple llamado fortio. Fortio te permite controlar la cantidad de conexiones, la simultaneidad y los retrasos de las llamadas HTTP salientes. Usarás este cliente para "activar" las políticas del disyuntor que estableciste en DestinationRule:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.9/samples/httpbin/sample-client/fortio-deploy.yaml

5. Accede al pod del cliente y usa la herramienta fortio para llamar a productpage. Pasa curl para indicar que solo quieres hacer una llamada:

   export FORTIO_POD=$(kubectl get pods -lapp=fortio -o 'jsonpath={.items[0].metadata.name}') kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio curl -quiet http://${GATEWAY_URL}/productpage

6. Llama al servicio con dos conexiones simultáneas (-c 2) y envía 20 solicitudes (-n 20):

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 2 -qps 0 -n 20 -loglevel Warning http://${GATEWAY_URL}/productpage

   Es interesante ver que casi todas las solicitudes se completaron. Esto es interesante porque maxConnections: 1 y http1MaxPendingRequests: 1. Estas reglas indican que, si superas más de una conexión y solicitud de forma simultánea, deberías ver algunos errores cuando istio-proxy abra el circuito para más solicitudes y conexiones.

   Sin embargo, vemos que istio-proxy permite cierta flexibilidad:

   Code 200 : 17 (85.0 %) Code 503 : 3 (15.0 %)

7. Aumenta la cantidad de conexiones simultáneas a 3:

   kubectl exec "$FORTIO_POD" -c fortio -- /usr/bin/fortio load -c 3 -qps 0 -n 30 -loglevel Warning http://${GATEWAY_URL}/productpage

   Ahora comenzarás a ver el comportamiento esperado de interrupción del circuito. Solo el 36.7% de las solicitudes se completaron correctamente, y el resto se detuvieron por la interrupción del circuito:

   Code 200 : 11 (36.7 %) Code 503 : 19 (63.3 %)

Haz clic en Revisar mi progreso para verificar el objetivo. Agregar disyuntores.

Revisión

En este lab, aprendiste distintas maneras de administrar y enrutar tráfico con diferentes objetivos. También probaste ajustar y visualizar tú mismo el cambio del tráfico, incluido el enrutamiento de la capa 7 (de aplicación), que revisa los encabezados de la solicitud.

Próximos pasos

• Más información sobre la administración del tráfico de Istio
• Más información sobre las implementaciones de versiones canary con Istio

Finaliza el lab

Cuando hayas completado el lab, haz clic en Finalizar lab. Google Skills quitará los recursos que usaste y limpiará la cuenta.

Tendrás la oportunidad de calificar tu experiencia en el lab. Selecciona la cantidad de estrellas que corresponda, ingresa un comentario y haz clic en Enviar.

La cantidad de estrellas indica lo siguiente:

• 1 estrella = Muy insatisfecho
• 2 estrellas = Insatisfecho
• 3 estrellas = Ni satisfecho ni insatisfecho
• 4 estrellas = Satisfecho
• 5 estrellas = Muy satisfecho

Puedes cerrar el cuadro de diálogo si no deseas proporcionar comentarios.

Para enviar comentarios, sugerencias o correcciones, usa la pestaña Asistencia.

Copyright 2026 Google LLC. Todos los derechos reservados. Google y el logotipo de Google son marcas de Google LLC. El resto de los nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que están asociados.