Balanceadores, proxies y gateways

¿Por qué hay varias copias? En «Hacer varias cosas a la vez» viste que un pod del gateway de C01 aguanta ≈ 100 requests por segundo: para 500 hacen falta 5. Y en «Probabilidad para sistemas que fallan», que aunque una copia bastara se pone otra en otra zona, por si una se cae. Además, las copias cambian todo el tiempo: el autoscaler (la regla que agrega o quita pods según su CPU) mueve el gateway entre 3 y 12 pods, y cada versión nueva reemplaza pods.

Cada pod tiene su propia dirección IP, y el que lo reemplaza tiene otra. El backend del marketplace no puede llevar esa lista al día, ni debería.

Para eso existe el balanceador de carga de carga (load balancer): un programa, o un servicio de la nube, que recibe las requests en una dirección fija y las reparte entre varias copias del servicio. Hace tres trabajos:

• Reparte. Lleva una lista de destinos (en AWS, un target group, un grupo de destinos) y elige uno para cada conexión o para cada request, según una regla: su algoritmo.
• Esconde. Quien llama ve una sola dirección, con un nombre que resuelve el DNS. Puedes pasar de 3 a 12 copias, o cambiarlas todas por una versión nueva, sin avisarle a nadie.
• Vigila. Pregunta seguido a cada destino si está sano, y deja de mandarle tráfico al que no contesta. Lo ves en la sección de health checks.

En C01, la puerta es un ALB (Application Load Balancer), el balanceador de AWS que entiende HTTP. No es una máquina que tú administras: AWS lo corre en varias máquinas, con presencia en las dos zonas de C01, y lo cobra por hora y por tráfico. Cuesta poco tiempo: la Ronda (M03) le pone de 1 a 3 ms a la request típica (el p50), con las conexiones ya abiertas. Y conviene aun con una sola copia detrás: da el cifrado en un solo lugar, los health checks y un punto estable para cambiar lo de atrás sin tocar a quien llama.

Ojo con la «puerta única»: el balanceador está en serie con todo lo demás. Si falla, falla todo, aunque haya 12 gateways sanos detrás. Por eso un balanceador serio nunca es una sola máquina. Y aun así, en «Probabilidad para sistemas que fallan» viste que pone 4 de los 5 minutos de falla que se esperan al mes en toda la cadena de C01: su 99.99 % es la única pieza que entra a la cuenta sin una copia en paralelo.

L4 y L7: lo que ve cada balanceador

En «Cómo viaja un mensaje» viste que un mensaje viaja en capas, como un sobre dentro de otro, y que las capas se numeran del 1 al 7 según un modelo de referencia. Aquí importan tres:

• Capas 3 y 4, red y transporte. Las direcciones IP de origen y de destino (capa 3), el puerto y la conexión TCP o UDP (capa 4). Dicen a qué máquina y a qué programa va el mensaje.
• Capa 7, aplicación. El mensaje mismo: en HTTP, el método, la URL, los headers y el body. Dice qué se pide.

Un balanceador se llama L4 o L7 (de layer, capa) según la capa más alta que lee: hasta dónde abre el sobre.

Un balanceador L4 decide una vez por conexión. Ve llegar una conexión nueva, elige un destino y, desde ese momento, pasa todos los bytes de esa conexión al mismo destino. No sabe si por ahí viajan una request o diez mil. No puede leer la ruta ni los headers, y si el tráfico es HTTPS, ni siquiera podría: va cifrado.

A cambio, es rápido y barato, y sirve para cualquier protocolo: HTTP, una base de datos, el video por UDP de una cámara. En AWS es el NLB (Network Load Balancer), que elige el destino de cada conexión con un hash de sus direcciones y sus puertos. Un hash es una cuenta que convierte unos datos en un número y que siempre da el mismo número para los mismos datos: la misma conexión, el mismo destino. El reparto dentro de Kubernetes, que hace un programa llamado kube-proxy, también es L4, y eso va a importar.

Un balanceador L7 decide en cada request. Termina la conexión con el cliente, lee cada request HTTP completa y elige un destino request por request. Como la lee, puede hacer mucho más:

• Rutear por contenido: /v1/classify a un grupo, /v2/classify a otro; un header X-Model-Arm: canary a la versión nueva del modelo (el canary, que ves más adelante).
• Agregar o quitar headers, como el id de la request para seguirla en los logs.
• Contestar él mismo cuando nadie puede: un 503 si no hay destinos, un 502 si el destino cortó la conexión.
• Medir cada request: cuántas, cuánto tardó cada destino, qué códigos devolvió.

