Integración con AWS

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

Tabla de contenidos

Integración con AWS Load Balancer

Istio Ingress Gateway puede integrarse con AWS Load Balancer para gestionar el 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: Gestiona millones de solicitudes por segundo
Baja latencia: Opera en la Capa 4 para ofrecer 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
Gestión de millones de solicitudes por segundo
Cuando se requiere una IP estática
Cuando la terminación de 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 funciones avanzadas de enrutamiento.

Arquitectura de ALB

Configuración de ALB

1. Crear ALB con un 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 requiere enrutamiento basado en rutas
Cuando se requiere seguridad de WAF
Cuando se gestionan 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	Paso directo como TCP (gestionado en Istio)	Puede gestionarse en ALB
Enrutamiento	Basado en IP/Port	Basado en Path, Host y Header
Integración 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 de Istio con otras soluciones

Istio vs VPC Lattice

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

Comparación de arquitecturas

Comparación de características

Propiedad	Istio	VPC Lattice
Administración	Autoadministrado	Administrado por AWS (Fully-managed)
Sidecar	Requerido (Sidecar o Ambient)	No requerido
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 (funciones suficientes)
mTLS	Automático, control detallado	Compatible
Observabilidad	Métricas y trazas enriquecidas	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	Compatibilidad sólida	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 de tráfico detallado
- Canary deployment, pruebas A/B, Traffic Mirroring
- Reglas de enrutamiento complejas (basadas en Header, Cookie, etc.)
- Fault Injection para Chaos Engineering
Existen 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 (Latency P50/P95/P99)
- Trazado distribuido (Jaeger, Zipkin)
- Visualización de topología de servicios (Kiali)
Mesh multi-cluster
- Comunicación entre varios clusters de EKS
- Failover entre clusters
- Balanceo de carga global
Independencia del proveedor
- Posibilidad de migrar a otros clouds o entornos on-premises
- Uso de estándares de Kubernetes

Ejemplo: gestión avanzada de 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 simple
- Solo se necesitan balanceo de carga y enrutamiento básicos
- Es importante una implementación rápida
Baja sobrecarga operativa
- Se prefieren servicios administrados por AWS
- Sin carga de administración de sidecar
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 más allá de Kubernetes
Optimización de costos
- Reducción de los costos de recursos de sidecar
- Servicios de pequeña escala

Uso conjunto de Istio + VPC Lattice

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

Casos de uso:

Dentro del cluster: Istio para la gestión detallada del tráfico y la seguridad
Entre clusters/entre cuentas: VPC Lattice para conectividad simple
Entornos mixtos: Usar VPC Lattice para conectar clusters de Istio con Lambda/EC2

Istio vs Cilium (basado en eBPF)

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

Comparación de arquitecturas

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 directamente
Rendimiento	Bueno	Excelente (nivel de kernel)
Uso de recursos	Alto (sidecar)	Bajo (nivel de kernel)
Funciones L7	Muy potentes	Básicas
Observabilidad	Enriquecida	Hubble (básica)
Curva de aprendizaje	Pronunciada	Pronunciada
Madurez	Alta	Media (funciones 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	Sólido	Cluster Mesh

Cuándo elegir cada opción

Elegir Istio:

La gestión de tráfico L7 es un requisito principal
Se necesitan funciones potentes de Service Mesh
Se necesitan herramientas enriquecidas 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 funciones y la mayor complejidad

Optimización específica de 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 los 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