Integración con AWS

Este documento explica cómo integrar Istio con servicios de AWS en un entorno de Amazon EKS.

Índice

Integración con AWS Load Balancer

Istio Ingress Gateway puede integrarse con AWS Load Balancer para manejar tráfico externo.

Integración con Network Load Balancer (NLB)

NLB es un balanceador de carga de capa 4 (TCP/UDP), adecuado cuando se requiere alto rendimiento y baja latencia.

Arquitectura de NLB

Configuración de NLB

1. Instalar AWS Load Balancer Controller

bash

# Create IAM policy
curl -o iam_policy.json https://raw.githubusercontent.com/kubernetes-sigs/aws-load-balancer-controller/main/docs/install/iam_policy.json

aws iam create-policy \
    --policy-name AWSLoadBalancerControllerIAMPolicy \
    --policy-document file://iam_policy.json

# IRSA setup
eksctl create iamserviceaccount \
  --cluster=my-cluster \
  --namespace=kube-system \
  --name=aws-load-balancer-controller \
  --attach-policy-arn=arn:aws:iam::<AWS_ACCOUNT_ID>:policy/AWSLoadBalancerControllerIAMPolicy \
  --override-existing-serviceaccounts \
  --approve

# Install controller with Helm
helm repo add eks https://aws.github.io/eks-charts
helm repo update

helm install aws-load-balancer-controller eks/aws-load-balancer-controller \
  -n kube-system \
  --set clusterName=my-cluster \
  --set serviceAccount.create=false \
  --set serviceAccount.name=aws-load-balancer-controller

2. Configuración de Istio Ingress Gateway con NLB

yaml

# istio-ingress-nlb.yaml
apiVersion: v1
kind: Service
metadata:
  name: istio-ingressgateway
  namespace: istio-system
  annotations:
    # NLB configuration
    service.beta.kubernetes.io/aws-load-balancer-type: "external"
    service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: "ip"
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"

    # TLS configuration
    service.beta.kubernetes.io/aws-load-balancer-ssl-cert: "arn:aws:acm:region:account:certificate/cert-id"
    service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "443"
    service.beta.kubernetes.io/aws-load-balancer-backend-protocol: "tcp"

    # Health check configuration
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: "http"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "15021"
    service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/healthz/ready"

    # Additional configuration
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
    service.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"
spec:
  type: LoadBalancer
  selector:
    app: istio-ingressgateway
    istio: ingressgateway
  ports:
  - name: status-port
    port: 15021
    protocol: TCP
    targetPort: 15021
  - name: http2
    port: 80
    protocol: TCP
    targetPort: 8080
  - name: https
    port: 443
    protocol: TCP
    targetPort: 8443

3. Configuración del recurso Gateway

yaml

apiVersion: networking.istio.io/v1
kind: Gateway
metadata:
  name: my-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: my-tls-secret
    hosts:
    - "myapp.example.com"
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "myapp.example.com"
    tls:
      httpsRedirect: true

Ventajas de NLB

Alto rendimiento: Maneja millones de solicitudes por segundo
Baja latencia: Opera en la capa 4 para obtener respuestas rápidas
IP estática: Es posible asignar Elastic IP
Compatibilidad de protocolos: TCP, UDP, TLS
Rentable: Más económico que ALB

Casos de uso de NLB

WebSocket, gRPC y otras conexiones de larga duración
Manejo de millones de solicitudes por segundo
Cuando se requiere una IP estática
Cuando la terminación TLS debe realizarse en Istio

Integración con Application Load Balancer (ALB)

ALB es un balanceador de carga de capa 7 (HTTP/HTTPS), adecuado cuando se necesitan características avanzadas de enrutamiento.

Arquitectura de ALB

Configuración de ALB

1. Crear ALB con el recurso Ingress

yaml

# istio-ingress-alb.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: istio-ingress
  namespace: istio-system
  annotations:
    # ALB configuration
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
    alb.ingress.kubernetes.io/listen-ports: '[{"HTTP": 80}, {"HTTPS": 443}]'
    alb.ingress.kubernetes.io/ssl-redirect: '443'

    # ACM certificate
    alb.ingress.kubernetes.io/certificate-arn: arn:aws:acm:region:account:certificate/cert-id

    # Health check
    alb.ingress.kubernetes.io/healthcheck-protocol: HTTP
    alb.ingress.kubernetes.io/healthcheck-port: '15021'
    alb.ingress.kubernetes.io/healthcheck-path: /healthz/ready
    alb.ingress.kubernetes.io/healthcheck-interval-seconds: '15'
    alb.ingress.kubernetes.io/healthcheck-timeout-seconds: '5'
    alb.ingress.kubernetes.io/success-codes: '200'
    alb.ingress.kubernetes.io/healthy-threshold-count: '2'
    alb.ingress.kubernetes.io/unhealthy-threshold-count: '2'

    # Additional configuration
    alb.ingress.kubernetes.io/load-balancer-attributes: idle_timeout.timeout_seconds=60
    alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=30
