Nota. traducir: Este artículo, escrito por un ingeniero SRE de LinkedIn, detalla la magia interna de Kubernetes (más precisamente, la interacción de CRI, CNI y kube-apiserver) que ocurre cuando es necesario asignar una dirección IP al siguiente pod.
Uno de los requisitos básicos. es que cada pod debe tener su propia dirección IP y cualquier otro pod en el clúster debe poder contactarlo en esa dirección. Hay muchos “proveedores” de redes (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 obtienen exactamente los pods sus direcciones IP. Incluso sabiendo cómo funcionaban los componentes individuales, era difícil imaginarlos trabajando juntos. Por ejemplo, sabía para qué servían los complementos CNI, pero no tenía idea de cómo se llamaban exactamente. Por lo tanto, decidí escribir este artículo para compartir conocimientos sobre los distintos componentes de la red y cómo funcionan juntos en un clúster de Kubernetes, lo que permite que cada módulo obtenga su propia dirección IP única.
Hay diferentes formas de organizar la red en Kubernetes, al igual que existen diferentes opciones de tiempo de ejecución para contenedores. Esta publicación utilizará para organizar una red en un clúster y como entorno ejecutable - . También asumo que usted sabe cómo funciona la red entre contenedores, así que lo abordaré brevemente, solo para contextualizarlo.
Algunos conceptos básicos
Los contenedores y la red: una breve descripción
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 Linux y encapsular paquetes. Se omiten detalles, ya que el tema de las redes de contenedores en sí merece un artículo aparte. A continuación se proporcionarán enlaces a algunas publicaciones particularmente interesantes y educativas.
Contenedores en un host
Una forma de organizar la comunicación a través de direcciones IP entre contenedores que se ejecutan en el mismo host implica crear un puente Linux. Para ello se crean dispositivos virtuales en Kubernetes (y Docker) . Un extremo del quinto dispositivo se conecta al espacio de nombres de red del contenedor, el otro al en la red anfitriona.
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í a través de direcciones IP. El puente de Linux también tiene una dirección IP y actúa como puerta de enlace para el tráfico de salida de los pods destinados a otros nodos.
Contenedores en diferentes hosts
La encapsulación de paquetes es un método que permite que los contenedores en diferentes nodos se comuniquen entre sí mediante direcciones IP. En franela, la tecnología es responsable de esta oportunidad. , que "empaqueta" el paquete original en un paquete UDP y luego lo envía a su destino.
En un clúster de Kubernetes, franela crea un dispositivo vxlan y actualiza la tabla de rutas en cada nodo en consecuencia. Cada paquete destinado a un contenedor en un host diferente pasa a través del dispositivo vxlan y se encapsula en un paquete UDP. En el destino, el paquete anidado se extrae y se reenvía al pod deseado.
Nota: Esta es sólo una forma de organizar la comunicación de red entre contenedores.
¿Qué es el IRC?
es un complemento que permite a kubelet utilizar diferentes entornos de ejecución de contenedores. La API CRI está integrada en varios tiempos de ejecución, por lo que los usuarios pueden elegir el tiempo de ejecución que prefieran.
¿Qué es el CNI?
representa organizar una solución de red universal para contenedores de Linux. Además, incluye , responsable de varias funciones al configurar una red pod. El complemento CNI es un archivo ejecutable que cumple con la especificación (analizaremos algunos complementos a continuación).
Asignación de subredes a nodos para asignar direcciones IP a pods
Dado que cada pod de un clúster debe tener una dirección IP, es importante asegurarse de que esta dirección sea única. Esto se logra asignando a cada nodo una subred única, desde la cual a los pods de ese nodo se les asignan direcciones IP.
Controlador IPAM de nodo
¿Cuándo nodeipam pasado como parámetro de bandera --controllers , asigna una subred separada (podCIDR) a cada nodo del CIDR del clúster (es decir, el rango de direcciones IP para la red del clúster). Dado que estos podCIDR no se superponen, es posible que a cada pod se le asigne una dirección IP única.
A un nodo de Kubernetes se le asigna un podCIDR cuando se registra inicialmente en el clúster. Para cambiar el podCIDR de los nodos, debe cancelar su registro y luego volver a registrarlos, realizando los cambios apropiados en la configuración de la capa de control de Kubernetes en el medio. 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, tiempo de ejecución de contenedores y complementos CNI: cómo funciona todo
Programar un pod por nodo implica muchos pasos preparatorios. En esta sección, me centraré únicamente en aquellos que están directamente relacionados con la configuración de una red pod.
La programación de un pod en un determinado nodo desencadena la siguiente cadena de eventos:
Información: .
Interacción entre el tiempo de ejecución del contenedor y los complementos CNI
Cada proveedor de red tiene su propio complemento CNI. El tiempo de ejecución del contenedor lo ejecuta para configurar la red para el pod cuando se inicia. En el caso de Containerd, el complemento CNI se inicia mediante el complemento. .
Además, cada proveedor tiene su propio agente. Se instala en todos los nodos de Kubernetes y es responsable de la configuración de red de los pods. Este agente se incluye con la configuración CNI o lo crea de forma independiente en el nodo. La configuración ayuda al complemento CRI a establecer a qué complemento CNI llamar.
La ubicación de la configuración CNI se puede personalizar; por defecto está 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; directorio predeterminado - /opt/cni/bin.
Cuando se utiliza Containerd, las rutas para la configuración del complemento y los archivos binarios se pueden configurar en la sección [plugins.«io.containerd.grpc.v1.cri».cni] в .
Dado que utilizamos franela como nuestro proveedor de red, hablemos un poco sobre cómo configurarlo:
- franela (el demonio de franela) generalmente se instala en un clúster como un DaemonSet con
install-cnicomo . Install-cnicrea (/etc/cni/net.d/10-flannel.conflist) en cada nodo.- franelad crea un dispositivo vxlan, recupera metadatos de red del servidor API y monitorea las actualizaciones del pod. A medida que se crean, distribuye rutas a todos los pods del clúster.
- Estas rutas permiten que los pods se comuniquen entre sí a través de direcciones IP.
Para obtener información más detallada sobre el trabajo de franela, 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 el pod, que luego llama al complemento CNI para configurar la red del pod. Al hacerlo, el complemento CNI del proveedor de red llama a otros complementos CNI principales para configurar varios aspectos de la red.
Interacción entre complementos CNI
Existen varios complementos de CNI cuyo trabajo es ayudar a configurar la comunicación de red entre contenedores en el host. Este artículo discutirá tres de ellos.
Complemento CNI Franela
Cuando se utiliza franela como proveedor de red, el componente Containerd CRI llama usando 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 franela CNI funciona junto con franela. Durante el inicio, Flanneld recupera 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 franela CNI utiliza datos de /run/flannel/subnet.env para configurar y llamar al complemento del puente CNI.
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"
}
}
Cuando se llama por primera vez, 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 está conectado al espacio de nombres de la red del contenedor, el otro está incluido en el puente de Linux en la red del host. conecta todos los contenedores de host a un puente de Linux en la red del host.
Una vez que haya terminado de configurar el par veth, el complemento Bridge llama al complemento IPAM CNI local del host. El tipo de complemento IPAM se puede configurar en la configuración CNI que utiliza el complemento CRI para llamar al complemento franela CNI.
Complementos IPAM CNI de host local
Puentear llamadas CNI con la siguiente configuración:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Complemento IPAM local de host (IP ADIRECCIÓN Mgestión - gestión de direcciones IP) devuelve la dirección IP para el contenedor de la subred y almacena la IP asignada en el host en el directorio especificado en la sección dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Este archivo contiene el ID del contenedor al que está asignada esta dirección IP.
Al llamar al complemento IPAM local del host, devuelve los siguientes datos:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Resumen
Kube-controller-manager asigna un podCIDR a cada nodo. Los pods de cada nodo reciben 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 tiempo de ejecución del contenedor, el agente del proveedor de red y copia los complementos CNI en cada nodo. Durante el inicio, el agente del proveedor de red genera una configuración CNI. Cuando un pod está programado para un nodo, kubelet llama al complemento CRI para crearlo. A continuación, si se utiliza Containerd, el complemento Containerd CRI llama al complemento CNI especificado en la configuración CNI para configurar la red del pod. Como resultado, el pod recibe una dirección IP.
Me tomó algún tiempo comprender todas las sutilezas y matices de todas estas interacciones. Espero que esta experiencia le ayude a comprender mejor cómo funciona Kubernetes. Si me equivoco en algo, por favor contáctame al o en la dirección . No dude en comunicarse si desea discutir aspectos de este artículo o cualquier otra cosa. ¡Me encantaría charlar contigo!
referencias
Contenedores y red
¿Cómo funciona la franela?
CRI y CNI
PD del traductor
Lea también en nuestro blog:
- «";
- "Una guía ilustrada para la creación de redes en Kubernetes": , ;
- «".
Fuente: habr.com