Kubernetes: differenze tra le versioni

Versione delle 15:15, 30 nov 2020

Versione attuale delle 19:10, 23 dic 2024

(15 versioni intermedie di 8 utenti non mostrate)

Riga 2:

|Nome = Kubernetes

|Logo = Kubernetes_logo_without_workmark.svg

|Sviluppatore = GoogleCloud Native Computing Foundation

|SistemaOperativo = Multipiattaforma

|Genere = Software per gestione cluster

Riga 8:

|DataPrimaVersione = 7 giugno 2014

}}

'''Kubernetes''' (abbreviato '''K8s''', pronunciato /ˌk(j)uːbərˈnɛtɪs/) è un sistema [[Open source|open-source]] di [[Orchestrazione (informatica)|orchestrazione]] e gestione di [[LXC|container]].<ref>{{Cita web|url=https://github.com/kubernetes/kubernetes/}}</ref> Inizialmente sviluppato da [[Google (azienda)|Google]], adesso è mantenuto da [[Cloud Native Computing Foundation]]. Funziona con molti sistemi di containerizzazione, compreso [[Docker]].

== Architettura ==

[[File:Kubernetes.png|miniatura|494x494px|Architettura di un cluster Kubernetes]]Kubernetes è un software formato da più componenti software dispostedistribuite secondoin ilnodi patternmaster [[Orchestratore nodi worker che formano il cluster pattern|orchestrator]]kubernetes. TaleUn patternnodo distingueè iun partecipantiserver infisico masteroppure eun nodiserver virtuale. Essi si coordinano per l'esecuzione deldei caricocarichi di lavoro suiovvero serverdelle cheapplicazioni vannocontainerizzate a(container). formare un [[Computer cluster|cluster]] controllato da Kubernetes.

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 {{chiarire|cluster}}. 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.

=== Control Plane Node ===

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 esponeimplementa e rende disponibili le [[Application programming interface|API]] di Kubernetes, eesponendo neuna rappresentainterfaccia laREST piùverso diffusalo implementazione.stato Siadel icluster. nodiEsso siarappresenta glil'unico operatori/amministratoricanale usanodi lecoordinamento APIe espostacontrollo, dalsia masterper comei uniconodi canaleche diper coordinamentogli e controllooperatori/amministratori.

==== Controller kube-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.

==== Schedulerkube-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 ====

Etcd<ref>{{Cita pubblicazione|data=2020-04-02|titolo=Container Linux di CoreOS|rivista=Wikipedia|lingua=it|accesso=2020-04-28|url=[[Container Linux di CoreOS|Etcd]]}}</ref> è il componente del master che si occupa di mantenere lo stato del sistema. IlI controllocomponenti del sistemacontrol avvieneplane specificandosono unstateless e fanno riferimento, tramite '''desired state'kube-apiserver'', allo (stato desiderato).mantenuto Ogniin partecipanteetcd. siPer attivaquesto permotivo contribuireanche ail mutaredemone il''etcd'' sistemaviene versoridondato ilnelle desiredinstallazioni statead definito[[High nelAvailability|alta masterdisponibilità]].

=== NodoWorker Node ===

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.

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]] o [[Container Linux di CoreOS|rkt]].

Generalmente unUn nodo è identificabile a uno a uno con un singolo server del cluster. Spesso quindi ci si riferisce a un gruppo di nodi direttamente con "cluster Kubernetes".

=== Nodo ===

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 a uno con un singolo server del cluster. Spesso quindi ci si riferisce a un gruppo di nodi direttamente con "cluster Kubernetes".

L'architettura decentralizzata del cluster permette a un nodo di mantenere una continuità limitata nel supportare il carico di lavoro anche in caso di fallimento nella comunicazione col master.

==== Kubeletkubelet ====

Il ''kubelet'' è il componente di control plane che controlla le risorse e gestisce il carico di lavoro su un singolo nodo. Mantiene una comunicazione col master e interviene costantemente sul nodo al fine di raggiungere e mantenere il desired state.

==== kube-proxy ====

Il componente [[proxy]] è dedicato all'inoltro del traffico fra i nodi e alla configurazione delle regole networking sugli stessi. Tramite il proxy viene resa trasparente la gestione dell'accesso ai ''service''.

==== Container runtime ====