spec:
  ingressClassName: alb
  rules:
  - host: "myapp.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80

2. Enrutamiento basado en rutas

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: istio-ingress-path-based
  namespace: istio-system
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip
spec:
  ingressClassName: alb
  rules:
  - host: "api.example.com"
    http:
      paths:
      - path: /v1
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80
  - host: "admin.example.com"
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80

Ventajas de ALB

Enrutamiento avanzado: Enrutamiento basado en rutas, Header y Query String
Integración con WAF: Seguridad mejorada con AWS WAF
Integración de autenticación: Integración con Cognito y OIDC
Integración con ACM: Gestión automática de certificados
Optimizado para contenedores: Optimizado para ECS y EKS

Casos de uso de ALB

Tráfico solo HTTP/HTTPS
Cuando se necesita enrutamiento basado en rutas
Cuando se requiere seguridad de WAF
Cuando se manejan varios dominios con un único balanceador de carga

Comparación entre NLB y ALB

Propiedad	NLB	ALB
Capa OSI	Capa 4 (TCP/UDP)	Capa 7 (HTTP/HTTPS)
Rendimiento	Millones de solicitudes por segundo	Decenas de miles de solicitudes por segundo
Latencia	Muy baja	Baja
IP estática	Compatible (Elastic IP)	No compatible
Terminación TLS	Se transmite como TCP (gestionada en Istio)	Puede gestionarse en ALB
Enrutamiento	Basado en IP/puerto	Basado en ruta, Host y Header
Integración con WAF	No disponible	Disponible
Costo	Menor	Relativamente mayor
WebSocket	Compatibilidad nativa	Compatible
gRPC	Compatibilidad nativa	Requiere HTTP/2
Uso recomendado	Alto rendimiento, WebSocket, gRPC	Enrutamiento HTTP, WAF, autenticación

Comparación entre Istio y otras soluciones

Istio frente a VPC Lattice

VPC Lattice es el servicio administrado de redes de aplicaciones de AWS.

Comparación de arquitectura

Comparación de características

Propiedad	Istio	VPC Lattice
Administración	Autogestionado	Administrado por AWS (Fully-managed)
Sidecar	Obligatorio (Sidecar o Ambient)	No obligatorio
Sobrecarga de recursos	Alta (Envoy por Pod)	Baja (sin sidecar)
Complejidad	Alta	Baja
Curva de aprendizaje	Pronunciada	Suave
Gestión de tráfico	Muy avanzada (control detallado)	Básica (características suficientes)
mTLS	Automático, control detallado	Compatible
Observabilidad	Métricas y trazas completas	Métricas básicas
Inyección de fallos	Compatible	No compatible
Circuit Breaker	Control detallado	Funcionalidad básica
Rate Limiting	Local + Global	Funcionalidad básica
Multi-cluster	Gran compatibilidad	Conectividad entre VPC
Cross-account	Complejo	Simple (compatibilidad nativa)
Costo	Costo de cómputo (EC2)	Costo por uso del servicio
Vendor Lock-in	Ninguno (open source)	Dependencia de AWS
Solo Kubernetes	Sí	No (EC2, Lambda, etc.)

Cuándo elegir Istio

Istio es adecuado cuando:

Se necesita control detallado del tráfico
- Despliegue canary, pruebas A/B, Traffic Mirroring
- Reglas de enrutamiento complejas (basadas en Header, Cookie, etc.)
- Inyección de fallos para Chaos Engineering
Se tienen requisitos de seguridad estrictos
- Cifrado mTLS automático entre servicios
- Políticas de autorización detalladas
- Validación de JWT, RBAC
Se necesita observabilidad avanzada
- Métricas detalladas (latencia P50/P95/P99)
- Trazabilidad distribuida (Jaeger, Zipkin)
- Visualización de la topología de servicios (Kiali)
Service Mesh Multi-cluster
- Comunicación entre varios clústeres EKS
- Failover entre clústeres
- Balanceo de carga global
Independencia del proveedor
- Posibilidad de migrar a otras nubes o entornos on-premises
- Uso de estándares de Kubernetes

Ejemplo: gestión avanzada del tráfico de Istio

