Nota. transl.: Este artigo, escrito por un enxeñeiro de SRE de LinkedIn, entra en detalles sobre a maxia interna en Kubernetes - máis precisamente, a interacción de CRI, CNI e kube-apiserver - que ocorre cando o seguinte pod necesita asignarlle un enderezo IP.
Un dos requisitos básicos é que cada pod debe ter o seu propio enderezo IP e calquera outro pod do clúster debe poder contactar con el nese enderezo. Hai moitos "provedores" de rede (Flannel, Calico, Canal, etc.) que axudan a implementar este modelo de rede.
Cando comecei a traballar con Kubernetes, non estaba do todo claro para min como obteñen exactamente os seus enderezos IP os pods. Mesmo cunha comprensión de como funcionaban os compoñentes individuais, era difícil imaxinalos traballando xuntos. Por exemplo, sabía para que eran os complementos CNI, pero non tiña idea de como se chamaban exactamente. Polo tanto, decidín escribir este artigo para compartir coñecementos sobre os distintos compoñentes da rede e como funcionan xuntos nun clúster de Kubernetes, o que permite que cada pod obteña o seu propio enderezo IP único.
Hai diferentes formas de organizar as redes en Kubernetes, do mesmo xeito que hai diferentes opcións de execución para os contedores. Esta publicación utilizará para organizar unha rede nun clúster e como ambiente executable - . Tamén supoño que sabes como funciona a conexión en rede entre contedores, así que vou tocar isto brevemente, só por contexto.
Algúns conceptos básicos
Os contedores e a rede: unha breve visión xeral
Hai moitas publicacións excelentes en Internet que explican como se comunican os contedores a través da rede. Polo tanto, só darei unha visión xeral dos conceptos básicos e limitarei a un enfoque, que implica crear unha ponte Linux e encapsular paquetes. Omítense detalles, xa que o tema da rede de contedores merece un artigo aparte. A continuación ofreceranse ligazóns a algunhas publicacións especialmente perspicaces e educativas.
Contedores nun só host
Unha forma de organizar a comunicación a través de enderezos IP entre contedores que se executan no mesmo host implica crear unha ponte Linux. Para este fin, créanse dispositivos virtuais en Kubernetes (e Docker) . Un extremo do dispositivo veth conéctase ao espazo de nomes de rede do contedor, o outro a na rede host.
Todos os contedores do mesmo host teñen un extremo do veth conectado a unha ponte a través da cal poden comunicarse entre si a través de enderezos IP. A ponte Linux tamén ten un enderezo IP e actúa como pasarela para o tráfico de saída dos pods destinados a outros nodos.
Contenedores en diferentes hosts
A encapsulación de paquetes é un método que permite que os contedores de diferentes nodos se comuniquen entre si mediante enderezos IP. En Flannel, a tecnoloxía é a responsable desta oportunidade. , que "empaqueta" o paquete orixinal nun paquete UDP e despois envíao ao seu destino.
Nun clúster de Kubernetes, Flannel crea un dispositivo vxlan e actualiza a táboa de rutas en cada nodo en consecuencia. Cada paquete destinado a un contedor nun host diferente pasa polo dispositivo vxlan e está encapsulado nun paquete UDP. No destino, o paquete aniñado extráese e envíase ao pod desexado.
Nota: esta é só unha forma de organizar a comunicación de rede entre contedores.
Que é CRI?
é un complemento que permite que kubelet utilice diferentes ambientes de execución de contedores. A API CRI está integrada en varios tempos de execución, polo que os usuarios poden elixir o tempo de execución que desexen.
Que é o CNI?
é un organizar unha solución de rede universal para contenedores Linux. Ademais, inclúe , responsable de varias funcións ao configurar unha rede de pods. O complemento CNI é un ficheiro executable que cumpre coa especificación (a continuación comentaremos algúns complementos).
Asignación de subredes a nodos para asignar enderezos IP aos pods
Dado que cada pod dun clúster debe ter un enderezo IP, é importante asegurarse de que este enderezo é único. Isto conséguese asignándolle a cada nodo unha subrede única, a partir da cal aos pods dese nodo se lles asignan enderezos IP.
Controlador IPAM de nodo
Cando nodeipam pasou como parámetro de marca --controllers , asigna unha subrede separada (podCIDR) a cada nodo do CIDR do clúster (é dicir, o intervalo de enderezos IP para a rede do clúster). Dado que estes podCIDR non se solapan, faise posible que cada pod teña asignado un enderezo IP único.
A un nodo de Kubernetes asígnaselle un podCIDR cando se rexistra inicialmente no clúster. Para cambiar o podCIDR dos nodos, cómpre anulalos e despois rexistralos de novo, facendo os cambios adecuados na configuración da capa de control de Kubernetes no medio. Pode mostrar o podCIDR dun nodo usando o seguinte comando:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, tempo de execución do contedor e complementos CNI: como funciona todo
A programación dun pod por nodo implica moitos pasos preparatorios. Nesta sección, centrareime só nos que están directamente relacionados coa configuración dunha rede de pods.
A programación dun pod para un determinado nodo desencadea a seguinte cadea de eventos:
FAQ: .
Interacción entre o tempo de execución do contedor e os complementos CNI
Cada provedor de rede ten o seu propio complemento CNI. O tempo de execución do contedor execútao para configurar a rede para o pod mentres se inicia. No caso de containerd, o complemento CNI é lanzado polo complemento .
Ademais, cada provedor ten o seu propio axente. Está instalado en todos os nodos de Kubernetes e é responsable da configuración da rede dos pods. Este axente inclúese coa configuración CNI ou créao de forma independente no nodo. A configuración axuda ao complemento CRI a definir a que complemento CNI chamar.
A localización da configuración do CNI pódese personalizar; por defecto está en /etc/cni/net.d/<config-file>. Os administradores do clúster tamén son responsables de instalar complementos CNI en cada nodo do clúster. A súa localización tamén é personalizable; directorio predeterminado - /opt/cni/bin.
Cando se usa containerd, os camiños para a configuración do complemento e os binarios pódense establecer na sección [plugins.«io.containerd.grpc.v1.cri».cni] в .
Xa que estamos a usar Flannel como o noso provedor de rede, imos falar un pouco sobre a súa configuración:
- Flanneld (o daemon de Flannel) adoita instalarse nun clúster como DaemonSet con
install-cnicomo . Install-cnicrea (/etc/cni/net.d/10-flannel.conflist) en cada nodo.- Flanneld crea un dispositivo vxlan, recupera os metadatos da rede do servidor da API e supervisa as actualizacións dos pods. A medida que se crean, distribúe rutas a todos os pods do clúster.
- Estas rutas permiten que os pods se comuniquen entre si a través de enderezos IP.
Para obter información máis detallada sobre o traballo de Flannel, recomendo usar as ligazóns ao final do artigo.
Aquí tes un diagrama da interacción entre o complemento Containerd CRI e os complementos CNI:
Como podes ver arriba, o kubelet chama ao complemento Containerd CRI para crear o pod, que logo chama ao complemento CNI para configurar a rede do pod. Ao facelo, o complemento CNI do provedor de rede chama a outros complementos CNI básicos para configurar varios aspectos da rede.
Interacción entre plugins CNI
Existen varios complementos de CNI cuxo traballo é axudar a configurar a comunicación de rede entre os contedores do host. Neste artigo discutiranse tres deles.
Complemento CNI Flannel
Cando se usa Flannel como provedor de rede, o compoñente Containerd CRI chama utilizando o ficheiro 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
}
}
]
}
O complemento Flannel CNI funciona en conxunto con Flanneld. Durante o inicio, Flanneld recupera podCIDR e outros detalles relacionados coa rede do servidor API e gárdaos nun ficheiro /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
O complemento Flannel CNI usa datos de /run/flannel/subnet.env para configurar e chamar ao complemento CNI bridge.
Complemento CNI Bridge
Este complemento chámase coa seguinte configuración:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Cando se chama por primeira vez, crea unha ponte Linux con «name»: «cni0», que se indica na configuración. Despois créase un veth par para cada vaina. Un dos seus extremos está conectado ao espazo de nomes da rede do contedor, o outro está incluído na ponte Linux na rede host. conecta todos os contenedores host a unha ponte Linux na rede host.
Unha vez rematado de configurar o par veth, o complemento Bridge chama ao complemento IPAM CNI local do host. O tipo de complemento IPAM pódese configurar na configuración CNI que usa o complemento CRI para chamar ao complemento Flannel CNI.
Complementos IPAM CNI do host local
Ponte chamadas CNI coa seguinte configuración:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Complemento IPAM local do host (IP Address Mxestión - xestión de enderezos IP) devolve o enderezo IP do contedor desde a subrede e almacena a IP asignada no host no directorio especificado na sección dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Este ficheiro contén o ID do contedor ao que está asignado este enderezo IP.
Ao chamar ao complemento IPAM local do host, devolve os seguintes datos:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Resumo
Kube-controller-manager asigna un podCIDR a cada nodo. Os pods de cada nodo reciben enderezos IP do espazo de enderezos no intervalo de podCIDR asignado. Dado que os podCIDR dos nodos non se solapan, todos os pods reciben enderezos IP únicos.
O administrador do clúster de Kubernetes configura e instala o kubelet, o tempo de execución do contedor, o axente do provedor de rede e copia os complementos CNI en cada nodo. Durante o inicio, o axente do provedor de rede xera unha configuración CNI. Cando se programa un pod nun nodo, o kubelet chama ao complemento CRI para crealo. A continuación, se se usa containerd, o complemento Containerd CRI chama ao complemento CNI especificado na configuración CNI para configurar a rede do pod. Como resultado, o pod recibe un enderezo IP.
Levoume algún tempo comprender todas as sutilezas e matices de todas estas interaccións. Espero que esta experiencia che axude a comprender mellor como funciona Kubernetes. Se me equivoco en algo, póñase en contacto comigo en ou no enderezo . Non dubide en poñerse en contacto se desexa discutir aspectos deste artigo ou calquera outra cousa. Encantaríame falar contigo!
referencias
Contedores e rede
Como funciona a franela?
CRI e CNI
PS do tradutor
Lea tamén no noso blog:
- «»;
- "Unha guía ilustrada de redes en Kubernetes": , ;
- «».
Fonte: www.habr.com