SDN OVN Open vSwitch 2025: Redes Kubernetes Avanzadas

Introducción: La evolución de las redes en Kubernetes

La adopción de Kubernetes como orquestador de contenedores ha transformado el paradigma del despliegue de aplicaciones. Sin embargo, la gestión de la red subyacente sigue siendo uno de los desafíos más complejos para los administradores de sistemas. Las redes tradicionales, basadas en configuraciones estáticas y dispositivos físicos, chocan con la naturaleza efímera y dinámica de los Pods.

Aquí es donde entran en juego las Redes Definidas por Software (SDN). En lugar de depender de conmutadores y enrutadores físicos, una SDN separa el plano de control del plano de datos, permitiendo una gestión centralizada y programable del tráfico. Dentro del ecosistema Kubernetes, dos tecnologías han emergido como la combinación más potente para implementar SDN de alto rendimiento: OVN (Open Virtual Network) y Open vSwitch (OVS).

Este artículo explora en profundidad cómo OVN y Open vSwitch se integran en clusters Kubernetes para ofrecer una segmentación de red granular, un aislamiento de tráfico robusto y una escalabilidad sin precedentes. Analizaremos su arquitectura, sus ventajas frente a otras soluciones CNI y cómo implementarlas en producción.

¿Qué es Open vSwitch y por qué es la base de la SDN?

Open vSwitch (OVS) es un conmutador virtual de código abierto, diseñado para entornos virtualizados. A diferencia de los bridges de Linux (como docker0 o cni0), OVS ofrece funcionalidades avanzadas propias de switches físicos empresariales: soporte para VLANs, OpenFlow, NetFlow, SPAN, RSPAN y túneles VXLAN/Geneve.

En el contexto de Kubernetes, OVS actúa como el plano de datos (data plane). Cada nodo del cluster ejecuta una instancia de OVS que se encarga de:

Reenviar paquetes entre Pods dentro del mismo nodo.
Encapsular tráfico entre nodos a través de túneles (generalmente Geneve o STT).
Aplicar políticas de red (NetworkPolicies) a nivel de flujo.
Recolectar métricas de tráfico para monitorización.

[TIP] Si tu cluster ya usa un CNI basado en bridges Linux, migrar a OVS no solo mejora el rendimiento en escenarios de alta densidad, sino que también te prepara para funciones avanzadas como la telemetría de flujos.

OVN: El cerebro de la red definida por software

OVN (Open Virtual Network) es la capa de control que se sitúa sobre OVS. Mientras OVS maneja los paquetes, OVN se encarga de la lógica de red: direccionamiento, conmutación, enrutamiento y políticas de seguridad. OVN introduce los siguientes conceptos clave:

Logical Switches: Equivalentes a VLANs o redes de nivel 2. Cada Namespace de Kubernetes puede mapearse a un Logical Switch.
Logical Routers: Proporcionan conectividad entre Logical Switches (inter-Namespace) y hacia el exterior.
Logical Ports: Representan las interfaces virtuales de los Pods (veth pairs) conectadas a OVS.
ACLs (Access Control Lists): Implementan las NetworkPolicies de Kubernetes de forma nativa, sin necesidad de iptables.

OVN centraliza el estado de la red en una base de datos (OVN Northbound DB) que luego se traduce en flujos OpenFlow para OVS. Esto permite que cualquier cambio en la topología de red (creación de un Pod, actualización de una política) se propague de forma consistente a todos los nodos en milisegundos.

Arquitectura OVN-Kubernetes: Cómo funciona realmente

La implementación de referencia para usar OVN+OVS en Kubernetes es el proyecto ovn-kubernetes. Su arquitectura se compone de varios componentes que trabajan en conjunto:

Componentes del plano de control

ovn-northd: Traduce las configuraciones de la base de datos Northbound en registros lógicos para la base de datos Southbound.
ovn-controller: Se ejecuta en cada nodo worker. Lee la base de datos Southbound y programa los flujos en el OVS local.

Componentes del plano de datos

Open vSwitch (ovs-vswitchd): El conmutador virtual que maneja el tráfico real.
ovsdb-server: Almacena la configuración de OVS (interfaces, bridges, túneles).

Flujo de tráfico entre Pods en diferentes nodos

El Pod A (nodo1) envía un paquete al Pod B (nodo2).
El paquete llega al bridge OVS integrado (br-int) en nodo1.
OVS, guiado por los flujos programados por ovn-controller, encapsula el paquete en un túnel Geneve.
El paquete viaja por la red física hasta nodo2.
OVS en nodo2 desencapsula el paquete y lo entrega al Pod B.

Este proceso es transparente para los Pods, que ven una red plana de nivel 2, mientras que la encapsulación permite una segmentación segura sin necesidad de configurar VLANs en los switches físicos.

Ventajas de OVN+OVS frente a otras CNIs populares

1. Escalabilidad masiva

Mientras que soluciones como Flannel (VXLAN) o Calico (BGP) pueden tener problemas de rendimiento o complejidad en clusters con más de 500 nodos, OVN está diseñado para manejar miles de nodos y decenas de miles de Pods. Su arquitectura basada en bases de datos distribuidas (RAFT para la DB Southbound) garantiza consistencia sin un punto único de fallo.

2. NetworkPolicies nativas y eficientes

OVN implementa las NetworkPolicies de Kubernetes directamente en el plano de datos mediante ACLs en OVS. Esto evita el uso de iptables (como hace Calico o Cilium en modo legacy), reduciendo la latencia y el consumo de CPU en nodos con muchas reglas.

