Architettura di un cluster Kubernetes - Tutorial Kubernetes

- [Istruttore] Diamo un'occhiata all'intera architettura cluster Kubernetes. Come puoi vedere, ha molte scatole e ancora più frecce. Analizziamo questo e ricostruiamolo. Innanzitutto, abbiamo il Nodo Master. Questo ragazzo è responsabile della gestione complessiva del cluster Kubernetes. Ha tre componenti che si occupano della comunicazione, della pianificazione e dei controller. Si tratta del server API, dell'Utilità di pianificazione e di Gestione cluster. Il server API Kube, come afferma il nome, consente di interagire con l'API Kubernetes. È il front-end del piano di controllo Kubernetes. Successivamente, abbiamo lo Scheduler. L'utilità di pianificazione consente di creare Pod creati, che non hanno ancora un design Node, e progetta il Pod per l'esecuzione su un Nodo specifico. Controller Manager esegue controller. Si tratta di thread in background che eseguono attività in un cluster. Il controller ha in realtà un sacco di ruoli diversi, ma è tutto compilato in un singolo binario. I ruoli includono il Node Controller, responsabile degli stati di lavoro, il Replication Controller, che è responsabile del mantenimento del numero corretto di Pod per i controller replicati, l'End-Point Controller, che unisce servizi e Pod. Account di servizio e controller token che gestiscono la gestione degli accessi. Infine, c'è quel CD, che è un semplice valore di chiave distribuita memorizzato. Kubernetes usa etcd come database e memorizza tutti i dati del cluster qui. Alcune delle informazioni che potrebbero essere memorizzate sono informazioni sulla pianificazione del lavoro, dettagli del pod, informazioni sul palco, ecc. E questo è il nodo principale. Si interagisce con il nodo master utilizzando l'applicazione Kubectl, che è l'interfaccia della riga di comando per Kubernetes. Kubectl è anche chiamato Kubectl, in alcuni casi, ma dirò Kubectl per il resto del corso. Kubectl ha un file di configurazione chiamato Kubeconfig. Questo file contiene informazioni sul server e informazioni di autenticazione per accedere al server API. Non arriveremmo da nessuna parte senza Worker Nodes, però. Questi nodi di lavoro sono i nodi in cui operano le applicazioni. I nodi di lavoro comunicano nuovamente con il nodo master. La comunicazione con un nodo di lavoro è gestita dal processo Kubelet. È un agente che comunica con il server API per vedere se i pod sono stati progettati per i nodi. Esegue i contenitori Pod tramite il motore del contenitore. Monta ed esegue il volume e i segreti del pod. E infine, è a conoscenza degli stati di Pod of Node e risponde al Master. È sicuro dire che se kubelet non funziona correttamente sul nodo di lavoro, avrai problemi. Come accennato in precedenza, Kubernetes è un agente di orchestrazione di container, quindi l'aspettativa è che tu abbia una piattaforma nativa del contenitore in esecuzione sui tuoi nodi di lavoro. È qui che entra in gioco Docker e collabora con Kubelet per eseguire i contenitori sul nodo. Potresti anche usare piattaforme di container alternative, come (borbotta), ma non molte persone lo fanno più. Il prossimo processo di cui parlerò è il Kube-proxy. Questo processo è il proxy di rete e il servizio di bilanciamento del carico per il servizio, su un singolo nodo di lavoro. Gestisce il routing di rete per i pacchetti TCP e UDP ed esegue l'inoltro della connessione. Va bene, siamo in homestretch. Avere il Docker Demon ti consente di eseguire contenitori. I contenitori di un'applicazione sono strettamente accoppiati insieme in un Pod. Per definizione, un Pod è l'unità più piccola che può essere pianificata come distribuzione in Kubernetes. Questo gruppo di contenitori condivide lo storage, lo spazio dei nomi Linux, gli indirizzi IP, tra le altre cose. Vengono anche localizzati e condividono risorse che sono sempre pianificate insieme. Una volta che i Pod sono stati distribuiti e sono in esecuzione, il processo Kubelet comunica con i Pod per verificare lo stato e l'integrità e il proxy Kube instrada tutti i pacchetti ai Pod da altre risorse che potrebbero voler comunicare con loro. I nodi di lavoro possono essere esposti a Internet tramite il servizio di bilanciamento del carico. Inoltre, il traffico che entra nei nodi viene gestito anche dal proxy Kube, che è il modo in cui un utente finale finisce per parlare con un'applicazione Kubernetes. Questa è l'intera architettura Kubernetes. Entreremo più in dettaglio su questi componenti nella prossima sezione. Ma, da un alto livello, sai come tutto funziona insieme.