BYOIP en Kubernetes: requisitos técnicos clave

Qué es BYOIP en Kubernetes y por qué importa

BYOIP (Bring Your Own IP) es, en pocas palabras, la posibilidad de anunciar en la nube tus propios prefijos IPv4 públicos —esos que ya tienes registrados a tu nombre en un RIR como RIPE NCC o ARIN— y asignarlos a servicios expuestos desde un clúster de contenedores. Si operas un ISP, una empresa de hosting o cargas en contenedores, la ventaja es clara: no pierdes la reputación de tus direcciones al migrar, te ahorras pelear con las listas blancas de firewalls de clientes y dejas de depender de los rangos del proveedor de nube.

¿Por qué ahora? El mercado ayuda a explicarlo. Los bloques IPv4 se siguen pagando a precios de referencia de entre 25 y 45 USD por dirección para un /24 en el mercado secundario. Con cifras así, proteger la inversión en un rango propio y poder llevarlo a cualquier entorno —Kubernetes incluido— deja de ser un capricho técnico y se convierte en una decisión estratégica.

Requisitos previos: propiedad y registro del prefijo IPv4

Tamaño mínimo del bloque

Casi todos los proveedores de nube que admiten BYOIP exigen, como mínimo, un /24 en IPv4. Algunos aceptan /23 o agregados mayores. Anunciar bloques menores no es viable: los filtros globales de longitud de prefijo en BGP lo impiden. ¿Tu rango es más pequeño? Las salidas habituales son CGNAT interno o comprar un /24 propio; en IP4 Market puedes comprar o alquilar prefijos /24 con vendedores verificados y precios competitivos, con transferencia limpia en el RIR.

Documentación de autorización: LOA y ROA

Antes de anunciar el prefijo en la nube tienes que demostrar que eres el legítimo titular. Esto implica tres cosas:

• LOA (Letter of Authorization): documento firmado donde el titular del recurso autoriza al proveedor de nube a anunciar el prefijo en BGP. Cada proveedor tiene su plantilla, pero todas piden lo mismo: el ASN del proveedor, el prefijo exacto, fechas de validez y contacto técnico.
• ROA en RPKI: un Route Origin Authorization que valide criptográficamente el origen del anuncio. Debe incluir el ASN del proveedor de nube como origen autorizado y una longitud máxima de prefijo acorde (normalmente /24). Sin ROA válido, muchos operadores descartan las rutas directamente por validación RPKI.
• Actualización del IRR: registrar el anuncio en la base IRR correspondiente (RIPE, RADB, etc.) para maximizar la aceptación de la ruta.

Integración de BYOIP con las plataformas de orquestación

Gestión del prefijo en el proveedor de nube

El flujo típico es este: aprovisionas el prefijo en el proveedor (que verifica el LOA y la propiedad en el RIR), creas un pool de direcciones y lo asocias a los recursos de red. Un detalle importante: el anuncio BGP del prefijo desde la nube solo debe activarse cuando la configuración interna esté lista. Si no, rutas negras.

Asignación de IPs propias a servicios de Kubernetes

Una vez el prefijo está disponible en la nube, la integración con el clúster va por estos caminos:

1. Services tipo LoadBalancer con pool propio: en EKS (AWS) se define un pool de BYOIP en un Network Load Balancer y se anota el servicio con service.beta.kubernetes.io/aws-load-balancer-ipv4-addresses o con el eIP del pool. En GKE, el prefijo BYOIP se publica como dirección IP pública estática reservable y se referencia en el Service. En AKS, las IPs del prefijo se convierten en recursos de IP pública y se asignan al balanceador.
2. Controladores de ingress: herramientas como Cilium, Calico (con BGP) o MetalLB permiten anunciar servicios directamente si el clúster tiene conectividad BGP propia. Útil en bare metal u on-premise.
3. Pods con IP pública directa: mediante CNI con soporte de EIP o NAT por pod (por ejemplo, en nodos con enrutamiento nativo), cada workload puede salir con una IP del rango propio. Esto es crítico para scraping autorizado, APIs con listas blancas o envío de correo desde tu rango con la reputación intacta.

On-premise y multicloud con BGP

En clústeres autohospedados, MetalLB en modo BGP permite anunciar el rango de servicios desde los nodos hacia tus routers. Y si además el /24 propio se propaga por tu ASN, Kubernetes pasa a ser simplemente otro origen de rutas. Nada más. Puedes mover workloads entre centros de datos y nubes sin cambiar IPs de cara al cliente, que al final es de lo que se trata.

Buenas prácticas operativas y seguridad

• Planifica la migración del anuncio: haz primero el anuncio desde la nube en modo prueba (advertising without provisioning completo) cuando el proveedor lo permita, monitoriza con looking glasses (bgp.he.net, RIPEstat) y verifica que el ROA e IRR apuntan al ASN correcto.
• Divide el uso del prefijo: un /24 da hasta 256 direcciones utilizables; reserva rangos para NAT de salida (egress) y otros para LoadBalancers, y documenta las asignaciones como harías con cualquier recurso IPAM.
• Monitoriza la reputación: revisa listas DNSBL y fuentes de reputación antes y después del cambio. Conservar ese historial es, precisamente, una de las grandes ventajas de BYOIP.
• Cuida el tiempo de convergencia BGP: los anuncios pueden tardar de 15 a 60 minutos en propagarse globalmente; coordina ventanas de mantenimiento en consecuencia. Con margen, no justo.
• Evita solapamientos: nunca anuncies el mismo prefijo a la vez desde dos orígenes sin un diseño anycast deliberado. Provocará inestabilidad de rutas y, con suerte solo filtrados.

Errores comunes al configurar BYOIP en Kubernetes

• Crear el ROA con maxLength menor de /24 e impedir anuncios válidos.
• Olvidar actualizar el LOA cuando cambia el ASN del proveedor.
• Asignar direcciones al balanceador sin haber verificado que el pool está en estado activo en la nube.
• No contemplar cuotas del proveedor: algunos limitan el número de prefijos BYOIP por cuenta (por ejemplo, 1 o 2 por defecto en AWS y GCP), ampliables previa solicitud.

Conclusión

Implementar BYOIP en Kubernetes es hoy perfectamente viable en las tres grandes nubes y en entornos bare metal con BGP, siempre que cumplas los requisitos técnicos: un prefijo mínimo /24 registrado a tu nombre en el RIR, un LOA firmado para el proveedor, un ROA RPKI correcto y una estrategia clara de asignación de direcciones a Services, ingress y tráfico de salida. ¿Merece la pena el esfuerzo? Creo que sí: continuidad de reputación IP, portabilidad multicloud y control total de tu espacio de direcciones en un mercado donde cada IPv4 cotiza entre 25 y 45 USD.

Y si aún no tienes bloque propio, evalúa comprar o alquilar un prefijo /24 con garantías de titularidad limpia. En IP4 Market encontrarás una plataforma con vendedores verificados, precios competitivos y soporte durante todo el proceso de transferencia y documentación, de modo que puedas llevar tus direcciones a tu clúster de Kubernetes sin sustos.