Domina la Arquitectura de Malla de Servicios con Istio

1. Introducción

Descubre la magia de la arquitectura de malla de servicios y observa cómo potencia tus sistemas distribuidos.

Sumérgete en Istio, la superestrella de la malla de servicios, y aprende cómo orquesta tu clúster de Kubernetes a la perfección.

2. ¿Qué es una Malla de Servicios?

Las aplicaciones monolíticas han evolucionado hacia servicios más pequeños e independientes. Este cambio ganó una inmensa popularidad con la computación en la nube y la arquitectura de microservicios. Herramientas como Docker y Kubernetes aceleraron esta tendencia.

Los microservicios en plataformas como Kubernetes ofrecen numerosos beneficios, pero también introducen complejidades. La gestión de la comunicación entre estos servicios distribuidos requiere un cuidadoso análisis del descubrimiento, el enrutamiento, los reintentos y la conmutación por error.

Desafíos adicionales incluyen la seguridad y la observabilidad.

Estos proxies forman una red de malla para los servicios, de ahí el nombre. La malla de servicios controla todos los aspectos de la comunicación de servicio a servicio, lo que le permite abordar las ocho falacias de la computación distribuida.

4. Istio Desvelado

Istio, una malla de servicios de código abierto creada por IBM, Google y Lyft, mejora invisiblemente las aplicaciones distribuidas con gestión del tráfico, seguridad e información sobre el rendimiento.

Implementado de forma flexible on-premise, en la nube, dentro de Kubernetes o en máquinas virtuales, Istio brilla con microservicios en Kubernetes. Aunque es independiente de la plataforma, encaja perfectamente en entornos en contenedores.

En esencia, Istio implementa proxies Envoy como sidecars junto con cada microservicio:

Esta red de proxies forma el plano de datos de Istio, orquestado por el plano de control:

La adaptabilidad de Istio brilla a través de la integración perfecta con sistemas externos de registro, telemetría y políticas.

5. Desentrañando los Bloques de Construcción de Istio

La arquitectura de Istio es un dúo dinámico: el plano de datos y el plano de control. Juntos, orquestan la magia detrás de las capacidades de Istio. Profundicemos en los componentes centrales que impulsan esta plataforma excepcional.

Prepárate para explorar los intrincados detalles de los componentes centrales de Istio.

5.1. El Plano de Datos: El Epicentro de Envoy

El plano de datos de Istio es esencialmente una versión amplificada del proxy Envoy. Esta maravilla de código abierto maneja las complejidades de la red, liberando a las aplicaciones para que se centren en su negocio principal. Las aplicaciones interactúan sin problemas, ajenas a la compleja infraestructura de red.

En esencia, Envoy es un asistente de red que opera en las capas 3 y 4 del modelo OSI. Gestiona hábilmente las conexiones utilizando una cadena de filtros de red adaptables. Más allá de esto, el filtro de capa L7 de Envoy le permite manejar el tráfico HTTP con delicadeza. Y eso no es todo: es natural con los protocolos HTTP/2 y gRPC.

Muchas de las características destacadas de Istio son en realidad superpoderes heredados de las habilidades integradas de Envoy:

• Control de tráfico: Envoy ejerce un control granular sobre el tráfico HTTP, gRPC, WebSocket y TCP, enrutándolo con precisión.
• Resiliencia de la red: Los reintentos automáticos integrados, la interrupción del circuito y la inyección de fallos garantizan una fiabilidad de la red inquebrantable.
• Seguridad: Protege tu comunicación con sólidas políticas de seguridad, control de acceso y limitación de velocidad.

El verdadero potencial de Envoy brilla cuando se combina con Istio. Su extensibilidad, impulsada por WebAssembly, cambia las reglas del juego para la aplicación de políticas personalizadas y la telemetría. Además, la API de sandbox Proxy-Wasm de Istio abre las puertas a aún más personalizaciones de Envoy.

5.2. El Plano de Control: El Maestro de Istiod

Conoce a istiod, el director de orquesta del plano de control de Istio. Este maestro transforma las reglas de enrutamiento de alto nivel y las directivas de gestión del tráfico en configuraciones amigables para Envoy, distribuyéndolas sin problemas a los sidecars.

¿Recuerdas la arquitectura anterior de Istio con sus componentes individuales? Bueno, para simplificar las cosas, estos componentes se fusionaron en el istiod unificado. Pero no temas, las funcionalidades principales permanecen intactas.

En esencia, istiod aprovecha el mismo código y API que sus predecesores. Pilot, por ejemplo, sigue siendo el maestro del descubrimiento de servicios, traduciendo los detalles específicos de la plataforma a un lenguaje universal que entienden los sidecars. Esta flexibilidad permite que Istio armonice con diversos entornos como Kubernetes y máquinas virtuales.

