Kubernetes: Networking

Raul Unzue Pulido 28 julio, 2020 Kubernetes, Linux, Virtualizacion 1 Comentario 4,503 Vistas

Kubernetes: Networking

Hoy os vamos a explicar los aspectos internos de las redes de Kubernetes. El capítulo de Networking en Kubernetes es el más complejo de explicar y manejar. Esto se debe a que Kubernetes se compone de varios nodos y dentro de ellos corren Contenedores y Pods que normalmente tienen que interrelacionarse entre ellos. Algo que, con Docker, por ejemplo, no pasa, ya que reside todo en el mismo host y simplemente se generan redes virtuales que residen en él.

Existen varios tipos de comunicaciones de red en un clúster Kubernetes:

Contenedor a Contenedor
Pod a Pod
Pod a Servicio
Tráfico externo a Servicio

Y existen a su vez unas reglas que tenemos que entender:

Los Pods del clúster de Kubernetes, da igual en que nodo corran, pueden comunicarse con otros Pods de diferentes nodos sin hacer NAT
Elementos como los demonios del sistema (Ejemplo: kubelet), pueden comunicarse con todos los Pods en ese nodo
Todos los contenedores pueden comunicarse entre sí directamente sin NAT
Todos los nodos pueden comunicarse con todos los contenedores (y viceversa) sin NAT
La IP que un contenedor ve, es la misma para sí y para el resto de componentes

Se puede decir, que cuando trabajamos con Pods de Kubernetes, se intenta alcanzar el modelo de red de la virtualización con máquinas virtuales, ya que cada Pod tiene una IP asignada de forma dinámica. Con lo que podemos usar esto para poder asignar puertos, descubrir servicios, equilibrio de carga…y poder llevar una aplicación que ya existía en una máquina virtual a Kubernetes.

Estas direcciones IP de las que hablamos que se asignan en los Pods, residen en el mismo Namespace. Y los contenedores que corren en esos Pods, que están en el mismo Namespace, son capaces de llegar a los puertos de escucha de cada contenedor dentro de ese Namespace.

Lo hay que tener claro, es que los contenedores dentro de cada Pod tienen que gestionar el uso de los puertos de escucha.

Y a nivel de host, es posible gestionar los puertos de escucha en los Pods y reenvíar a los puertos de escucha de los Pods. Siendo algo totalmente transparente para el Pod que está en ejecución.

La idea es que asignemos una subred para cada host y luego configuremos algún tipo de enrutamiento entre los hosts para reenviar el tráfico del contenedor de manera adecuada.

Para poder lograr esa comunicación entre los diferentes componentes del clúster, Kubernetes utiliza CNI (Container Network Interface) o una red superpuesta. Vamos a explicar un poco más en detalle esto…

En cuanto al CNI, es un proyecto de la Cloud Native Computing Foundation, que consiste en crear unas características y bibliotecas concretas para usar plugins que permitan configurar interfaces de red en contenedores de Linux.

URL PROYECTO: https://github.com/containernetworking/cni

Al final, la función principal del CNI es la conectividad de los contenedores, y la creación y eliminación de los recursos asignados a los contenedores cuando son creados o eliminados.

En el propio proyecto, se pone a disposición de los diferentes desarrolladores el código Go, de tal forma que sea más fácil crear plugins.

Existen diferentes plugins que nos permitirán crear una red superpuesta. ya creados por diferentes empresas VMware (NSX), Amazon ECS, Calico, Huawei, Google, Flannel,…y que se pueden cargar fácilmente en un clúster Kubernetes.

Uno de los plugins más utilizado en este contexto de red es Cálico. Que es un proyecto OpenSource que gestionaría la capa de red y adicionalmente implementa seguridad en el entorno, al integrarse dinámicamente con los cambios en el firewall del propio host donde están trabajando los contenedores.

Es un plugin muy escalable y que nos permite crecer a la vez que lo haga nuestra plataforma. Existe una versión Enterprise con las siguientes características extras:

• Política de red jerárquica
• Controles de acceso de salida (políticas de DNS, puertas de enlace de salida)
• Visualización de red y resolución de problemas
• Recomendaciones de política de red
• Vista previa y puesta en escena de la política de red
• Controles de cumplimiento e informes
• Detección de intrusos (actividad sospechosa, detección de anomalías)
• Gestión de múltiples clústeres con federación de múltiples nubes

Ejemplo de instalación de Calico:

https://docs.projectcalico.org/getting-started/kubernetes/quickstart

curl https://docs.projectcalico.org/manifests/calico-typha.yaml -o calico.yaml
kubectl apply -f calico.yaml

COMUNICACIONES EN UN CLUSTER DE KUBERNETES

CLUSTER A MASTER:
- Todos los canales de comunicación desde el clúster hacia el máster terminan en la ApiServer (ningún otro componente del Máster está diseñado para exponer servicios remotos)
- Normalmente, se usa para la comunicación HTTPS (TCP 443), donde la ApiServer escucha
- A los nodos se les proporciona un certificado raíz para que se puedan conectar con la ApiServer
- Los Pods se conectarán a la ApiServer a través de una cuenta de servicio
- Con todo esto, las conexiones por defecto dentro del clúster son totalmente seguras
MASTER A CLUSTER:
- Hay dos vías de comunicación del Máster(ApiServer) al Clúster, la primera es desde la ApiServer al proceso kubelet que se ejecuta en cada nodo del Clúster:
  - Recoger entradas de registro de Pods
  - Conectar (a través de kubectl) con Pods en ejecución
  - Facilitar la funcionalidad port-forwarding del kubelet
  - Se realiza mediante conexiones HTTPS
  - Por defecto, el apiserver no verifica el certificado del kubelet, por lo que la conexión es vulnerable a ataques del tipo man-in-the-middle, e insegura para conectar a través de redes públicas o de no confianza. Para asegurar la conexión se usa un certificado en su defecto un túnel SSH
  - Por eso, debemos habilitar la autorización y autenticación a kubelet para proteger nuestra API
- La segunda, es desde la ApiServer a cualquier nodo, Pod, o servicio a través de la funcionalidad proxy del ApiServer
APISERVER A NODOS, PODS Y SERVICIOS:
- Las conexiones desde el ApiServer a un nodo, pod o servicio se realizan por defecto con HTTP y, por consiguiente, no son autentificadas o encriptadas. En consecuencia, estas conexiones no son seguras, aunque podemos implementar HTTPS
TUNELES SSH:
- Kubernetes ofrece soporte para túneles SSH (TCP 22) que protegen la comunicación entre el Máster y el Clúster
- El túnel garantiza que dicho tráfico no es expuesto fuera de la red en la que se ejecutan los nodos
- Los túneles SSH se consideran obsoletos, y no deberían utilizarse a menos que se sepa lo que se está haciendo

PUERTOS TCP/IP NECESARIOS EN KUBERNETES

A su vez, para que nuestro clúster de Kubernetes trabaje correctamente, deberemos asegurarnos de que tanto los nodos maestros como los nodos de trabajo tengan los puertos en el firewall abiertos. Os dejo a continuación un par de tablas explicativas: