Kubernetes networking – Parte 2

En la primera parte de esta serie de Posts estuvimos realizando una explicación básica de como funciona el Networking en Kubernetes.

En esta segunda parte de la serie de Blog Posts sobre Kubernetes Networking vamos a estar explorando los modelos de networking típicos en varias implementaciones de Kubernetes.

Modelos de Networking típicos en Kubernetes

Existen diferentes variantes de la implementación del Modelo de Networking en Kubernetes. Cualquiera de estas implementaciones debe tener las siguientes caracteristicas:

• Cada Pod debe tener una IP unica en todo el cluster.
• Los Pods deben comunicarse con otros Pods en todos los nodos sin utilizar NAT.
• Kubelet debe poder comunicarse con todos los Pods en el nodo.

Existen 3 tipos de implementaciones:

• Modelo Completamente Integrado (Flat).
• Modelo Bridge (Isla).
• Modelo Aislado (Air-gapped)

Característica	Modelo Completamente Integrado (Flat)	Modelo Bridge (Modo Isla)	Modelo Aislado (Air-gapped)
Asignación de IPs	IPs de pods asignadas directamente en la red de la VPC del clúster; requiere gran cantidad de IPs	IPs de pods pueden reutilizarse en otros clústeres, aunque con riesgos; requiere planificación cuidadosa	Todos los rangos internos pueden reutilizarse al no haber conexión con la red corporativa
Comunicaciones entre Pods	Directa sin necesidad de NAT	Requiere SNAT para tráfico outbound; comunicación entre pods dentro del clúster es directa	Comunicación solo dentro del clúster; sin acceso externo directo
Comunicaciones con Red Corporativa	Los pods pueden comunicarse sin NAT	Comunicación con red corporativa a través de Gateways o Proxies, usando SNAT	No tiene acceso a la red corporativa ni privada; solo acceso a APIs públicas
Requisitos de SDN	Integración profunda con la red subyacente; difícil en entornos on-premises	No requiere integración SDN profunda; adecuado para entornos on-premises	No se requiere SDN, ideal para entornos sin necesidades de conectividad externa
Compatibilidad con Service Mesh	Alta compatibilidad	No compatible debido a la dificultad de visibilidad IP	No compatible debido al aislamiento de red
Seguridad	Alta, pero requiere buena gestión de IPs y firewalls	Mayor control de seguridad; los pods no están expuestos directamente a la red externa	Seguridad por aislamiento completo
Telemetría y Debugging	Facilita monitoreo y depuración con IPs visibles en la red	Telemetría limitada y debugging difícil; solo muestra la IP del nodo	Muy limitada; difícil monitorear tráfico externo
Uso de Firewalls	Reglas de firewall más fáciles de configurar en los pods	Dificultades para configurar firewalls precisos; solo basado en IPs de nodos	No es necesario configurar firewalls externos

Estas 3 implementaciones varian en:

• Como los pods se comunican con servicios fuera de Kubernetes en la red corporativa.
• Como los podes se comunican con otros Clusters en la organización.
• Si NAT es necesario para la comunicación outbound-to-external.
• Si las IPs de los Pods pueden ser reutilizadas en otro cluster de la red corporativa.

Como se habrán dado cuenta, cada uno de los Cloud Providres puede implementar uno o más de estos modelos, dando varias opciones de implementación.

Modelo Completamente Integrado (Flat).

Una de las principales ventajas de este modelo es que los Cloud Providers pueden integrar estrechamente la implementación de Kubernetes con las Software-Defined Network (SDN).

La clave respecto del funcionamiento de este modelo es que las direcciones IP de los pods son ruteadas dentro de la red donde el Cluster se encuentra. La red subyacente sabe en que nodo se encuentran los pods. Esto puede ser manejado por las Routes en GCP o las Effective Routes en Azure.