istiod también se encarga de la seguridad, estableciendo una sólida autenticación de servicio a servicio y de usuario final con su sistema integrado de gestión de identidades y credenciales. Aplica políticas de seguridad granulares basadas en la identidad del servicio con facilidad. Además, istiod funciona como una autoridad de certificación (CA) de confianza, emitiendo certificados para asegurar la comunicación entre servicios mediante TLS mutuo (MTLS).

6. Cómo Funciona Istio

Hemos explorado las características típicas de una malla de servicios y hemos analizado la arquitectura y los componentes centrales de Istio. Ahora, descubramos cómo Istio ofrece estas características utilizando sus componentes centrales.

Volveremos a visitar las mismas categorías de características que exploramos anteriormente.

6.1. Gestión del Tráfico

La API de gestión del tráfico de Istio ofrece un control granular sobre el tráfico de la malla de servicios. Adapta las configuraciones de tráfico utilizando estas API y define los recursos de la API con las definiciones de recursos personalizados de Kubernetes (CRD). Los recursos clave de la API para el enrutamiento del tráfico son los servicios virtuales y las reglas de destino:

Un servicio virtual dicta cómo se enrutan las solicitudes a un servicio dentro de la malla de Istio. Comprende una o más reglas de enrutamiento que se evalúan secuencialmente. Después del enrutamiento del servicio virtual, se aplican reglas de destino para controlar el tráfico a un destino, como agrupar instancias de servicio por versión.

6.2. Seguridad

La base de seguridad de Istio son identidades sólidas para cada servicio. Los agentes de Istio junto con cada proxy Envoy colaboran con istiod para automatizar la rotación de claves y certificados:

Istio admite dos tipos de autenticación: autenticación de pares y autenticación de solicitudes. La autenticación de pares asegura la comunicación de servicio a servicio con la solución TLS mutua de Istio. La autenticación de solicitudes maneja la autenticación del usuario final a través de la validación de tokens web JSON (JWT) utilizando un proveedor de autenticación personalizado o un proveedor OpenID Connect (OIDC).

Istio aplica el control de acceso al servicio aplicando políticas de autorización. Estas políticas regulan el tráfico entrante en el proxy Envoy, lo que permite el control de acceso a nivel de malla, espacio de nombres y servicio.

6.3. Observabilidad

Istio genera telemetría completa, que incluye métricas, seguimientos distribuidos y registros de acceso, para toda la comunicación de servicio dentro de la malla. Esta telemetría abarca métricas a nivel de proxy, orientadas al servicio y del plano de control.

Anteriormente, Mixer era el componente central de la arquitectura de telemetría de Istio. Sin embargo, Telemetry v2 reemplaza las funciones de Mixer con complementos de proxy Envoy:

Istio crea seguimientos distribuidos a través de proxies Envoy y admite varios backends de rastreo como Zipkin, Jaeger, Lightstep y Datadog. La frecuencia de muestreo de la generación de rastreo es configurable. Además, Istio genera registros de acceso para el tráfico de servicios en formatos personalizables.

7. Sumérgete en Istio

Suficiente información general, ¡veamos Istio en acción! Instalaremos Istio en un clúster de Kubernetes y usaremos una aplicación de microservicios simple para mostrar su potencia.

7.1 Instalación

Istio se instala de varias maneras, pero descargar y extraer la última versión para tu sistema operativo (como Windows) es lo más fácil. El paquete extraído incluye el cliente istioctl en la carpeta bin. Usa istioctl para instalar Istio en tu clúster de Kubernetes:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

Estamos usando kubectl aquí, suponiendo que tienes un clúster de Kubernetes (como Minikube) y la CLI de Kubernetes kubectl configurada.

7.2 Aplicación de Muestra

Imagina una aplicación de pedidos en línea simple para esta demostración. Consta de tres microservicios que funcionan juntos para completar los pedidos:

No profundizaremos en los detalles de los microservicios, pero son fáciles de crear con Spring Boot y API REST. Fundamentalmente, crea imágenes de Docker para estos microservicios para implementar en Kubernetes.

7.3 Implementación

Implementar cargas de trabajo en contenedores en clústeres de Kubernetes como Minikube es simple. Usa los recursos de implementación y servicio para declarar y acceder a la carga de trabajo. Normalmente, defínelos en un archivo YAML:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

Dado que habilitamos la inyección automática de proxies sidecar Envoy para el espacio de nombres predeterminado, todo está controlado. O inyecta manualmente proxies sidecar Envoy usando el comando kube-inject de istioctl.

7.4 Acceso a la Aplicación

Istio maneja principalmente el tráfico de malla. De forma predeterminada, el tráfico hacia o desde fuera de la malla está bloqueado. Istio utiliza puertas de enlace para gestionar el tráfico de malla entrante y saliente, lo que te da un control preciso sobre lo que entra o sale. Istio ofrece implementaciones de proxy de puerta de enlace preconfiguradas: istio-ingressgateway e istio-egressgateway.

