Kubernetes: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Bot: fix sezioni standard |
→Master: aggiunto paragrafo dedicato a kube-apiserver |
||
Riga 15:
Le componenti che si occupano di controllare l'esecuzione dei container applicativi sono raggruppate nel '''[[control plane]]'''. Il '''data plane''' raggruppa invece le componenti software coinvolte nelle funzionalità che gestiscono il carico di lavoro del cluster.
===
Il master o Control Plane Node è 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. Esegue i processi della Control Plane ed essendo questi processi centrali al funzionamento del cluster, spesso il master viene replicato su più server in modo da garantire un'[[High Availability|alta disponibilità]] del servizio.
== kube-apiserver ==
Questo componente espone le [[Application programming interface|API]] di Kubernetes e ne rappresenta la più diffusa implementazione. Sia i nodi sia gli operatori/amministratori usano
==== 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 cosiddetto ''reconciliation loop''. Gli interventi necessari al raggiungimento del desired state vengono fatti da ''controller'' per specifiche funzionalità attivati a loro volta dal controller manager.▼
==== Scheduler ====▼
Lo scheduler decide come assegnare il carico di lavoro specificato dal desired state sui nodi che compongono il cluster. La scelta dei nodi a cui assegnare il carico dipende dall'algoritmo di allocazione usato. Nel caso più comune la scelta viene fatta in base alla disponibilità di risorse sui nodi.▼
==== Etcd ====
Line 26 ⟶ 31:
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 estendere le funzionalità disponibili.
▲==== 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 cosiddetto ''reconciliation loop''. Gli interventi necessari al raggiungimento del desired state vengono fatti da ''controller'' per specifiche funzionalità attivati a loro volta dal controller manager.
▲==== Scheduler ====
▲Lo scheduler decide come assegnare il carico di lavoro specificato dal desired state sui nodi che compongono il cluster. La scelta dei nodi a cui assegnare il carico dipende dall'algoritmo di allocazione usato. Nel caso più comune la scelta viene fatta in base alla disponibilità di risorse sui nodi.
=== Nodo ===
| |||