Puntos clave: La red Kubernetes es crucial para la comunicación dentro de un clúster, gestionando las interacciones entre contenedores. Abarca varios tipos de red y el papel de los servicios en el enrutamiento del tráfico.
- Los tipos de red aseguran una comunicación fluida sin necesidad de NAT.
- Los servicios abstraen el enrutamiento del tráfico a pods, mejorando la flexibilidad.
- Herramientas como Cilium y Flannel optimizan la red de Kubernetes.
La red Kubernetes es una parte integral para gestionar y facilitar la comunicación dentro de un clúster Kubernetes. Gestiona una amplia gama de operaciones, tales como:
- Gestión de la comunicación interna de contenedores
- Exponer los contenedores a internet
Este artículo te presenta conceptos clave de redes de Kubernetes.
Redes en Kubernetes
Primero, repasemos los tipos básicos de red en un clúster Kubernetes:
- Redes contenedor a contenedor
- Redes pod-to-pod
- Redes pod-to-service
- Redes de Internet a servicio
Ahora, veamos cómo funciona cada tipo para proporcionar conectividad dentro del clúster.
Redes contenedor a contenedor
En las configuraciones más básicas, la comunicación contenedor a contenedor dentro de un solo pod tiene lugar a través del localhost y los números de puerto. Esto es posible porque los contenedores en el pod son ubicados en el mismo espacio de nombres de red. Un espacio de nombres de red están una pila lógica de red que incluye rutas, reglas de cortafuegos y dispositivos de red, proporcionando una pila de red completa para los procesos dentro del espacio de nombres. Puede haber múltiples espacios de nombres en la misma máquina virtual. En Kubernetes, están un contenedor oculto llamado contenedor de pausa que se ejecuta en todos los pods de Kubernetes. Este contenedor mantiene abierto el espacio de nombres incluso si todos los demás contenedores del pod son no funcionales. A cada pod creado se está asignado un nuevo espacio de nombres de red. Los contenedores dentro del pod pueden utilizar este espacio de nombres de red a través de localhost. Sin embargo, el usuario debe ser consciente de los conflictos de puerto: Si los contenedores utilizan el mismo puerto, surgirán problemas de red dentro de los contenedores.
Redes pod-to-pod
A cada pod de un nodo Kubernetes se le asigna una dirección IP dedicada con un espacio de nombres dedicado. Debido a una asignación automática, los usuarios no necesitan Crea explícitamente enlaces entre pods. Esto nos permite realizar operaciones de red de pods como asignación de puertos, balanceo de carga y nombres, similar a una máquina virtual o un host físico. Kubernetes impone tres requisitos fundamentales a cualquier red.
- Los pods en un nodo pueden comunicarse con todos los pods en todos los nodos sin NAT.
- Los agentes en un nodo (demonios del sistema, kubelet) pueden comunicarse con todos los pods de ese nodo específico.
- Los pods en una red anfitriona de un nodo pueden comunicarse con todos los pods en todos los nodos sin NAT (solo para plataformas como Linux, que soporta pods que se ejecutan en la red anfitriona)
Comunicación entre pods en el mismo nodo
Kubernetes crea un adaptador ethernet virtual para cada pod, que está conectado al adaptador de red del nodo. Cuando se está realizada una solicitud de red, el pod se conecta a través del dispositivo ethernet virtual asociado al pod y tunela el tráfico hacia el dispositivo ethernet del nodo. En un nodo Kubernetes, está un puente de red llamado cbr0, que facilita la comunicación entre pods dentro de un nodo. Todos los pods son parte de este puente de red. Cuando se está realizada una solicitud de red, el puente comprueba el destino (pod) correcto y dirige el tráfico.
Comunicación entre pods en diferentes nodos
Cuando la dirección IP solicitada no se encuentra dentro del pod, el puente de red dirige el tráfico a la pasarela predeterminada. Esto buscaría la IP dentro del nivel del clúster. Kubernetes mantiene un registro de todos los rangos de IP asociados a cada nodo. Luego se están asignada una dirección IP a los pods dentro de los nodos desde el rango asignado al nodo. Cuando se están realizadas una solicitud a una dirección IP del clúster, será:
- Busca el rango de IP para la IP solicitada.
- Luego dirígete al nodo específico y después al pod correcto.
Redes pod-to-service
Un servicio están una abstracción que enruta el tráfico a un conjunto de pods. En otras palabras, un servicio asignará una única dirección IP a un conjunto de pods. Cuando se están realizada una solicitud de red, el servicio proxia la solicitud al pod necesario. Este servicio proxy se realiza mediante un proceso llamado Kube-proxy que se ejecuta dentro de cada nodo. El servicio Obtén su IP dentro del clúster cuando una solicitud llega por primera vez a la IP del servicio antes de ser reenviada a la IP real del pod. Esta es una característica importante en Kubernetes: desacopla la dependencia de la red directamente a cada pod. Los pods pueden crearse y destruirse sin preocuparse por la conectividad de red. Esto se están porque el servicio actualizará automáticamente sus endpoints cuando los pods cambian con la IP del pod. El servicio Obtén su IP dentro del clúster. Cualquier solicitud llega primero a la IP del servicio antes de ser reenviada a la IP real del Pod. Esta es una característica importante en Kubernetes, ya que desacopla la dependencia de la red directamente a cada Pod. Así, los pods pueden Obtén y destruirse sin preocuparse por la conectividad de red, ya que el servicio actualizará automáticamente sus endpoints con la IP del pod al que apunta a medida que los Pods cambian. Un servicio sabe a qué Pods dirigirse usando el selector de etiquetas. El selector de etiquetas está la primitiva de agrupación central en Kubernetes; mediante un selector de etiquetas, el cliente o usuario puede identificar un conjunto de objetos.
- El selector de etiquetas buscará las etiquetas especificadas en cada Pod y las comparará con el servicio en consecuencia.
- Sin el selector, los servicios correctamente configurados no pueden seguir los Pods y provocarán problemas de comunicación dentro del clúster.
DNS para enrutamiento interno en un clúster Kubernetes
Cada clúster viene con un servicio integrado para la resolución DNS.
- Se está asignado un nombre de dominio a cada servicio del clúster
- A los Pods se están asignados un nombre DNS.
(Estos pueden configurarse manualmente mediante el archivo YAML usando los campos de nombre de host y subdominio.) Cuando se están realizadas una solicitud mediante el nombre de dominio, el servicio DNS de Kubernetes resolverá la solicitud y la apuntará al servicio interno necesario desde el servicio. El proceso Kube-proxy la apuntará al pod de endpoint.
Redes de Internet a servicio
En las secciones anteriores, hemos cubierto los conceptos básicos de redes internas de un clúster Kubernetes. El siguiente paso están exponer la aplicación contenedora a internet. A diferencia de los tipos de redes anteriores, exponer el clúster Kubernetes a internet depende de ambos:
- Infraestructura subyacente de clúster
- Configuraciones de red
El método más común para gestionar el tráfico están mediante un balanceador de carga. En Kubernetes, podemos configurar balanceadores de carga. Cuando se están creado un servicio, los usuarios pueden:
- Especifica un balanceador de carga que exponga la dirección IP del balanceador.
- Dirige el tráfico al balanceador de carga y comunícate con el servicio a través de él.
Herramientas para redes Kubernetes
Son muchas herramientas que podemos utilizar para configurar la red dentro de Kubernetes cumpliendo todas las directrices y requisitos impuestos por el clúster.
- Cilium está un software de código abierto para proporcionar y asegurar la conectividad de red entre contenedores de aplicaciones. Cilium está consciente de L7/HTTP y puede hacer cumplir las políticas de red desde L3 hasta L7 utilizando modelos de seguridad basados en identidad.
- Flannel están una simple superposición de red que cumple con los requisitos de Kubernetes.
- Kube-router están una solución llave en mano para redes Kubernetes. Kube-router ofrece una alternativa ligera y potente a los componentes de red Kubernetes por defecto de un único DaemonSet/Binary.
- Antrea están una solución de red de código abierto nativa de Kubernetes que aprovecha Open vSwitch como plano de datos de red.
Y aquí son interfaces de red de contenedores específicas para proveedores en la nube:
- AWS VPC CNI para Kubernetes están el CNI específico de Amazon Web Services.
- Azure CNI for Kubernetes están el CNI específico de Microsoft Azure.
Por favor, consulte la documentación oficial de Kubernetes para la lista completa de herramientas de red disponibles.
La red K8s optimiza el rendimiento
La red de clúster Kubernetes puede configurarse para adaptarse a cualquier requisito del usuario y así optimizar el rendimiento de la aplicación contenedorizada y del clúster.
Lecturas relacionadas
Guía Kubernetes
- ¿Qué es Kubernetes (K8s)? Un tutorial básico de Kubernetes
- Mejores prácticas de Kubernetes para mejorar la eficiencia del clúster
- Mejores Prácticas: Cómo Diseñar Aplicaciones para Kubernetes
- Kubernetes Pods: Una introducción
- Kubernetes ReplicaSets: Una breve introducción
- Despliegues de Kubernetes completamente explicados
- Cómo utilizar y gestionar los DaemonSets de Kubernetes
- Cómo funcionan los servicios de Kubernetes
- Uso de Kubernetes Port, TargetPort y NodePort
- Creación y uso de ConfigMaps en Kubernetes
- Introducción a Kubernetes Secrets
- Fundamentos de las redes de Kubernetes
- Explicación de Kubernetes Ingress
- Introducción a las Listas de Helm de Kubernetes
- ¿Qué están el patrón de operador Kubernetes?
- Despliegue de PostgreSQL como un StatefulSet en Kubernetes
- Definición de Recursos Personalizados (CRDs) de Kubernetes Explicada
- 3 Patrones Kubernetes para aplicaciones nativas en la nube
- Explicación de los recursos de cómputo de Kubernetes
- Kubernetes Security for DevOps Pipelines
- Uso de spinnaker con Kubernetes para entrega continua
- Multi-Clústeres Kubernetes: Cómo y por qué utilizarlos
- Monitorización de Kubernetes: Una guía completa
- Kubernetes vs Docker: Una comparación rápida
- Kubernetes vs Docker Swarm: Comparando herramientas de orquestación de contenedores
- Kubernetes vs OpenShift: ¿Cuál es la diferencia?
- Certificaciones Kubernetes: Cómo y por qué Obtén la certificación
Estas publicaciones son mías y no representan necesariamente la posición, estrategias u opinión de BMC.