Crea una puerta de enlace y un servicio virtual para tu aplicación:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 Casos de Uso Comunes de Istio

Hemos implementado una aplicación simple en Kubernetes con Istio. Exploremos las potentes funciones de Istio y veamos cómo pueden mejorar nuestra aplicación.

8.1 Enrutamiento de Solicitudes

Imagina implementar múltiples versiones de un microservicio como el servicio de envío. Deseas introducir gradualmente nuevas funciones sin afectar a todos los usuarios. El enrutamiento de solicitudes te permite hacer esto dirigiendo una parte del tráfico a la última versión.

Utiliza reglas de enrutamiento de servicio virtual para lograr esto.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

Las reglas de enrutamiento también pueden filtrar el tráfico en función de los encabezados u otros atributos. El campo de destino especifica el servicio de destino para las solicitudes coincidentes.

8.2 Interrupción del Circuito

Evita fallos en cascada con interruptores de circuito. Este patrón detecta errores y detiene temporalmente el tráfico a los servicios que fallan, protegiendo la salud general de tu aplicación.

DestinationRule de Istio te permite configurar el comportamiento de interrupción del circuito para servicios como el servicio de inventario.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

Al limitar las conexiones máximas, las solicitudes pendientes y las solicitudes por conexión, puedes gestionar eficazmente el tráfico y evitar la sobrecarga.

8.3 Habilitación de TLS Mutuo

El TLS mutuo garantiza una comunicación segura entre servicios al requerir que ambas partes se autentiquen. Istio habilita automáticamente el TLS mutuo para los servicios que utilizan sus proxies.

Si bien Istio aplica el TLS mutuo entre los servicios proxy, el tráfico de texto sin formato aún puede llegar a los servicios sin proxies. Utiliza las políticas de PeerAuthentication para aplicar el TLS mutuo en toda tu malla.

apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT

Puedes aplicar TLS mutuo a nivel de malla, espacio de nombres o servicio. Las políticas específicas del servicio anulan la configuración de todo el espacio de nombres.

8.4 Control de Acceso con JWT

Los tokens web JSON (JWT) son un estándar para transmitir de forma segura la información del usuario. Se utilizan ampliamente para la autenticación y autorización.

AuthorizationPolicy de Istio te permite controlar el acceso a servicios como el servicio de reservas en función de las reclamaciones de JWT.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

Requiere JWT válidos con reclamaciones específicas para el acceso autorizado. Istio crea un atributo requestPrincipal a partir de las reclamaciones del emisor y del sujeto del JWT.

9. Reflexiones Finales

Istio simplifica la gestión de los desafíos comunes en arquitecturas distribuidas de microservicios. Sin embargo, su complejidad puede agregar sobrecarga a las implementaciones. Como cualquier herramienta, Istio no es una solución mágica y requiere una evaluación cuidadosa.

9.1. ¿Es Siempre Necesaria una Malla de Servicios?

Si bien las mallas de servicios ofrecen ventajas, ten en cuenta estos inconvenientes:

Las mallas de servicios ofrecen beneficios, pero es crucial una evaluación cuidadosa de la complejidad de tu aplicación. Sopesa las ventajas frente a la complejidad añadida.

9.2. Alternativas a Istio

Istio es una malla de servicios popular respaldada por líderes de la industria, pero no es la única opción. Aquí tienes una breve descripción general de Linkerd y Consul.

Linkerd es una malla de servicios de código abierto nativa de Kubernetes que está ganando popularidad. Es un proyecto de incubación de CNCF y funciona de manera similar a Istio, utilizando proxies TCP. El micro-proxy basado en Rust de Linkerd se llama Linkerd-proxy.

Linkerd es generalmente más simple que Istio debido a su enfoque en Kubernetes. Sin embargo, su conjunto de características se parece mucho al de Istio y su arquitectura central es similar. Linkerd consta de una interfaz de usuario, un plano de datos y un plano de control.

Consul es una malla de servicios de código abierto de HashiCorp que se integra con otras herramientas de infraestructura de HashiCorp. El plano de datos de Consul admite modelos de integración tanto proxy como nativos. Ofrece un proxy integrado pero también puede funcionar con Envoy.

Consul opera más allá de Kubernetes, admitiendo plataformas como Nomad. Utiliza agentes en cada nodo para verificaciones de estado y se comunica con los servidores de Consul para el almacenamiento y la replicación de datos. Si bien ofrece características estándar de malla de servicios, Consul es más complejo de implementar y gestionar.

10. Resumen

Este tutorial ha explorado los fundamentos de la arquitectura de malla de servicios y las potentes capacidades de Istio. Hemos profundizado en la estructura central de Istio, los componentes y las aplicaciones prácticas. Al final, deberías tener una sólida comprensión de cómo instalar y utilizar Istio para escenarios comunes.