Para leer HTTPS tiene que descifrarlo: tener el certificado (el archivo con el que un servidor demuestra quién es) y hacer el trabajo del cifrado. Eso se llama terminar TLS (TLS es el cifrado de HTTPS, y tiene su lección en la fase de seguridad), y lo ves en la sección de proxies. En AWS, el L7 es el ALB; fuera de la nube, programas de código abierto que instalas tú, como NGINX, HAProxy y Envoy.

Por qué importa «por conexión». Con keep-alive, una conexión TCP lleva muchas requests, una tras otra. Con HTTP/2 y gRPC, muchas a la vez sobre la misma conexión, durante horas. Un L4 manda todas esas requests al destino que eligió cuando se abrió la conexión. Si hay pocas conexiones y muy largas, el reparto puede quedar muy chueco, y ningún algoritmo L4 lo arregla: el L4 no ve las requests. Es el problema de la sección de Kubernetes.

¿Cuándo eliges L4, entonces? Cuando el protocolo no es HTTP, cuando importa el costo por conexión, o cuando el cifrado debe llegar intacto hasta el servidor.

Un algoritmo de balanceo es la regla con la que el balanceador elige el destino de cada request, o de cada conexión. Los más comunes:

• Round-robin (por turnos). Al primero, al segundo, al tercero, y otra vez al primero. Sin memoria y sin cuentas. Es el que usan por omisión el ALB, NGINX, HAProxy y Envoy.
• Por peso (weighted round-robin). Por turnos, pero un destino con peso 3 recibe 3 requests por cada una del de peso 1. Sirve cuando las máquinas no son iguales.
• Al azar (random). Se elige un destino al azar. No necesita guardar ni un turno, y por eso lo pueden aplicar muchas máquinas a la vez sin ponerse de acuerdo. Es lo que hace kube-proxy en su modo más común.
• Menos conexiones (least-connections) o menos requests pendientes (least outstanding requests). Al destino con menos trabajo en vuelo en ese momento: requests que ya recibió y todavía no contesta. El ALB lo ofrece con ese nombre, least outstanding requests, como opción en vez de su round-robin (tiene un tercero, al azar con pesos, weighted random).
• Dos opciones al azar (power of two choices). Elige dos destinos al azar y manda la request al menos ocupado de los dos.
• Por hash. Una cuenta con algo de la request, como el id del usuario, que siempre da el mismo destino para el mismo valor. Es para la afinidad, y está en su propia sección.

Por qué round-robin falla

Round-robin reparte requests, no trabajo. Si todas tardan lo mismo, es perfecto. Pero en C01 una foto de 200 KB del celular y una de 10 MB de la web no cuestan lo mismo, y en un LLM una respuesta de 50 tokens y una de 2,000 tardan ≈ 40 veces distinto (2,000 ÷ 50), porque el modelo escribe un token tras otro. Round-robin no lo sabe, y sigue mandando su turno a la copia que se quedó atorada con la pesada.

Least-connections no adivina cuánto va a tardar cada request: solo cuenta cuántas tiene cada destino sin contestar. Es suficiente, porque un destino atorado acumula requests en vuelo y deja de recibir.

¿Y con muchas requests, no solo diez? Una simulación con 100,000 requests en 4 pods, con 1 de cada 10 pesada, mide cuánto espera cada request en fila. El p99 de esa espera queda en ≈ 332 ms con round-robin, ≈ 436 ms al azar, ≈ 136 ms con least-connections y ≈ 186 ms con dos opciones al azar. Least-connections lo baja a menos de la mitad, y dos opciones queda cerca con mucha menos información.

La razón es la idea de M03: mandar cada request al menos ocupado se porta casi como una sola fila compartida, la del banco. Con dos servidores ocupados al 80 % y 10 ms por request (otra carga, no la de esta simulación), la espera promedio baja de 40 ms, cada uno con su fila, a ≈ 18 ms con una fila compartida. «Qué tan rápido y cuánto» explica por qué.

import random

def simular(politica, pods=4, tasa=150, n=100_000):
    rng = random.Random(7)                                # semilla: siempre la misma corrida
    libre, fines, t, esperas = [0.0] * pods, [[] for _ in range(pods)], 0.0, []
    for i in range(n):
        t += rng.expovariate(tasa)                        # 150 requests por segundo, al azar
        dur = 0.100 if rng.random() < 0.10 else 0.010     # 1 de cada 10 tarda 100 ms; el resto, 10
        vuelo = [sum(f > t for f in fines[p]) for p in range(pods)]   # requests en vuelo por pod
        if politica == "round-robin":   p = i % pods
        elif politica == "al azar":     p = rng.randrange(pods)
        elif politica == "least-conn":  p = vuelo.index(min(vuelo))
        else:                                             # dos opciones: dos al azar, el más libre
            a, b = rng.sample(range(pods), 2)
            p = a if vuelo[a] <= vuelo[b] else b
        inicio = max(t, libre[p])                         # cada pod atiende de una en una
        libre[p] = inicio + dur
        fines[p] = [f for f in fines[p] if f > t] + [libre[p]]
        esperas.append(inicio - t)
    return sorted(esperas)