3. Segmentación avanzada

OVN permite crear Logical Routers y Logical Switches que van más allá de los Namespaces. Puedes definir zonas de red (DMZ, backend, base de datos) con reglas de enrutamiento y ACLs propias, todo gestionado desde Kubernetes mediante CRDs.

4. Soporte para múltiples NICs y redes secundarias

OVN-Kubernetes soporta el concepto de redes secundarias (Multus CNI). Puedes tener una red principal para el tráfico interno y una red secundaria (por ejemplo, con IPs públicas) para servicios expuestos, todo gestionado por OVN.

Implementación práctica: Instalando OVN-Kubernetes

A continuación, se muestra un ejemplo simplificado de cómo instalar OVN-Kubernetes en un cluster existente usando kubectl y el repositorio oficial.

Requisitos previos

Kubernetes 1.24 o superior.
Nodos con kernel Linux 5.0+ (para Geneve).
Acceso SSH a los nodos para instalar OVS.

Pasos de instalación

Instalar Open vSwitch en todos los nodos:

# En Debian/Ubuntu
apt-get install openvswitch-switch -y

# En CentOS/RHEL
yum install openvswitch -y

Clonar el repositorio ovn-kubernetes:

git clone https://github.com/ovn-org/ovn-kubernetes
cd ovn-kubernetes

Desplegar los componentes de OVN:

# Configurar variables de entorno (ajustar según tu cluster)
export K8S_NODE_IPS="192.168.1.10 192.168.1.11"
export OVN_NET_CIDR="10.244.0.0/16"
export OVN_SVC_CIDR="10.96.0.0/12"

# Aplicar los manifiestos
kubectl apply -f dist/yaml/ovn-k8s-cni.yaml
kubectl apply -f dist/yaml/ovn-k8s-overlay.yaml

Verificar la instalación:

kubectl get pods -n ovn-kubernetes
# Deberías ver pods como ovn-master, ovn-controller, etc.

[WARNING] Asegúrate de que los puertos 6641 (OVN Northbound) y 6642 (OVN Southbound) no estén bloqueados por firewalls entre los nodos master y workers.

Segmentación de red con OVN: Casos de uso reales

Aislamiento multi-tenant

En un cluster compartido por varios equipos, puedes asignar un Logical Switch por Namespace y conectar solo los que necesiten comunicarse mediante un Logical Router con ACLs restrictivas.

apiVersion: k8s.ovn.org/v1
kind: OVNNetwork
metadata:
  name: tenant-a-network
spec:
  netID: 100
  subnet: "10.128.0.0/24"
  gateway: "10.128.0.1"

Redes separadas para tráfico interno y externo

Usando Multus, puedes adjuntar un segundo Logical Switch a Pods específicos para tráfico de alta velocidad (por ejemplo, almacenamiento o backups) sin mezclarlo con el tráfico general.

Monitorización y troubleshooting

OVN ofrece herramientas nativas para depurar la red:

ovn-trace: Simula el recorrido de un paquete a través de la red lógica.
ovs-ofctl dump-flows: Muestra los flujos OpenFlow activos en OVS.
kubectl ko (kube-ovn): Comando específico de OVN-Kubernetes para ver el estado de los Logical Switches.

Ejemplo de troubleshooting básico:

# Ver el estado de los Logical Switches
kubectl ko nbctl lr-list
kubectl ko nbctl ls-list

# Ver las ACLs aplicadas a un Logical Switch
kubectl ko nbctl acl-list <switch-name>

Consideraciones de rendimiento y escalabilidad

Aunque OVN+OVS es extremadamente potente, no está exento de consideraciones:

Overhead de encapsulación: Geneve añade 50 bytes por paquete. Para cargas de trabajo sensibles a MTU, ajusta el MTU de los Pods a 1450.
Consumo de memoria: OVS puede consumir entre 500MB y 2GB de RAM en nodos con muchos flujos. Monitorea con ovs-appctl memory/show.
Latencia de convergencia: En clusters muy grandes (>1000 nodos), la base de datos Southbound puede tardar segundos en sincronizarse. Usa la opción --nb-raft para mejorar la consistencia.

[INFO] Para entornos de producción con alta criticidad, considera usar OVS-DPDK (Data Plane Development Kit) para acelerar el procesamiento de paquetes mediante bypass del kernel. Esto requiere CPUs con soporte de aislamiento y memoria HugePages.

Conclusión: ¿Es OVN+OVS adecuado para tu cluster?

La combinación de SDN, OVN y Open vSwitch representa el estado del arte en redes para Kubernetes. Ofrece una segmentación granular, un rendimiento predecible y una escalabilidad que pocas soluciones CNI pueden igualar. Sin embargo, su complejidad operativa es mayor que la de alternativas como Flannel o Weave.

Elige OVN+OVS si:

Gestionas clusters con más de 100 nodos.
Necesitas un control detallado de políticas de red (multi-tenant, DMZ).
Requieres integración con SDN corporativas (NSX, OpenStack).
Buscas una solución que soporte redes secundarias y múltiples NICs.

Para clusters pequeños o entornos de desarrollo, soluciones más ligeras como Calico (modo eBPF) o Cilium pueden ser más apropiadas. Pero si tu objetivo es construir una infraestructura de red robusta, escalable y preparada para el futuro, OVN+OVS es, sin duda, la opción más sólida.

La adopción de SDN con OVN en Kubernetes no es solo una tendencia, es una necesidad para quienes buscan dominar la complejidad de las redes en la era cloud-native. ¿Estás listo para dar el salto?