Conceptos básicos de networking en Kubernetes
Recientemente me dió por introducirme en la tecnología de Kubernetes y qué mejor manera de acercarse a esta que preparándose la certificación. Seguramente otras certificaciones más teóricas la mera presentación al exámen, previa revisión de las respuestas, nos aporte bien poco para su comprensión y aprendizaje pero esta es eminentemente práctica por lo que es una manera perfecta de comenzar a profundizar en ella.
Tras realizar un par de cursos orientados a la certificación y, dada mi vertiente escorada hacia las redes, encontré que el contenido al respecto de este tema es, en cierta medida, escaso por lo que este post lo dedico a enumerar las necesidades de comunicación que requiere Kubernetes .
Comunicación Contenedor a Contenedor (mismo host)
Un contenedor se puede comunicar con otro dentro del mismo host a través de la dirección de loopback del host (conocida como localhost o 127.0.0.1) o mediante mecanismos de comunicación entre porcesos (no hay que olvidar que al final un contenedor no es más que un proceso al que se le asignan y controlan recursos del sistema mediante las tecnologías de namespaces y cgroups)
Comunicación Pod a Pod
En este caso cabría considerar si los Pods (agrupación de contenedores compartiendo namespace) están en el mismo host o en uno distinto. En cualquier caso esta comunicación requiere del uso de cualquiera de los plugins (modelos de red) que implementen el Container Nertworking Interfce (CNI). Por enumerar unos pocos: Flannel, Calico, Weave-net o Cisco ACI. Cada uno de ellos implementa uno o más mecanismos de enrutamiento como rutas estáticas en los hosts y encapsulación VXLAN (Flannel), conexiones TCP malladas entre hosts (Weave-net) o simplemente routing BGP (Calico) entre, seguramente, otras muchas.
Cabe destacar que cada Pod posee su propio interfaz de red con su propia IP de modo que todos deben de poder comunicarse entre si sin emplear NAT.
Comunicación Pod a Servicio y Usuario a Servicio
Un servicio en kubernetes se puede definir como un conjunto de Pods más las políticas necesarias para accederlos como si fueran una única entidad (comunmente a esto se le llama microservicio). Bajando al lenguaje de redes, es una dirtección IP más su entrada DNS y los puertos necesarios para acceder a la funcionalidad que ofrecen un conjunto de Pods (o un único Pod). Estamos hablando que un servicio es el punto de conexión entre usuarios y la aplicación o entre aplicaciones.
Estos servicios se implementan a nivel del núcleo del sistema operativo en cada nodo del cluster kubernetes y es gestionado por el componente kube-proxy ya sea mediante el uso de IPtables o IPVS (IP Virtual Server). Por lo que he podido leer, su rendimiento es similar hasta llegar a los miles de servicios en los que ipvs mejora drásticamente en tiempos de resuesta.