for politica in ("round-robin", "al azar", "least-conn", "dos opciones"):
    e = simular(politica)
    print(f"{politica:<13} espera en fila: p50 {e[len(e)//2]*1000:4.1f} ms · p99 {e[int(len(e)*0.99)]*1000:5.1f} ms")

round-robin   espera en fila: p50  9.7 ms · p99 331.5 ms
al azar       espera en fila: p50 27.6 ms · p99 436.0 ms
least-conn    espera en fila: p50  0.0 ms · p99 136.2 ms
dos opciones  espera en fila: p50  3.0 ms · p99 185.8 ms

Un proxy es un intermediario: recibe tu request y la hace por ti. La pregunta que lo define es a nombre de quién trabaja.

El proxy, a nombre de los clientes

Un proxy «de ida» (forward proxy) se pone del lado de los clientes. Las computadoras de una empresa, por ejemplo, salen a internet a través de uno: el proxy decide qué sitios se permiten, guarda un registro y, a veces, una copia de lo que se pide seguido. El servidor de afuera ve la dirección del proxy, no la de cada empleado.

En ML lo vas a ver en la salida de un clúster hacia un proveedor externo de LLMs: un proxy revisa a dónde va cada request antes de que salga. Esa salida se llama egress, y tiene su lección en la fase de la nube.

El proxy inverso, a nombre de los servidores

Un proxy inverso (reverse proxy) se pone del lado de los servidores. Los clientes creen que hablan con el servidor, pero hablan con el proxy, que pasa cada request a alguno de los de atrás. Un balanceador L7 es un proxy inverso cuyo trabajo principal es repartir. Pero un proxy inverso hace más cosas:

• Terminar TLS. Es descifrar en el proxy: el certificado vive en un solo lugar y los servidores de atrás reciben HTTP simple dentro de la red privada, o cifrado otra vez si la red no es de confianza. El precio: el proxy ve todo en claro, así que es parte de lo que hay que proteger.
• Poner límites. Tamaño máximo del body, tiempo máximo de espera (timeout), número de conexiones.
• Juntar la request completa (buffering) antes de pasarla, para que un cliente lento no tenga ocupado al servidor. Y guardar copias de lo que se repite (cache).

Los más usados son NGINX, HAProxy y Envoy; los de la nube, como el ALB, hacen lo mismo como servicio.

Terminar TLS cuesta: una conexión cifrada nueva pide una o dos idas y vueltas más por la red que la de TCP, según la versión de TLS, y cuentas de criptografía. La Ronda (M03) le pone al ALB, con TLS, de 5 a 10 ms en el p99; con las conexiones ya abiertas y reutilizadas, la request típica (el p50) paga de 1 a 3 ms. Por eso los clientes mantienen sus conexiones abiertas en un pool de conexiones.

El API gateway: un proxy inverso con reglas

Un API gateway es un proxy inverso que conoce las reglas de la api. Antes de pasar una request, revisa:

• Quién llama (autenticación): una llave de la API (api key) o un token firmado (JWT), que tienen su lección en la fase de identidad.
• Qué puede hacer (autorización): esta ruta, este modelo, esta versión.
• Cuánto puede pedir: un rate limit por cliente, en la sección que sigue.
• A dónde va: por ruta, por versión o por un alias, como chat-default → la revisión actual del modelo.
• Cuánto usó: cuenta requests o tokens por cliente, para cobrar o para repartir costos.

Sin un gateway, cada servicio reimplementa la autenticación y el rate limit, y cada uno a su manera. Con uno, se hace en un lugar.

Los dos «gateway» de C01

Aquí la palabra se presta a confusión. En C01, «el gateway» es el programa en Python que recibe la foto, la valida, la decodifica, la redimensiona, la normaliza y llama a Triton. Eso no es un proxy: es un servicio con lógica de ML, el preprocesamiento. Pero ese mismo programa también hace trabajo de API gateway: aplica la cuota de cada cliente, rechaza bodies de más de 10 MB leyendo el header Content-Length antes de recibirlos y pone el límite de tiempo de toda la request.

Lo de «verifica el token» lo hace el propio ALB: desde noviembre de 2025 puede revisar un token JWT (su firma, su vencimiento y lo que dice) antes de pasar la request, sin código en el gateway. Lo que el ALB no hace es contar cuánto pide cada cliente: eso queda en el gateway.

