CNI, políticas de red, egress y la entrada de tráfico: las capas por debajo del service mesh. Incluida la salida de ingress-nginx, que ya no recibe parches de seguridad.
De confianza en toda Europa
Equipos de ingeniería en sectores regulados y críticos — cada proyecto auditado, documentado y llevado a nivel de producción.
Infraestructura de pagos y core bancario conforme a PCI-DSS — latencia p99 por debajo de 100 ms, trazabilidad de auditoría de extremo a extremo y tokenización en el edge.
Pipelines de datos de pacientes alineados con HIPAA
Observabilidad del core 5G a escala
99,99% de disponibilidad en picos de tráfico
Nube soberana con trazabilidad completa
Seguimiento de flotas en tiempo real e ingesta IoT
Qué entregamos
Todo lo que hay entre el nodo y tus servicios: cómo entran los paquetes, cómo se mueven entre pods y cómo salen del clúster.
Ingress-NGINX dejó de recibir versiones y parches de seguridad después de marzo de 2026. Inventariamos cada Ingress y sus anotaciones, elegimos una implementación de Gateway API, convertimos las rutas, ejecutamos ambos en paralelo y movemos el tráfico host a host.
Corte en paralelo · rollback por hostCilium, Calico o quedarte con lo que tienes. Algunos CNI, Flannel entre ellos, no aplican NetworkPolicy en absoluto, así que las políticas que escribiste pueden no estar haciendo nada. Probamos tu CNI frente a tus requisitos y, cuando hay que cambiarlo, migramos node pool a node pool.
Node pool a node pool · sin big bangKubernetes permite todo el tráfico entre pods hasta que una política diga lo contrario. Registramos el tráfico que realmente tienes, escribimos las reglas de permiso a partir de él y pasamos cada namespace a default-deny, uno a uno, con rollback preparado.
Observar primero · aplicar por namespaceUn pod comprometido que llega a todo internet es un canal de exfiltración. Restringimos el egress a los destinos que cada carga de trabajo necesita, por IP o por nombre DNS donde el CNI lo permite, y afinamos el DNS del clúster para que las resoluciones dejen de añadir latencia.
Egress con lista de permitidos · DNS que escalaEn bare metal no hay balanceador de la nube, así que configuramos el anuncio de las IP de servicio por BGP o en capa 2. Entre clústeres conectamos las redes de pods en L3 con políticas coherentes, y dejamos la gestión de tráfico L7 a un mesh donde lo necesites.
IP de servicio en bare metal · L3 entre clústeresCuando algo da timeout, la primera pregunta es si es la red. Los flow logs y la visibilidad de los paquetes descartados la responden en minutos en lugar de en una sala de crisis: qué pod, qué política, qué salto.
Flow logs · un motivo para cada descarteNuestros ingenieros revisan tu configuración actual y entregan una hoja de ruta priorizada — sin compromiso.
Las tres situaciones en las que este trabajo suele amortizarse más rápido.
La entrada de tu clúster depende de un controlador que ya no recibe parches de seguridad. Planificamos la migración a Gateway API en torno a tus anotaciones y certificados, y hacemos el corte host a host sin ventana de mantenimiento.
Cualquier pod llega a cualquier otro, y se acerca una auditoría o una evaluación de NIS2. Te llevamos a default-deny sin romper producción y dejamos las políticas en Git con pruebas.
Sin balanceador de la nube, varios clústeres y pods que necesitan hablar entre sí. Construimos el anuncio de IP de servicio en tu propia red y la conectividad L3 entre clústeres.
Una plataforma FinTech chocaba con cuellos de botella de kube-proxy a escala y sin visibilidad del tráfico entre pods, poniendo en riesgo tanto el rendimiento como el cumplimiento.
Cuello de botella de kube-proxy a 50K conexiones/seg, sin visibilidad de red.
Cilium con eBPF para el dataplane, Hubble para la observabilidad.
200K conexiones/seg, visibilidad L7 completa, 40% menos de latencia.
La mayoría de las redes de clúster crecieron por accidente: un CNI por defecto, unas pocas políticas que nadie probó, un controlador de ingress instalado hace años. Lo convertimos en un diseño que puedes explicar a un auditor y cambiar sin miedo, empezando por las partes que ya no reciben parches de seguridad.
Políticas aplicadas por un CNI que de verdad las hace cumplir y probadas contra el tráfico real, para que el movimiento lateral se detenga en el límite del namespace.
El tráfico de entrada en una implementación de Gateway API mantenida, en lugar de un controlador que ya no recibe parches.
Visibilidad de flujos que muestra qué política descartó qué paquete, para que saber si es la red lleve minutos.
Mapeamos tu CNI, cada Ingress y sus anotaciones, las políticas existentes, las rutas de egress y el DNS, y acordamos el diseño objetivo y el orden del trabajo.
Gateway API en paralelo con el controlador antiguo, políticas observadas antes de aplicarlas, cambios de CNI node pool a node pool, cada paso con rollback.
Runbooks, pruebas de políticas en CI y dashboards de flujos que tu equipo controla, además de alertas ante descartes inesperados.
De la primera llamada a producción — un modelo de colaboración probado en 4 pasos que mantiene la conversación transparente y la velocidad honesta.
Auditamos tu stack actual, identificamos carencias y alineamos los objetivos de negocio.
Una hoja de ruta detallada con prioridades, estimaciones de esfuerzo y quick wins.
Nuestros ingenieros se integran en tu equipo y ejecutan sprint a sprint.
Monitorización continua, optimización y transferencia de conocimiento a tu equipo.
Prácticas adyacentes que combinan bien con esta — la mayoría de los proyectos mezclan dos o tres.
Respuestas prácticas sobre alcance, plazos y cómo suelen ser los proyectos con nuestro equipo de Cloud Native Networking.
Tanto si empiezas de cero como si escalas lo que ya tienes, nuestros ingenieros están listos para ayudar.