yaml

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  # Header-based routing
  - match:
    - headers:
        user-agent:
          regex: ".*Mobile.*"
    route:
    - destination:
        host: reviews
        subset: mobile-v2
  # Canary deployment (10%)
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: reviews
        subset: v3
      weight: 10
    - destination:
        host: reviews
        subset: v2
      weight: 90
  # Traffic Mirroring
  - route:
    - destination:
        host: reviews
        subset: v2
    mirror:
      host: reviews
      subset: v3
    mirrorPercentage:
      value: 100

Cuándo elegir VPC Lattice

VPC Lattice es adecuado cuando:

Conectividad de servicios sencilla
- Solo se necesita balanceo de carga y enrutamiento básicos
- Es importante una implementación rápida
Baja sobrecarga operativa
- Se prefieren servicios administrados por AWS
- No hay carga de administrar sidecars
Comunicación entre VPC/cuentas
- Conexión de servicios entre varias cuentas de AWS
- Comunicación sin VPC peering
Entornos mixtos
- Entornos mixtos de EKS + EC2 + Lambda
- Uso de diversos tipos de cómputo además de Kubernetes
Optimización de costos
- Reducción de los costos de recursos de sidecar
- Servicios a pequeña escala

Uso conjunto de Istio y VPC Lattice

Las dos soluciones no son mutuamente excluyentes y pueden utilizarse juntas:

Casos de uso:

Dentro del clúster: Istio para la gestión detallada del tráfico y la seguridad
Entre clústeres/entre cuentas: VPC Lattice para conectividad sencilla
Entornos mixtos: Usar VPC Lattice para conectar clústeres de Istio con Lambda/EC2

Istio frente a Cilium (basado en eBPF)

Cilium es una solución de redes y seguridad para Kubernetes que usa eBPF.

Comparación de arquitectura

Propiedad	Istio	Cilium
Stack tecnológico	Envoy Proxy (sidecar)	eBPF (nivel de kernel)
Propósito principal	Service Mesh	CNI + Service Mesh
Redes	Opera sobre Kubernetes CNI	Proporciona CNI
Rendimiento	Bueno	Excelente (nivel de kernel)
Uso de recursos	Alto (sidecar)	Bajo (nivel de kernel)
Características L7	Muy potentes	Básicas
Observabilidad	Completa	Hubble (básica)
Curva de aprendizaje	Pronunciada	Pronunciada
Madurez	Alta	Media (características de Service Mesh)

Comparación de características

Característica	Istio	Cilium
Network Policy	Kubernetes + Istio	Kubernetes + Cilium (más potente)
Balanceo de carga L7	Muy detallado	Básico
mTLS	Automático, control detallado	Compatible
Gestión de tráfico	Muy avanzada	Básica
Observabilidad	Prometheus, Jaeger, Kiali	Hubble
Rendimiento	Bueno	Excelente
Multi-cluster	Fuerte	Cluster Mesh

Cuándo elegir cada opción

Elegir Istio:

La gestión de tráfico L7 es un requisito fundamental
Se necesitan potentes características de Service Mesh
Se necesitan herramientas completas de observabilidad y depuración

Elegir Cilium:

Se considera reemplazar CNI
La seguridad de red es la principal preocupación
La optimización del rendimiento es importante
Se desea aprovechar la tecnología eBPF

Uso conjunto:

Se puede usar Cilium como CNI e Istio como Service Mesh
Sin embargo, se debe considerar la superposición de características y la mayor complejidad

Optimización específica para EKS

Integración de IAM Roles for Service Accounts (IRSA)

Configure IRSA para permitir que las cargas de trabajo de Istio accedan de forma segura a servicios de AWS.

Configuración de IRSA

bash

# 1. Create OIDC provider
eksctl utils associate-iam-oidc-provider \
    --cluster my-cluster \
    --approve

# 2. Create IAM policy
cat <<EOF > app-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::my-bucket",
                "arn:aws:s3:::my-bucket/*"
            ]
        }
    ]
}
EOF

aws iam create-policy \
    --policy-name MyAppS3Policy \
    --policy-document file://app-policy.json

# 3. Link IAM Role to Service Account
eksctl create iamserviceaccount \
    --cluster my-cluster \
    --namespace default \
    --name my-app-sa \
    --attach-policy-arn arn:aws:iam::<ACCOUNT_ID>:policy/MyAppS3Policy \
    --approve

Uso de Istio con IRSA

yaml

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: default
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::<ACCOUNT_ID>:role/my-app-role
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      serviceAccountName: my-app-sa  # Using IRSA
      containers:
      - name: app
        image: my-app:latest
        env:
        - name: AWS_REGION
          value: us-west-2