En la Ronda, cuando leas «gateway» en C01, piensa en las dos cosas. Cuando leas «API gateway» en general, piensa en la puerta: productos como Kong, Envoy Gateway o el API Gateway de AWS. Y en C10, el caso de la Ronda de un LLM que sirve a varios equipos de una empresa, el «llm-gateway» es una puerta pura: no prepara nada, pero revisa la llave de cada equipo, cobra su cuota en tokens y elige la réplica del modelo.

El balanceador solo debe mandar tráfico a destinos que puedan contestar. Para saberlo, usa health checks (revisiones de salud), de dos tipos:

• Activos. El balanceador pregunta cada cierto tiempo, por ejemplo con un GET /readyz cada 5 s, y espera un 200 en menos de un límite. Si falla N veces seguidas, marca al destino como no sano y deja de mandarle requests. Si vuelve a contestar bien M veces seguidas, lo regresa.
• Pasivos. El balanceador mira las respuestas de verdad. Si un destino devuelve 5 errores seguidos, o se le vencen varias requests, lo saca un rato aunque sus preguntas de salud digan que está bien. En Envoy se llama outlier detection (detección del que se sale de lo normal), y 5 errores 5xx seguidos (los códigos del 500 al 599, que dicen «falló el servidor») es su umbral si nadie lo cambia.

Los dos se complementan. Un pod cuyo programa se murió, en una máquina que sigue viva, rechaza las conexiones al instante, y el chequeo pasivo lo nota en milisegundos. Uno que se cuelga (acepta la conexión, pero no contesta) es peor: cada request espera hasta su timeout, y el chequeo activo tarda varios periodos en sacarlo.

¿Por qué no preguntar cada segundo y sacar al primer error? Porque un chequeo demasiado sensible saca pods sanos que tuvieron un mal segundo. Los que quedan reciben más tráfico, se frenan también, fallan su chequeo… y el sistema se apaga solo, en cascada. Los umbrales son un equilibrio entre tardar en sacar a uno muerto y sacar por error a uno vivo.

Readiness y liveness: dos preguntas distintas

Kubernetes hace sus propias preguntas a cada pod, las probes, y en «Programa, proceso e hilo» viste la de liveness. Son tres, y cada una tiene una consecuencia distinta:

La readiness es el health check del balanceo: un pod que no está listo sale de la lista de destinos y sigue vivo, esperando. C01 las separa en dos rutas. /healthz es la liveness: solo dice si el proceso responde y no pregunta por nadie más. /readyz es la readiness: da 200 solo si el modelo está cargado y listo en Triton. Y Triton, que tarda en cargar su engine (el modelo ya convertido para correr rápido en la T4, que viste en «CPU y GPU»), tiene una startup probe que le da hasta 5 minutos (60 intentos, cada 5 s).

El ALB, además, tiene sus propios health checks, que no son los de Kubernetes: son dos jueces distintos, con sus propios tiempos. Si nadie los cambia, el ALB pregunta cada 30 s y saca al destino tras 2 fallas, hasta un minuto; el controlador de AWS que lo arma desde Kubernetes (un programa dentro del clúster que crea y ajusta el ALB; lo ves con el Ingress) pone, por omisión, cada 15 s y 2 fallas. En C01 manda el que avise primero: si el chequeo del ALB falla, el ALB deja de mandarle; si falla la readiness, el controlador de AWS da de baja al pod en el ALB. Y ninguno dice que las respuestas sean buenas. La readiness pregunta «¿el proceso está vivo y cargó el modelo?», no «¿las predicciones son buenas?» (M11).

C01 no solo atiende al backend del marketplace. También lo llaman otros equipos: moderación, por ejemplo, que revisa publicaciones en tandas. Si un programa de moderación con un error manda 3,000 requests por segundo, se come la GPU de todos, y Ana espera.

Un rate limit (límite de ritmo) es un tope de cuántas requests acepta el sistema de cada cliente por unidad de tiempo. Lo que pase del tope recibe al instante un 429 (Too Many Requests, «demasiadas requests»), con un header undefined que dice en cuántos segundos vale la pena volver a intentar.

El token bucket

Un token bucket (balde de fichas) separa las dos preguntas que de verdad importan: qué ritmo sostenido le das a un cliente y cuánto de golpe le toleras.

1. 1

   Un balde con capacidad B

   Cada cliente tiene un balde que guarda hasta B fichas. Empieza lleno.

2. 2

   Se rellena a ritmo r

   Cada segundo caen r fichas nuevas, hasta que el balde se llena. Lo que sobra se tira.

3. 3

   Cada request gasta una ficha

   Si hay ficha, la request pasa. Si el balde está vacío, recibe 429, y el Retry-After dice cuánto falta para la siguiente ficha.

Así, un cliente que manda menos de r por segundo nunca recibe un 429. Uno que estuvo tranquilo puede mandar una ráfaga (burst) de hasta B de golpe. Y nadie sostiene más de r por segundo.

En código cabe en unas líneas. El balde no necesita un reloj que lo rellene: cada vez que llega una request, suma las fichas que cayeron desde la última.

import math

class TokenBucket:
    def __init__(self, ritmo, capacidad):
        self.r, self.B = ritmo, capacidad        # fichas por segundo y tamaño del balde
        self.fichas, self.t = capacidad, 0.0     # empieza lleno

    def pedir(self, ahora):
        self.fichas = min(self.B, self.fichas + (ahora - self.t) * self.r)   # recarga lo que pasó
        self.t = ahora
        if self.fichas >= 1:
            self.fichas -= 1
            return 200, None                     # pasa
        falta = (1 - self.fichas) / self.r       # segundos para la siguiente ficha
        return 429, math.ceil(falta)             # Retry-After va en segundos enteros

moderacion = TokenBucket(ritmo=50, capacidad=100)
codigos = [moderacion.pedir(i / 300) for i in range(300)]          # 300 requests en 1 s
print("en el primer segundo:", sum(c == 200 for c, _ in codigos), "pasan,",
      sum(c == 429 for c, _ in codigos), "reciben 429 · Retry-After:", codigos[-1][1], "s")
codigos = [moderacion.pedir(1 + i / 50) for i in range(50)]        # luego, 50 por segundo
print("al ritmo pactado:", sum(c == 200 for c, _ in codigos), "de 50 pasan")
print("fichas tras 3 s sin pedir nada:", round(min(100, moderacion.fichas + 3 * 50)))

en el primer segundo: 149 pasan, 151 reciben 429 · Retry-After: 1 s
al ritmo pactado: 50 de 50 pasan
fichas tras 3 s sin pedir nada: 100

Salen 149 y no 150 porque la última request llega a los 0.997 s, un poquito antes de que caiga la ficha 50 de ese segundo.

El balde va por identidad verificada, no por dirección IP: muchos clientes pueden salir por la misma IP, y uno solo puede usar muchas. En C01, la identidad sale del token que el ALB ya verificó.

Kubernetes, el programa de orquestación de C01, corre los contenedores en pods repartidos por un clúster: el grupo de máquinas que maneja. Cada pod recibe su propia IP, y la pierde cuando muere. ¿Cómo encuentra el gateway a Triton, si los pods de Triton van y vienen?

El Service: una IP que no cambia

Un Service es un objeto de Kubernetes que le da a un grupo de pods un nombre y una IP estables. El gateway de C01 llama a triton, y el DNS del clúster lo traduce a una IP virtual, la ClusterIP, que no pertenece a ningún pod. El Service elige sus pods por sus etiquetas (por ejemplo, app: triton) y guarda la lista de sus pods, con una marca de cuáles están listos (los que pasan su readiness), en unos objetos llamados EndpointSlices. Un pod que falla su readiness queda marcado como no listo, y el reparto lo salta.

¿Quién reparte? kube-proxy, un programa que corre en cada máquina del clúster. No recibe las requests: le escribe al kernel de Linux unas reglas para que, cada vez que alguien abre una conexión a la ClusterIP, el kernel la reescriba hacia la IP de uno de los pods listos. En su modo más común, el de iptables (el sistema de reglas de red del kernel), elige al azar. Y elige por conexión: es L4. Nunca ve una request HTTP.

Conexiones pegadas

Ahora junta las piezas. Con gRPC, cada pod del gateway abriría una conexión HTTP/2 a Triton y la usaría para miles de requests, durante horas. kube-proxy elige el pod de Triton una sola vez, al abrir la conexión, y ahí se queda.

C01 usa HTTP entre el gateway y Triton, con un pool de varias conexiones que se renuevan, y ahí el efecto existe pero es menor. Por eso la Ronda dice que gRPC solo entra si se mide una ganancia clara, y con alguna de estas salidas:

• Un Service headless (sin cabeza: sin ClusterIP). El DNS devuelve las IPs de todos los pods, y el cliente de gRPC reparte él mismo, request por request.
• Un balanceo L7 entre servicios, que es lo que da un service mesh: la sección extra.
• Una vida máxima para cada conexión en el servidor: cada pocos minutos la cierra, y el cliente se reconecta y vuelve a sortear.

Ingress y Gateway API: la entrada desde afuera

