Nota. trad.: Questo articolo, scritto da un ingegnere SRE di LinkedIn, approfondisce la magia interna di Kubernetes - più precisamente, l'interazione di CRI, CNI e kube-apiserver - che avviene quando al pod successivo deve essere assegnato un indirizzo IP.
Uno dei requisiti fondamentali è che ogni pod deve avere il proprio indirizzo IP e qualsiasi altro pod nel cluster deve essere in grado di contattarlo a quell'indirizzo. Esistono molti “fornitori” di rete (Flannel, Calico, Canal, ecc.) che aiutano a implementare questo modello di rete.
Quando ho iniziato a lavorare con Kubernetes, non mi era del tutto chiaro come esattamente i pod ottengano i loro indirizzi IP. Anche sapendo come funzionavano i singoli componenti, era difficile immaginarli lavorare insieme. Ad esempio, sapevo a cosa servivano i plugin CNI, ma non avevo idea di come si chiamassero esattamente. Pertanto, ho deciso di scrivere questo articolo per condividere la conoscenza sui vari componenti di rete e su come lavorano insieme in un cluster Kubernetes, che consente a ciascun pod di ottenere il proprio indirizzo IP univoco.
Esistono diversi modi per organizzare la rete in Kubernetes, così come esistono diverse opzioni di runtime per i contenitori. Questa pubblicazione utilizzerà organizzare una rete in un cluster e come ambiente eseguibile - . Presumo anche che tu sappia come funziona il networking tra contenitori, quindi ne parlerò brevemente, solo per contesto.
Alcuni concetti base
Container e rete: una breve panoramica
Su Internet sono disponibili numerose pubblicazioni eccellenti che spiegano come i contenitori comunicano tra loro in rete. Pertanto, fornirò solo una panoramica generale dei concetti di base e mi limiterò a un approccio, che prevede la creazione di un bridge Linux e l'incapsulamento dei pacchetti. I dettagli vengono omessi, poiché l’argomento stesso del networking dei contenitori merita un articolo a parte. Di seguito verranno forniti i collegamenti ad alcune pubblicazioni particolarmente approfondite ed educative.
Contenitori su un host
Un modo per organizzare la comunicazione tramite indirizzi IP tra contenitori in esecuzione sullo stesso host prevede la creazione di un bridge Linux. A questo scopo vengono creati dispositivi virtuali in Kubernetes (e Docker) . Un'estremità del veth dispositivo si connette allo spazio dei nomi di rete del contenitore, l'altra a sulla rete ospitante.
Tutti i contenitori sullo stesso host hanno un'estremità del veth collegata a un bridge attraverso il quale possono comunicare tra loro tramite indirizzi IP. Anche il bridge Linux ha un indirizzo IP e funge da gateway per il traffico in uscita dai pod destinato ad altri nodi.
Contenitori su host diversi
L'incapsulamento dei pacchetti è un metodo che consente ai contenitori su nodi diversi di comunicare tra loro utilizzando indirizzi IP. In Flannel, la tecnologia è responsabile di questa opportunità. , che “impacchetta” il pacchetto originale in un pacchetto UDP e poi lo invia a destinazione.
In un cluster Kubernetes, Flannel crea un dispositivo vxlan e aggiorna di conseguenza la tabella di routing su ciascun nodo. Ogni pacchetto destinato ad un contenitore su un host diverso passa attraverso il dispositivo vxlan e viene incapsulato in un pacchetto UDP. A destinazione, il pacchetto annidato viene estratto e inoltrato al pod desiderato.
Nota: questo è solo un modo per organizzare la comunicazione di rete tra contenitori.
Cos'è l'IRC?
è un plugin che consente a kubelet di utilizzare diversi ambienti di runtime del contenitore. L'API CRI è integrata in vari runtime, quindi gli utenti possono scegliere il runtime che preferiscono.
Cos'è il CNI?
Rappresenta organizzare una soluzione di rete universale per contenitori Linux. Inoltre, include , responsabile di varie funzioni durante la configurazione di una rete pod. Il plugin CNI è un file eseguibile conforme alle specifiche (discutiamo di alcuni plugin di seguito).
Assegnazione di sottoreti ai nodi per l'assegnazione di indirizzi IP ai pod
Poiché ciascun pod in un cluster deve avere un indirizzo IP, è importante garantire che questo indirizzo sia univoco. Ciò si ottiene assegnando a ciascun nodo una sottorete univoca, dalla quale ai pod su quel nodo vengono quindi assegnati gli indirizzi IP.
Controller IPAM del nodo
Quando nodeipam passato come parametro flag --controllers , alloca una sottorete separata (podCIDR) a ciascun nodo dal CIDR del cluster (ovvero, l'intervallo di indirizzi IP per la rete del cluster). Poiché questi podCIDR non si sovrappongono, diventa possibile assegnare a ciascun pod un indirizzo IP univoco.
A un nodo Kubernetes viene assegnato un podCIDR quando viene inizialmente registrato con il cluster. Per modificare il podCIDR dei nodi, è necessario annullarne la registrazione e quindi registrarli nuovamente, apportando le modifiche appropriate alla configurazione del livello di controllo Kubernetes nel frattempo. Puoi visualizzare il podCIDR di un nodo utilizzando il seguente comando:
$ kubectl get no <nodeName> -o json | jq '.spec.podCIDR'
10.244.0.0/24
Kubelet, container runtime e plugin CNI: come funziona
La pianificazione di un pod per nodo comporta molti passaggi preparatori. In questa sezione mi concentrerò solo su quelli direttamente correlati alla creazione di una rete pod.
La pianificazione di un pod su un determinato nodo attiva la seguente catena di eventi:
Informazioni: .
Interazione tra il runtime del contenitore e i plugin CNI
Ogni provider di rete ha il proprio plugin CNI. Il runtime del contenitore lo esegue per configurare la rete per il pod all'avvio. Nel caso di containerd, il plugin CNI viene avviato dal plugin .
Inoltre, ogni fornitore ha il proprio agente. È installato su tutti i nodi Kubernetes ed è responsabile della configurazione di rete dei pod. Questo agente è incluso nella configurazione CNI o lo crea in modo indipendente sul nodo. La configurazione aiuta il plug-in CRI a impostare quale plug-in CNI chiamare.
La posizione della configurazione CNI può essere personalizzata; per impostazione predefinita è presente /etc/cni/net.d/<config-file>. Gli amministratori del cluster sono anche responsabili dell'installazione dei plug-in CNI su ciascun nodo del cluster. Anche la loro posizione è personalizzabile; directory predefinita - /opt/cni/bin.
Quando si utilizza containerd, i percorsi per la configurazione del plugin e i binari possono essere impostati nella sezione [plugins.«io.containerd.grpc.v1.cri».cni] в .
Dato che utilizziamo Flannel come provider di rete, parliamo un po' della sua configurazione:
- Flanneld (il demone di Flannel) viene solitamente installato in un cluster come DaemonSet con
install-cnicome . Install-cnicrea (/etc/cni/net.d/10-flannel.conflist) su ciascun nodo.- Flanneld crea un dispositivo vxlan, recupera i metadati di rete dal server API e monitora gli aggiornamenti dei pod. Man mano che vengono creati, distribuisce le rotte a tutti i pod nel cluster.
- Questi percorsi consentono ai pod di comunicare tra loro tramite indirizzi IP.
Per informazioni più dettagliate sul lavoro di Flannel, consiglio di utilizzare i link alla fine dell'articolo.
Ecco un diagramma dell'interazione tra il plugin Containerd CRI e i plugin CNI:
Come puoi vedere sopra, kubelet chiama il plugin Containerd CRI per creare il pod, che poi chiama il plugin CNI per configurare la rete del pod. In tal modo, il plug-in CNI del provider di rete richiama altri plug-in CNI principali per configurare vari aspetti della rete.
Interazione tra plugin CNI
Esistono vari plugin CNI il cui compito è aiutare a impostare la comunicazione di rete tra i contenitori sull'host. Questo articolo ne discuterà tre.
Flanella plug-in CNI
Quando si utilizza Flannel come provider di rete, il componente Containerd CRI chiama utilizzando il file di configurazione 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
}
}
]
}
Il plugin Flannel CNI funziona insieme a Flanneld. Durante l'avvio, Flanneld recupera podCIDR e altri dettagli relativi alla rete dal server API e li salva in un file /run/flannel/subnet.env.
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=false
Il plugin Flannel CNI utilizza i dati da /run/flannel/subnet.env per configurare e chiamare il plugin bridge CNI.
Plug-in CNI Bridge
Questo plugin viene richiamato con la seguente configurazione:
{
"name": "cni0",
"type": "bridge",
"mtu": 1450,
"ipMasq": false,
"isGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24"
}
}
Quando viene chiamato per la prima volta, crea un bridge Linux con «name»: «cni0», che è indicato nel config. Quindi viene creata una quinta coppia per ciascun pod. Un'estremità è connessa allo spazio dei nomi di rete del contenitore, l'altra è inclusa nel bridge Linux sulla rete host. collega tutti i contenitori host a un bridge Linux sulla rete host.
Dopo aver terminato la configurazione della quinta coppia, il plug-in Bridge richiama il plug-in IPAM CNI host-locale. Il tipo di plug-in IPAM può essere configurato nella configurazione CNI utilizzata dal plug-in CRI per chiamare il plug-in Flannel CNI.
Plug-in CNI IPAM locale host
Bridge chiamate CNI con la seguente configurazione:
{
"name": "cni0",
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/24",
"dataDir": "/var/lib/cni/networks"
}
}
Plug-in IPAM locale dell'host (IP Andirizzo Management - gestione degli indirizzi IP) restituisce l'indirizzo IP del contenitore dalla sottorete e memorizza l'IP allocato sull'host nella directory specificata nella sezione dataDir - /var/lib/cni/networks/<network-name=cni0>/<ip>. Questo file contiene l'ID del contenitore a cui è assegnato questo indirizzo IP.
Quando si chiama il plug-in IPAM host-locale, restituisce i seguenti dati:
{
"ip4": {
"ip": "10.244.4.2",
"gateway": "10.244.4.3"
},
"dns": {}
}
Riassunto
Kube-controller-manager assegna un podCIDR a ciascun nodo. I pod di ciascun nodo ricevono indirizzi IP dallo spazio degli indirizzi nell'intervallo podCIDR allocato. Poiché i podCIDR dei nodi non si sovrappongono, tutti i pod ricevono indirizzi IP univoci.
L'amministratore del cluster Kubernetes configura e installa kubelet, runtime del contenitore, agente del provider di rete e copia i plug-in CNI su ciascun nodo. Durante l'avvio, l'agente del provider di rete genera una configurazione CNI. Quando un pod viene pianificato su un nodo, kubelet chiama il plugin CRI per crearlo. Successivamente, se viene utilizzato containerd, il plug-in Containerd CRI chiama il plug-in CNI specificato nella configurazione CNI per configurare la rete del pod. Di conseguenza, il pod riceve un indirizzo IP.
Mi ci è voluto del tempo per comprendere tutte le sottigliezze e le sfumature di tutte queste interazioni. Spero che questa esperienza ti aiuti a capire meglio come funziona Kubernetes. Se sbaglio qualcosa, per favore contattami a o all'indirizzo . Sentiti libero di contattarci se desideri discutere aspetti di questo articolo o qualsiasi altra cosa. Mi piacerebbe chiacchierare con te!
riferimenti
Contenitori e rete
Come funziona la flanella?
CRI e CNI
PS da traduttore
Leggi anche sul nostro blog:
- «";
- "Una guida illustrata alla rete in Kubernetes": , ;
- «'.
Fonte: habr.com