En algunas implementaciones se utiliza un CIDR aislado y separado para los pods, pero no es una condicion obligatoria. En algunas implementaciones los Pods toman las ips de la misma red donde se encuentra el Cluster.

En esta implementación los pods no necesitan NAT para comunicarse con otras aplicaciones fuera del cluster.

Implementación en diferentes Cloud Providers:

• GKE utiliza este modelo con los VPC-native Clusters. Los rangos de Servicios y Pods son asignados como rangos secundarios de la VPC de los nodos. Para el trafico externo puede utilizarse SNAT para mapear la IP del Pod con la del nodo.
• AKS utiliza este modelo en las configuraciones de Azure CNI y Azure CNI dynamic. En Azure CNI, se utilizan IPs de la misma red de los Clusters y en el Dynamic podemos asignar una Subnet separada en la VNET para este fin, permitiendo diferentes implementaciones de NSG.
• En EKS se utiilza este modelo al utilizar el Amazon VPC Container Networking interface (CNI) Plugin. Permite asignar IPs a los pods directamente desde un espacio de direccions de una VPC. Esta subnet puede ser en la que se encuentran los nodos o una subnet dedicada. Parecido a la variación en AKS.

Ventajas:

• Mejor telemetría y debugging.
• Facilita la configuración de reglas de Firewall.
• Mejor compatibilidad.
• Compatibilidad con Service Mesh

Desventajas:

• Uso de Direcciones IPs extensivo ya que se necesitaran grandes cantidades para los pods.
• Requerimientos de SDN: requiere una integración muy profunda con la red subyacente. Dificil de implementar en Self-Managed/On-premises.

Modelo Bridge (Isla)

Este modelo es comunmente utilizado On-Premises donde no es posible realizar una integración estrecha con la red subyacente. Con este modelo los Pods pueden comunicarse con recursos fuera del cluster a través de un Gateway o Proxy. Los Pods dentro del Cluster pueden comunicarse libremente.

Para la implementación de los Proxys/Gateway existen diferentes modelos de implementación:

• Utilizar a los Nodos como Gateways: se utiliza SNAT para Outbound. Para la comunicación hacia los Services, se pueden utilizar los Services como NodePort o LoadBalancer.
• Utilizar Proxy VMs: las VMs deberán tener dos NICs, una en la red de los nodos y otra en la Enterprise Network.

Implementación en diferentes Cloud Providers:

• En GKE y EKS no se utiliza este modelo.
• Por defecto AKS utiliza este modelo cuando se utiliza Kubenet, se utilizan UDRs para el trafico Pod-to-Pod con Ip Forwarding a nivel de las NICs de los nodos. Para traficou outbound se utiliza SNAT.

Ventajas:

• Se pueden reutilizar las CIDR en otros clusters, aunque es un poco riesgoso para la comunicación externa. Debe planificarse cuidadosamente e igualmente se recomienda reservar un rango unico en toda la red para los pods y utilizar este rango para todos los clusters.
• Seguridad más facil: ya que los pods no están expuestos al resto de la red.

Desventajas:

• Telemetría imprecisa y dificil debugging: solo se tiene registro del trafico con la IP de los Nodos.
• Más dificil configurar firewalls: solo se puede usar la IP de los nodos.
• Incompatibilidad con Service Meshes.

Modelo Aislado (Air-gapped)

Este modelo es mayormente utilizado para los Clousters que no necesitan acceso a la red corporativa. Solo a través de Public APIs. En este modelo el cluster no puede comunicarse con otros recursos utilizando IPs privadas. Los Pods dentro del cluster pueden comunicarse libremente.

Este modelo no es comunmente utilizado pero se puede lograr una red aislada en cualquier implementación. Solo es necesario implementar el cluster en una red separada sin conectividad a otros servicios en la red corporativa.

Ventajas:

• Se pueden reutilizar todos los rangos internos.
• Seguridad por aislamiento total.

Desventajas:

• Sin comunicación privada.