El Service conecta pods con pods. Para que el tráfico de afuera entre al clúster existe el Ingress: un objeto de Kubernetes con reglas HTTP de entrada, como «lo que llegue a api.ejemplo.com/v1/classify, mándalo al Service del gateway». El Ingress es solo la regla escrita. Lo aplica un controlador de Ingress, que es un proxy inverso de verdad, como NGINX, o un programa que configura uno de la nube. En C01, el controlador de AWS lee el Ingress del gateway y arma el ALB. Con target-type: ip, el ALB manda cada request directo a la IP de un pod del gateway: reparte él, por request, y kube-proxy no interviene en esa entrada.

Su sucesor es Gateway API, estable desde octubre de 2023, con pesos y condiciones por header ya incluidos. La documentación de Kubernetes y la Ronda (M06) dicen lo mismo: Ingress sigue funcionando, pero su API está congelada (no recibe funciones nuevas), y los diseños nuevos van con Gateway API.

Hasta aquí, el balanceador trata igual a todas las copias. A veces no quieres eso: quieres mandar una parte exacta del tráfico a una versión.

Cuando sale una versión nueva del modelo, C01 no se la da a todo el mundo de golpe. Primero le manda una parte chica del tráfico, el 5 %, y vigila sus errores: es un canary, y tiene su lección en la fase de despliegue. Para eso hace falta ruteo por peso: repartir el tráfico entre versiones según porcentajes fijados en la configuración. En el ALB, cada target group lleva un peso de 0 a 999, y cada request cae en uno u otro en proporción.

Aquí hay una trampa. Kubernetes, por sí solo, reparte por pods: si el estable tiene 2 pods de Triton y le agregas 1 del canary, el Service le manda al canary ≈ 1 de cada 3 requests, no el 5 %. Para un 5 % por pods harían falta 19 pods estables por cada canary. El porcentaje lo tiene que poner un proxy: el ALB, Gateway API o un service mesh.

Los pesos reparten por request: cada una tira su propio dado. Para vigilar errores y latencia, eso basta. Cuando no basta, se reparte por usuario, y eso abre la sección extra que sigue.

1. Creer que el Service reparte requests

El Service de Kubernetes reparte conexiones. Con gRPC o con pocas conexiones largas, unos pods se llenan, otros quedan ociosos y los pods nuevos del autoscaler no reciben nada.

Cómo evitarlo: mide las requests por pod, no solo el total. Si las conexiones son largas, usa balanceo L7 (un mesh o un proxy), un Service headless con balanceo en el cliente, o una vida máxima de conexión.

2. Round-robin con requests que tardan muy distinto

Todos reciben las mismas requests, pero no el mismo trabajo, y la fila crece detrás de la copia que se atoró.

Cómo evitarlo: least outstanding requests en el ALB, least request en Envoy o dos opciones al azar. En LLMs, nunca round-robin.

3. Una liveness que pregunta por otros

Si la liveness del gateway revisa a Triton, cuando Triton cae el kubelet (el agente de Kubernetes en cada máquina) reinicia gateways sanos, que no arreglan nada.

Cómo evitarlo: la liveness solo pregunta si el proceso responde. Las dependencias van en la readiness (sabiendo que, si todos fallan a la vez, el ALB falla abierto) o en las respuestas: un 503 con Retry-After.

4. Un rate limit por pod, por IP o con 503

Cinco pods con su propio balde dan cinco veces la cuota. Una IP compartida castiga a muchos por uno. Un 503 por cuota dispara tu alarma de disponibilidad.

Cómo evitarlo: el balde por identidad verificada, en un almacén compartido o dividido entre los pods, y 429 con Retry-After.

5. Hacer el canary con el número de pods

Uno de tres pods es 33 %, no 5 %.

Cómo evitarlo: que el porcentaje lo ponga un proxy con pesos (ALB, Gateway API, mesh), y un canary con su propio Service.

6. El keep-alive del servidor más corto que el del balanceador

El ALB cierra las conexiones que pasan 60 s sin tráfico. Si el servidor de atrás las cierra antes, el ALB a veces manda una request por una conexión que el servidor acaba de cerrar, y el cliente recibe un 502 que nadie entiende.

Cómo evitarlo: que el servidor espere más que el balanceador, como recomienda AWS. uvicorn, si nadie lo cambia, cierra a los 5 s; el gateway de C01 lo corre con --timeout-keep-alive 75, más que los 60 del ALB.

Resuélvelos con lápiz antes de abrir la solución. El de token bucket y el de canary se pueden comprobar con las calculadoras.

