Kubernetes: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
Correzione definizione services |
Nessun oggetto della modifica |
||
Riga 21:
Il master è l'attore centrale di un cluster in quanto a lui fanno riferimento tutti gli altri nodi per coordinarsi nell'esecuzione dei container. Il master si occupa solo della funzione di orchestrare i nodi e non di eseguire container applicativi.
Sia i nodi
Essendo centrale al funzionamento del cluster, spesso il master viene replicato su più server in modo da garantire un'[[High Availability|alta disponibilità]] del servizio.
Riga 28:
Etcd<ref>{{Cita pubblicazione|data=2020-04-02|titolo=Container Linux di CoreOS|rivista=Wikipedia|lingua=it|accesso=2020-04-28|url=https://it.wikipedia.org/w/index.php?title=Container_Linux_di_CoreOS&oldid=111891044}}</ref> è il componente del master che si occupa di mantenere lo stato del sistema. Il controllo del sistema avviene specificando un '''desired state''' (stato desiderato). Ogni partecipante si attiva per contribuire a mutare il sistema verso il desired state definito nel master.
Lo stato del sistema viene rappresentato in Kubernetes mediante in concetto di '''risorsa'''. Sono definite delle risorse base sufficienti a far funzionare il cluster, che possono essere poi integrate con risorse definite da terzi per
==== Controller manager ====
Il controller manager si occupa costantemente di fare in modo che lo stato attuale del sistema coincida con il desired state all'interno del
==== Scheduler ====
Riga 39:
Un nodo, anche chiamato worker, si occupa di eseguire il carico di lavoro secondo le modalità definite dal master. Per poter eseguire i carichi di lavoro, il nodo deve disporre di un container runtime come [[Docker]].
Generalmente un nodo è identificabile a uno
L'architettura decentralizzata del cluster permette
==== Kubelet ====
Riga 50:
== Risorse del cluster ==
In Kubernetes lo stato del sistema è descritto mediante l'utilizzo del concetto di risorsa. Le risorse descrivono il '''desired state''', cioè lo stato desiderato del sistema. Una volta creata o modificata la descrizione di una risorsa sul master, le varie componenti di Kubernetes apportano le necessarie modifiche per variare dallo stato attuale del sistema verso lo stato desiderato. Alcuni esempi di modifiche al sistema possono essere l'avvio di nuovi container e la configurazione della rete per esporli su Internet.
L'utilizzo di un modello a risorse permette di descrivere con un [[Programmazione dichiarativa|linguaggio dichiarativo]] lo stato che in sistema deve assumere, senza la necessità di conoscere la tecnologia sottostante. Questo aspetto è particolarmente importante nei contesti cloud in cui Kubernetes viene offerto come servizio avendo la flessibilità di scelta sulla tecnologia sottostante.
Kubernetes permette di aggiungere etichette chiave-valore chiamate "labels" a qualunque risorsa, come ad esempio a ''pod'' e [[Kubernetes#Kubernetes node|nodi]]. Questo permette di creare riferimenti tra le varie risorse per implementare molteplici funzionalità.
===
Il ''pod'' è la risorsa che descrive l'unità elementare eseguibile su un nodo del cluster. Un pod raggruppa dei container che condividono le risorse e che vengono eseguiti sullo stesso nodo. Il pod si occupa di astrarre rete e storage al fine di poter essere spostato e replicato facilmente sui nodi del cluster, permettendo una forte [[scalabilità]] orizzontale, in particolare alle applicazioni orientate ai [[microservizi]].
I pod possono essere gestiti manualmente tramite le [[Application programming interface|API]] di Kubernetes o più di frequente tramite i controller che assicurano il mantenimento della loro esecuzione.
===
Il ''service'' definisce come esporre dei pod su una rete interna o esterna. Il service definisce un nome che viene risolto dal DNS interno al cluster con uno dei pod
== Vedi anche ==
| |||