Nota. transl.: Aquest article, escrit per un enginyer SRE de LinkedIn, detalla la "màgia interior" a Kubernetes -més precisament, la interacció de CRI, CNI i kube-apiserver- què passa quan cal assignar una adreça IP al següent pod.
Un dels requisits bàsics és que cada pod ha de tenir la seva pròpia adreça IP i qualsevol altre pod del clúster ha de poder contactar-hi a aquesta adreça. Hi ha molts "proveïdors" de xarxa (Flannel, Calico, Canal, etc.) que ajuden a implementar aquest model de xarxa.
Quan vaig començar a treballar amb Kubernetes, no estava del tot clar per a mi com els pods obtenen exactament les seves adreces IP. Fins i tot amb una comprensió de com funcionen els components individuals, era difícil imaginar-los treballant junts. Per exemple, sabia per a què servien els complements CNI, però no tenia ni idea de com es deien exactament. Per tant, vaig decidir escriure aquest article per compartir coneixements sobre els diferents components de la xarxa i com funcionen junts en un clúster de Kubernetes, que permet que cada pod obtingui la seva pròpia adreça IP única.
Hi ha diverses maneres d'organitzar la xarxa a Kubernetes, igual que les diferents opcions d'execució dels contenidors. Aquesta publicació utilitzarà per a la creació de xarxes en un clúster i com a entorn executable - . També suposo que sabeu com funciona la xarxa entre contenidors, així que només hi parlaré breument, només per context.
Alguns conceptes bàsics
Contenidors i xarxes d'un cop d'ull
Hi ha força publicacions excel·lents al web que expliquen com es comuniquen els contenidors entre si a través de la xarxa. Per tant, només donaré una visió general dels conceptes bàsics i em limitaré a un enfocament, que consisteix a crear un pont Linux i encapsular paquets. S'ometen detalls, ja que el tema de la xarxa de contenidors mereix un article a part. A continuació es proporcionaran enllaços a algunes publicacions especialment informatives i informatives.
Contenidors al mateix host
Una manera d'organitzar la comunicació d'adreces IP entre contenidors que s'executen al mateix host consisteix a crear un pont Linux. Per fer-ho, Kubernetes (i Docker) creen dispositius virtuals . Un extrem del dispositiu veth es connecta a l'espai de noms de xarxa del contenidor i l'altre extrem es connecta a la xarxa host.
Tots els contenidors del mateix host tenen un extrem de veth connectat a un pont a través del qual es poden comunicar entre ells mitjançant adreces IP. El pont Linux també té una adreça IP i actua com a passarel·la per al trànsit de sortida (de sortida) dels pods destinats a altres nodes.
Contenidors en diferents hosts
L'encapsulació de paquets és una manera en què els contenidors de diferents hosts es poden comunicar entre ells mitjançant adreces IP. A Flannel, la tecnologia és el que ho fa possible. , que "empaqueta" el paquet d'origen en un paquet UDP i després l'envia a la seva destinació.
En un clúster de Kubernetes, Flannel crea un dispositiu vxlan i actualitza la taula de rutes de cada node en conseqüència. Cada paquet destinat a un contenidor d'un altre host passa pel dispositiu vxlan i s'encapsula en un paquet UDP. A la destinació, el paquet imbricat es recupera i es redirigeix al pod correcte.
Nota: aquesta és només una de les maneres d'organitzar la xarxa entre contenidors.
Què és el CRI?
és un connector que permet al kubelet utilitzar diferents temps d'execució de contenidors. L'API CRI està integrada en diversos temps d'execució perquè els usuaris puguin triar el temps d'execució que vulguin.
Què és el CNI?
és un per organitzar una solució de xarxa universal per a contenidors Linux. A més, inclou , que són responsables de diverses funcions en configurar la xarxa d'un pod. Un connector CNI és un executable que s'ajusta a l'especificació (a continuació parlarem d'alguns dels connectors).
Amfitrions de subxarxes per assignar adreces IP als pods
Com que cada pod del clúster ha de tenir una adreça IP, és important assegurar-vos que aquesta adreça sigui única. Això s'aconsegueix assignant a cada node una subxarxa única, des de la qual els pods d'aquest node se'ls assignen adreces IP.
Controlador IPAM del node
Quan nodeipam passat com a paràmetre de bandera --controllers , assigna a cada node una subxarxa separada (podCIDR) del clúster CIDR (és a dir, l'interval d'adreces IP per a la xarxa del clúster). Com que aquests podCIDR no es superposen, és possible que a cada pod se li assigni una adreça IP única.
A un node de Kubernetes se li assigna un podCIDR quan es registra per primera vegada al clúster. Per canviar el podCIDR dels nodes, els heu de donar de baixa i després tornar-los a registrar, fent els canvis adequats a la configuració de la capa de control de Kubernetes entremig. Podeu mostrar el podCIDR d'un node amb l'ordre següent:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, temps d'execució del contenidor i complements CNI: com funciona tot
Programar un pod a un node implica fer molt treball preparatori. En aquesta secció, només em centraré en aquells que estan directament relacionats amb la configuració de la xarxa d'un pod.
La programació d'un pod a un node activa la següent cadena d'esdeveniments:
FAQ: .
Interacció entre el temps d'execució del contenidor i els connectors CNI
Cada proveïdor de xarxa té el seu propi connector CNI. El temps d'execució del contenidor l'executa per configurar la xarxa per al pod a mesura que s'inicia. En el cas de containerd, el connector CNI el llança .
A més, cada proveïdor té el seu propi agent. S'instal·la a tots els nodes de Kubernetes i és responsable de la configuració de xarxa dels pods. Aquest agent ve inclòs amb la configuració CNI o el crea pel seu compte al node. La configuració ajuda el connector CRI a determinar quin connector CNI ha de trucar.
Es pot configurar la ubicació de la configuració del CNI; per defecte està a /etc/cni/net.d/<config-file>. Els administradors del clúster també són responsables d'instal·lar connectors CNI a cada node del clúster. La seva ubicació també és configurable; directori predeterminat - /opt/cni/bin.
Quan utilitzeu containerd, els camins dels binaris de configuració i complement es poden establir a la secció [plugins.«io.containerd.grpc.v1.cri».cni] в .
Com que utilitzem Flannel com a proveïdor de xarxa, parlem una mica de la seva configuració:
- Flanneld (el dimoni de Flannel) s'instal·la normalment en un clúster com a DaemonSet amb
install-cnien qualitat . Install-cnicrea (/etc/cni/net.d/10-flannel.conflist) a cada node.- Flanneld crea un dispositiu vxlan, recupera metadades de xarxa del servidor de l'API i supervisa les actualitzacions del pod. A mesura que es creen, propaga les rutes a tots els pods del clúster.
- Aquestes rutes permeten que els pods es comuniquin entre ells mitjançant adreces IP.
Per obtenir més informació sobre el treball de Flannel, us recomano utilitzar els enllaços al final de l'article.
Aquí teniu el diagrama d'interacció entre el connector Containerd CRI i els connectors CNI:
Com s'ha vist anteriorment, el kubelet crida al connector Containerd CRI per crear el pod, que ja crida al connector CNI per configurar la xarxa del pod. En aquest cas, el connector CNI del proveïdor de xarxa crida a altres connectors CNI bàsics per configurar diversos aspectes de la xarxa.
Interacció entre connectors CNI
Hi ha diversos connectors CNI, la tasca dels quals és ajudar a configurar la comunicació de xarxa entre els contenidors de l'amfitrió. En aquest article en parlarem de tres.
Connector CNI de franela
Quan s'utilitza Flannel com a proveïdor de xarxa, el component Containerd CRI crida , utilitzant el fitxer de configuració 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 connector Flannel CNI funciona conjuntament amb Flanneld. Durant l'inici, Flanneld recupera el podCIDR i altres detalls relacionats amb la xarxa del servidor API i els desa en un fitxer. /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 connector Flannel CNI utilitza dades de /run/flannel/subnet.env per configurar i trucar al connector CNI pont.
Connector Bridge CNI
Aquest connector es crida amb la configuració següent:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
La primera vegada que es crida, crea un pont Linux amb «name»: «cni0», que s'especifica a la configuració. A continuació, es crea una parella veth per a cada beina. Un extrem es connecta a l'espai de noms de xarxa del contenidor, l'altre extrem es connecta a un pont Linux a la xarxa de l'amfitrió. connecta tots els contenidors host a un pont Linux a la xarxa host.
Un cop configurat el parell veth, el connector Bridge crida al connector IPAM CNI local de l'amfitrió. El tipus de connector IPAM es pot configurar a la configuració CNI que utilitza el connector CRI per cridar el connector CNI Flannel.
Connectors IPAM CNI de l'amfitrió local
Trucades de pont CNI amb la configuració següent:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Connector IPAM local de l'amfitrió (IP Address Mgestió - gestió d'adreces IP) retorna l'adreça IP del contenidor des de la subxarxa i emmagatzema l'IP assignada a l'amfitrió al directori especificat a la secció dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Aquest fitxer conté l'ID del contenidor al qual està assignada l'adreça IP donada.
Quan es crida al connector IPAM local de l'amfitrió, retorna les dades següents:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Resum
Kube-controller-manager assigna un podCIDR a cada node. Els pods de cada node obtenen adreces IP de l'espai d'adreces a l'interval podCIDR assignat. Com que els podCIDR dels nodes no es superposen, tots els pods obtenen adreces IP úniques.
L'administrador del clúster de Kubernetes configura i instal·la el kubelet, el temps d'execució del contenidor, l'agent del proveïdor de xarxa i copia els connectors CNI a cada node. Durant l'inici, l'agent del proveïdor de xarxa genera una configuració CNI. Quan un pod està programat en un node, el kubelet crida al connector CRI per crear-lo. A continuació, si s'utilitza containerd, el connector CRI de Containerd crida al connector CNI especificat a la configuració de CNI per configurar la xarxa del pod. Com a resultat, el pod obté una adreça IP.
Em va costar un temps entendre totes les subtileses i matisos de totes aquestes interaccions. Espero que l'experiència adquirida us ajudi a entendre millor com funciona Kubernetes. Si m'equivoco en alguna cosa, poseu-vos en contacte amb mi a o a l'adreça . No dubteu a posar-vos en contacte si voleu parlar d'aspectes d'aquest article o qualsevol altra cosa. Estaré encantat de xerrar amb tu!
Referències
Contenidors i xarxa
Com funciona la franela
CRI i CNI
PS del traductor
Llegeix també al nostre blog:
- «»;
- "Una guia il·lustrada per a les xarxes a Kubernetes": , ;
- «».
Font: www.habr.com