1. 1Fácil

   Un balanceador reparte 500 requests por segundo entre dos pods: uno con el doble de CPU que el otro. ¿Cuánto recibe cada uno con round-robin? ¿Y por peso, con pesos 2 y 1?

   Ver la solución paso a paso

   • Round-robin: 250 y 250, sin importar el tamaño. El pod chico recibe lo mismo con la mitad de CPU.
   • Por peso 2 y 1: el grande recibe 2 de cada 3: 500 × 2/3 ≈ 333; el chico, 500 × 1/3 ≈ 167.
   • Así, los dos quedan igual de ocupados en proporción a su CPU.
2. 2Fácil

   ¿L4 o L7? (a) Mandar /v2/ a la versión nueva. (b) Repartir el video por UDP de unas cámaras. (c) Respetar la cookie de afinidad. (d) Que el cifrado llegue intacto hasta el servidor.

   Ver la solución paso a paso

   • (a) L7: hay que leer la ruta.
   • (b) L4: no es HTTP; el L4 sirve para cualquier protocolo.
   • (c) L7: la cookie es un header de la request.
   • (d) L4: un L7 tendría que descifrar para leer; un L4 pasa los bytes sin abrirlos.
3. 3Fácil

   ¿Qué probe falla y qué pasa? (a) Triton sigue cargando su engine. (b) El proceso del gateway se trabó y no contesta nada. (c) El gateway está bien, pero Triton no responde.

   Ver la solución paso a paso

   • (a) La startup: Kubernetes espera (hasta 5 minutos en C01) y no le manda tráfico. Si nunca termina, lo reinicia.
   • (b) La liveness: el kubelet reinicia el contenedor. Mientras tanto, también falla la readiness y sale del reparto.
   • (c) Solo la readiness del gateway (/readyz): sale del reparto sin reiniciarse. Reiniciarlo no arreglaría a Triton.
4. 4Medio

   Un token bucket da 20 fichas por segundo y guarda hasta 40. Con el balde lleno llegan 100 requests en medio segundo. ¿Cuántas pasan? ¿Cuánto tarda en llenarse otra vez?

   Ver la solución paso a paso

   • Pasan las del balde, 40, más las que caen en medio segundo: 20 × 0.5 = 10. En total, ≈ 50; las otras ≈ 50 reciben 429.
   • Para llenarse: 40 ÷ 20 = 2 s sin pedir nada.
   • Compruébalo con la calculadora: ritmo 20, balde 40, 100 requests en 0.5 s.
5. 5Medio

   El estable de C01 tiene 4 pods de Triton y quieres un canary al 5 % en el pico de diseño de 500 requests por segundo. (a) Si agregas 1 pod canary al mismo Service, ¿qué porcentaje y cuántas requests por segundo recibe? (b) ¿Y con pesos en el ALB? (c) ¿Aguanta un solo pod?

   Ver la solución paso a paso

   • (a) Por pods: 1 ÷ (4 + 1) = 20 %: 500 × 0.2 = 100 por segundo. Cuatro veces lo que querías.
   • (b) Con pesos: 500 × 5 % = 25 por segundo.
   • (c) Sí: la Ronda cuenta con ≈ 1,200 imágenes por segundo por T4, y 25 le sobran. Un canary puede tener un solo pod si aguanta su parte con margen.
6. 6Medio

   Un pod del gateway, con 100 requests por segundo, se cuelga. Su readiness usa los valores de Kubernetes si nadie los cambia: cada 10 s, 3 fallas. ¿Cuántas requests se pierden antes de que salga? ¿Y con cada 5 s y 2 fallas? ¿Qué arriesgas al bajarlo?

   Ver la solución paso a paso

   • Por omisión: 10 × 3 = 30 s, y 100 × 30 = 3,000 requests.
   • Con 5 s y 2: 10 s, 1,000 requests.
   • Lo que arriesgas: sacar pods sanos que tuvieron un mal momento, cargar más a los demás y causar una cascada. Por eso se combina con un chequeo pasivo.
7. 7Medio

   Tres pods del gateway abren una conexión gRPC cada uno al Service de Triton, que tiene 2 pods. (a) ¿Qué tan probable es que un Triton se quede sin tráfico? (b) El autoscaler agrega un tercero: ¿qué recibe? (c) Con una vida máxima de conexión, cada conexión se cierra y se vuelve a abrir: ¿cuántas conexiones espera tener el nuevo después?

   Ver la solución paso a paso

   • (a) Cada conexión elige al azar entre 2: hay 2³ = 8 combinaciones, y en 2 de ellas las 3 caen en el mismo. 2 ÷ 8 = 25 %.
   • (b) Nada: las conexiones ya están abiertas. Recibe 0 % hasta que alguna se reconecte.
   • (c) Cada conexión que se reabre elige entre 3: el nuevo espera 3 × 1/3 = 1 conexión. Con tan pocas, el reparto sigue chueco; por request, cada uno recibiría un tercio.
