Uno de los requisitos básicos del modelo de red de Kubernetes es que cada pod debe tener su propia dirección IP, y todos los demás pod del clúster deben poder acceder a él en esa dirección. Hay muchos "proveedores" de red (Flannel, Calico, Canal, etc.) que ayudan a implementar este modelo de red.
Cuando comencé a trabajar con Kubernetes, no tenía del todo claro cómo exactamente los pods obtienen sus direcciones IP. Incluso con una comprensión de cómo funcionan los componentes individuales, era difícil imaginarlos trabajando juntos. Por ejemplo, yo sabía para qué eran los complementos CNI, pero no tenía idea de cómo se llamaban. Por lo tanto, decidí escribir este artículo para compartir mi conocimiento sobre varios componentes de red y cómo funcionan juntos en un clúster de Kubernetes, lo que permite que cada pod obtenga su propia dirección IP única.
Hay diferentes formas de organizar las redes en Kubernetes, al igual que hay diferentes opciones de tiempo de ejecución para los contenedores. Esta publicación usará Flannel para redes de clústeres y Containerd como tiempo de ejecución . También procedo de la suposición de que usted sabe cómo funciona la red entre contenedores, por lo que solo lo tocaré brevemente, únicamente por contexto.
Algunos conceptos basicos
Contenedores y redes: una descripción general
Hay muchas publicaciones excelentes en Internet que explican cómo los contenedores se comunican entre sí a través de la red. Por lo tanto, solo daré una descripción general de los conceptos básicos y me limitaré a un enfoque, que implica crear un puente de Linux y encapsular paquetes. Los detalles se omiten, ya que el tema mismo de las redes de contenedores merece un artículo aparte. A continuación se proporcionan enlaces a algunas publicaciones particularmente informativas e informativas.
Contenedores en un solo host
Una forma de establecer la comunicación de direcciones IP entre contenedores que se ejecutan en el mismo host es crear un puente de Linux. Para ello, se crean dispositivos virtuales veth (ethernet virtual) en Kubernetes (y Docker ) . Un extremo del dispositivo veth se conecta al espacio de nombres de la red del contenedor, el otro se conecta al puente de Linux en la red del host.
Todos los contenedores en el mismo host tienen un extremo del veth conectado a un puente a través del cual pueden comunicarse entre sí mediante direcciones IP. El puente de Linux también tiene una dirección IP y actúa como una puerta de enlace para el tráfico de salida de los pods a otros nodos.
Contenedores en diferentes hosts
La encapsulación de paquetes es una forma de permitir que los contenedores de diferentes hosts se comuniquen entre sí mediante direcciones IP. En Flannel , la tecnología vxlan es responsable de esta característica , que "empaqueta" el paquete original en un paquete UDP y luego lo envía a su destino.
En un clúster de Kubernetes, Flannel crea un dispositivo vxlan y aumenta la tabla de rutas en cada nodo en consecuencia. Cada paquete destinado a un contenedor en un host diferente pasa por el dispositivo vxlan y se encapsula en un paquete UDP. En el destino, el paquete anidado se extrae y se redirige al pod deseado.
Nota: esta es solo una forma de establecer una red entre contenedores.
¿Qué es CRI?
CRI (Container Runtime Interface) es un complemento que permite a kubelet utilizar diferentes entornos de ejecución de contenedores. La API de CRI está integrada en varios entornos de ejecución, por lo que los usuarios pueden elegir el tiempo de ejecución de su elección.
¿Qué es CNI?
El proyecto CNI es una especificación para organizar una solución de red universal para contenedores Linux. Además, incluye complementos responsables de varias funciones al configurar la red de un pod. El complemento CNI es un archivo ejecutable que cumple con la especificación (discutiremos algunos de los complementos a continuación).
Subnetting hosts para asignar direcciones IP a pods
Dado que cada pod del clúster debe tener una dirección IP, es importante asegurarse de que esta dirección sea única. Esto se logra asignando a cada host una subred única, desde la cual se asignan direcciones IP a los pods en ese host.
Controlador de IPAM de host
Cuando se
nodeipampasa como un parámetro al --controllers indicador kube-controller-manager , asigna una subred separada (podCIDR) para cada nodo del clúster CIDR (es decir, el rango de direcciones IP para la red del clúster). Dado que estos podCIDR no se superponen, es posible que cada pod asigne una dirección IP única.
A un nodo de Kubernetes se le asigna un podCIDR cuando se registra por primera vez en el clúster. Para cambiar el podCIDR de los nodos, debe anular el registro y luego volver a registrarlos, mientras tanto, realizar los cambios apropiados en la configuración de la capa de control de Kubernetes. Puede mostrar el podCIDR de un nodo usando el siguiente comando:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, lanzador de contenedores y complementos CNI: cómo funciona todo
La programación de un pod por nodo implica muchos pasos preparatorios. En esta sección, me centraré solo en aquellos que están directamente relacionados con las redes de pods.
La programación de un pod en un nodo desencadena la siguiente cadena de eventos:
Ayuda: Arquitectura del complemento CRI de Containerd .
Interacción entre los contenedores de tiempo de ejecución y los complementos CNI
Cada proveedor de red tiene su propio complemento CNI. El tiempo de ejecución del contenedor lo inicia para configurar la red para el pod a medida que se inicia. En el caso de containerd, el complemento Containerd CRI es responsable de iniciar el complemento CNI .
Además, cada proveedor tiene su propio agente. Está instalado en todos los nodos de Kubernetes y es responsable de la conexión en red de los pods. Este agente viene con la configuración CNI o la crea en el nodo por sí solo. La configuración ayuda al complemento CRI a determinar a qué complemento CNI llamar.
La ubicación de la configuración CNI se puede personalizar; por defecto se encuentra en
/etc/cni/net.d/<config-file>. Los administradores del clúster también son responsables de instalar complementos CNI en cada nodo del clúster. Su ubicación también es personalizable; el directorio predeterminado es /opt/cni/bin.
Cuando se utiliza containerd, las rutas de acceso para la configuración y los binarios de plugin se pueden fijar en una sección
[plugins.«io.containerd.grpc.v1.cri».cni]en el archivo de configuración containerd .
Como usamos Flannel como nuestro proveedor de red, hablemos un poco sobre cómo configurarlo:
- Flanneld (el demonio de Flannel) generalmente se instala en el clúster como un DaemonSet con
install-cniun contenedor de inicio . Install-cnicrea un archivo de configuración CNI (/etc/cni/net.d/10-flannel.conflist) en cada nodo.- Flanneld crea un dispositivo vxlan, obtiene metadatos de red del servidor API y monitorea las actualizaciones de pod. A medida que se crean, distribuye rutas para todos los pods en todo el clúster.
- Estas rutas permiten que los pods se comuniquen entre sí mediante direcciones IP.
Para obtener más información sobre cómo funciona Flannel, recomiendo utilizar los enlaces al final del artículo.
Aquí hay un diagrama de la interacción entre el complemento Containerd CRI y los complementos CNI:
Como puede ver arriba, kubelet llama al complemento Containerd CRI para crear un pod, y llama al complemento CNI para configurar la red del pod. Al hacerlo, el complemento CNI del proveedor de red invoca otros complementos CNI básicos para configurar varios aspectos de la red.
Interacción entre complementos CNI
Existen varios complementos CNI que están diseñados para ayudar a configurar la red entre contenedores en un host. Este artículo se centrará en tres de ellos.
Complemento Flannel CNI
Cuando se usa Flannel como proveedor de red, el componente Containerd CRI invoca el complemento Flannel CNI mediante el archivo de configuración CNI
/etc/cni/net.d/10-flannel.conflist.
$ cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cni0",
"plugins": [
{
"type": "flannel",
"delegate": {
"ipMasq": false,
"hairpinMode": true,
"isDefaultGateway": true
}
}
]
}
El complemento Flannel CNI funciona junto con Flanneld. Al inicio, Flanneld extrae el podCIDR y otros detalles relacionados con la red del servidor API y los guarda en un archivo
/run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
El complemento Flannel CNI utiliza los datos de
/run/flannel/subnet.envpara configurar e invocar el complemento CNI del puente.
Puente del complemento CNI
Este complemento se llama con la siguiente configuración:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
En la primera llamada, crea un puente de Linux con
«name»: «cni0», que se indica en la configuración. Luego se crea un quinto par para cada grupo. Un extremo se conecta al espacio de nombres de la red del contenedor y el otro al puente de Linux en la red del host. El complemento CNI Bridge conecta todos los contenedores de host al puente de Linux en la red de host.
Cuando termina de configurar el par veth, el complemento Bridge invoca el complemento CNI IPAM local del host. El tipo de complemento IPAM se puede configurar en la configuración CNI, que el complemento CRI utiliza para llamar al complemento Flannel CNI.
Complementos CNI de IPAM local de host
Bridge CNI llama al complemento CNI de IPAM local del host con la siguiente configuración:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
IPAM-plug-host local ( IP A ddress M GESTIÓN - gestión de dirección IP) devuelve la dirección IP de la subred del recipiente y almacena la IP seleccionada en el huésped en un directorio especificado en la sección
dataDir- /var/lib/cni/networks/<network-name=cni0>/<ip>. Este archivo contiene el ID del contenedor al que se le asigna esta dirección IP.
Cuando se llama al complemento IPAM local de host, devuelve los siguientes datos:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Resumen
Kube-controller-manager asigna podCIDR a cada nodo. Los pods de cada nodo obtienen direcciones IP del espacio de direcciones en el rango podCIDR asignado. Dado que los podCIDR de los nodos no se superponen, todos los pods reciben direcciones IP únicas.
El administrador del clúster de Kubernetes configura e instala kubelet, el lanzador de contenedores, el agente del proveedor de red y copia los complementos CNI en cada nodo. Durante el inicio, el agente del proveedor de red genera la configuración CNI. Cuando se programa un pod para un nodo, kubelet llama al complemento CRI para crearlo. Además, si se usa containerd, el complemento Containerd CRI llama al complemento CNI especificado en la configuración CNI para configurar la red de pod. Esto le da al pod una dirección IP.
Me tomó un tiempo descubrir todas las sutilezas y matices de todas estas interacciones. Espero que la experiencia adquirida le ayude a comprender mejor cómo funciona Kubernetes. Si me equivoco en algo, por favor contácteme en Twitter o en hello@ronaknathani.com . No dude en ponerse en contacto si desea discutir aspectos de este artículo o cualquier otra cosa. ¡Estaré encantado de hablar contigo!
Enlaces
Contenedores y Red
Cómo actúa la franela
CRI y CNI
PD del traductor
Lea también en nuestro blog: