Arquitectura de Kubernetes: Comunicación y Red

En esta entrada siguiendo con los principios de la Arquitectura de Kubernetes vamos ver 4 diferentes tipos de comunicación y red, dentro de K8S.

Desafíos de Red

Durante la era monolítica de las aplicaciones, toda la lógica de negocio se hacía en la misma aplicación y en la misma red, con la llegada de los microservicios, esta lógica, se desacopla y para intentar seguir manteniendo «un acoplamiento», las redes y la comunicación se vuelven indispensable. La creación de redes, por lo general, suele dar complicaciones y suele ser difícil tanto de entender como de implementar, y en Kubernetes no es una excepción, para ello se abordan 4 desafíos de red diferentes:

• Contenedor a contenedor, comunicación dentro de los Pods.
• Pod a Pod, comunicación en el mismo nodo y en los nodos del cluster
• Comunicación de pod a servicio dentro del mismo espacio de nombres y en espacios de nombres de clúster.
• Comunicación externa a servicio para que los clientes accedan a las aplicaciones en un clúster.

Contenedor a Contenedor comunicación dentro de los Pods

Haciendo uso de las características del sistema operativo, en tiempo de ejecución de un contenedor se crea un espacio de red aislado para cada contenedor que se inicia. Ese espacio de red es denominado nombre de red (namespace). Ese namespace es compartido entre contenedores o con el sistema operativo.

Cuando se inicia un Pod, un namespace es creado dentro del Pod, y todos los conetenedores dentro del Pod compartirán ese namespace, por lo que podrán comunicarse uno con otro via localhost.

Comunicación Pod a Pod

En los clúster de Kubernetes, los Pods son planificados en nodos al azar. Independientemente de sus nodos, se espera que los Pods puedan comunicarse con otros Pods en el clúster, todo eso sin necesidad de implementar una Network Address Translation (NAT). Esto es un principio y requerimiento fundamental de cualquier implementación de redes en Kubernetes.

El modelo de red de Kubernetes tiene como objetivo reducir la complejidad, y trata los Pods como máquinas virtuales en una red, donde cada VM recibe una dirección IP, por lo que cada Pod recibe una dirección IP. Este modelo se llama «IP-per-Pod» y garantiza la comunicación de Pod a Pod, al igual que las máquinas virtuales pueden comunicarse entre sí

Los contenedores comparten el espacio de nombres de red del Pod y deben coordinar la asignación de puertos dentro del Pod tal como lo harían las aplicaciones en una VM; todo mientras pueden comunicarse entre sí mediante localhost, dentro del Pod. Sin embargo, los contenedores se integran con el modelo de red general de Kubernetes mediante el uso de la Container Network Interface (CNI) admitida por los complementos CNI. CNI es un conjunto de especificaciones y bibliotecas que permiten que los complementos configuren la red para contenedores. La mayoría de los complementos CNI son soluciones de redes definidas por software (SDN) de terceros que implementan el modelo de red Kubernetes. Además de abordar el requisito fundamental del modelo de red, algunas soluciones de red ofrecen soporte para políticas de red. Flannel, Weave, Calico son solo algunas de las soluciones SDN disponibles para los grupos de Kubernetes.

Comunicación del Pod al mundo exterior

Todas las aplicaciones desplegadas con éxito dentro de un Pod en un clúster dentro de Kubernetes, necesitan que sean accesibles desde el exterior. Para ello Kubernete lo hace accesible habilitando una serie de servicios en los que se encapsula una serie de reglas de red en los clúster del nodo. Los servicio se exponen al exterior gracias a Kube-proxy.

Conclusión.

En esta entrada hemos visto un resumen del proceso de Comunicación y red en la Arquitectura de Kubernetes. En la siguiente entrada, iremos entrando en faena y veremos los diferentes tipos de objetos de kubernetes.