8. 8Reto

   Un pod del gateway de C01 se cuelga en el pico de diseño. El ALB pregunta cada 10 s y lo saca a las 2 fallas; la readiness de Kubernetes lo marca como no listo a los 15 s. (a) ¿Cuántas requests recibe antes de salir? (b) ¿Qué parte del presupuesto mensual de ≈ 300,000 fallas es? (c) ¿Cuántas requests hay colgadas en ese pod a la vez, si quien llama se rinde a los 300 ms? (d) ¿Qué agregarías?

   Ver la solución paso a paso

   • (a) Lo saca el primero que se entere. El chequeo del ALB tarda 10 × 2 = 20 s; la readiness, 15 s, y cuando falla, el controlador de AWS da de baja al pod en el ALB. Gana la readiness: 100 × 15 = ≈ 1,500 requests, más los segundos que tarde la baja en llegar al ALB. Sin la readiness serían 100 × 20 = 2,000.
   • (b) 1,500 ÷ 300,000 = 0.5 % del presupuesto del mes, por un solo pod. Diez incidentes así son 5 %.
   • (c) Con la Ley de Little: 100 por segundo × 0.3 s = 30 colgadas a la vez. Es más que MAX_INFLIGHT = 16, el tope que rechazaría la 17 con un 503 si el pod funcionara; pero un pod colgado no corre ni ese código, así que no rechaza nada: todas esperan.
   • (d) Un chequeo pasivo: sacar al pod tras unos cuantos errores o timeouts seguidos, que a 100 por segundo se juntan en menos de un segundo. Y timeouts cortos, como los 300 ms de C01, para que ninguna espere más.
9. 9Reto

   Un cliente tiene una cuota de 3,000 requests por minuto con una ventana fija. (a) ¿Cuántas puede mandar en 2 segundos, y a qué ritmo, comparado con 50 por segundo? (b) Diseña un token bucket con el mismo ritmo sostenido que no deje pasar más de 250 en esos 2 segundos. (c) ¿Qué mide cada uno?

   Ver la solución paso a paso

   • (a) 3,000 al final de un minuto y 3,000 al principio del siguiente: 6,000 en 2 s, 3,000 por segundo: 60 veces el ritmo de 50 por segundo.
   • (b) El ritmo sostenido es 3,000 ÷ 60 = 50 por segundo. En 2 s pasan B + 50 × 2 = B + 100. Para que no pasen de 250: B = 150.
   • (c) La ventana fija controla el total de cada minuto, para la factura. El token bucket controla el ritmo instante a instante, para la capacidad: aguanta una ráfaga de 150 y nada más.

Estos son los conceptos que presentó esta lección. Cada uno tiene su tarjeta con la definición completa.

Intenta responder en tu cabeza antes de abrir cada respuesta.

1. 1¿Qué diferencia a un balanceador L4 de uno L7?Ver respuesta

   El L4 ve direcciones y puertos y decide una vez por conexión. El L7 lee cada request HTTP (ruta, headers, body) y decide en cada una; para eso termina TLS.

2. 2¿Por qué round-robin falla cuando las requests tardan distinto?Ver respuesta

   Reparte requests, no trabajo: sigue mandando su turno a la copia atorada con una pesada, y la fila crece ahí mientras otra está libre. Least-connections mira cuántas tiene cada una en vuelo.

3. 3¿En qué se diferencian la readiness y la liveness?Ver respuesta

   La readiness pregunta «¿te mando tráfico?» y, si falla, saca al pod del reparto sin reiniciarlo. La liveness pregunta «¿sigues vivo?» y, si falla, lo reinicia. Las dependencias van en la readiness.

4. 4Un token bucket da 50 fichas por segundo y guarda 100. ¿Cuántas pasan de 300 requests en un segundo?Ver respuesta

   ≈ 150: las 100 del balde y las 50 que caen en ese segundo. Las otras ≈ 150 reciben 429 con Retry-After.

5. 5¿Por qué un pod nuevo de Triton puede quedarse sin tráfico detrás de un Service?Ver respuesta

   Porque el Service reparte por conexión (L4), y con conexiones largas, como las de gRPC, las que ya existen siguen pegadas a los pods viejos hasta que se cierren.

6. 6¿Por qué un canary con 1 pod junto a 2 estables no recibe el 5 %?Ver respuesta

   Porque Kubernetes reparte por pods listos: le toca 1 de 3, ≈ 33 %. El 5 % lo pone un proxy con pesos: el ALB, Gateway API o un mesh.