Kubernetes: differenze tra le versioni

Versione delle 11:04, 28 apr 2020

Versione attuale delle 19:10, 23 dic 2024

(30 versioni intermedie di 17 utenti non mostrate)

Riga 1:

{{Software

|Nome = Kubernetes

|Logo = Kubernetes_logo_without_workmark.svg

|Logo =

|Sviluppatore = Cloud Native Computing Foundation

|SistemaOperativo = Multipiattaforma

|Genere = Software per gestione cluster

|SoftwareLibero = sì

|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 [[Linux Foundation|Cloud Native Computing Foundation]]. Funziona con molti sistemi di containerizzazione, compreso [[Docker]].

<br />

== 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|'''[[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.

=== MasterControl 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.

==== Schedulerkube-apiserver ====

Sia i nodi che gli operatori/amministratori usano l'[[Application programming interface|API]] esposta dal master come unico canale di coordinamento e controllo.

Questo componente implementa e rende disponibili le [[Application programming interface|API]] di Kubernetes, esponendo una interfaccia REST verso lo stato del cluster. Esso rappresenta l'unico canale di coordinamento e controllo, sia per i nodi che per gli operatori/amministratori.

==== kube-controller-manager ====

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.

Il controller manager si occupa costantemente di fare in modo che lo stato attuale del sistema coincida con il desired state all'interno del cosidettocosiddetto ''reconciliation loop''. Gli interventi necessari al raggiungimento del desired state vengono fatti da ''controller'' per specifiche funzionatiàfunzionalità attivati a loro volta dal controller manager.

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

[[Container Linux di CoreOS|Etcd]] è il componente del master che si occupa di mantenere lo stato del sistema. IlI controllocomponenti del sistemacontrol avvieneplane specificandosono unstateless '''desirede fanno riferimento, tramite 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à]].

==== ControllerWorker managerNode ====

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]].

Il controller manager si occupa costantemente di fare in modo che lo stato attuale del sistema coincida con il desired state all'interno del cosidetto ''reconciliation loop''. Gli interventi necessari al raggiungimento del desired state vengono fatti da ''controller'' per specifiche funzionatià attivati a loro volta dal controller manager.

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

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

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.

=== Nodo ===

Un nodo, anche chiamato worker, si occupa di eseguire il carico di lavoro secondo le modalità definite dal master.

==== kubelet ====

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

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.

== Struttura ==

==== Podskube-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''.

Il più semplice elemento in Kubernetes è il ''pod''. Il pod aggiunge un più alto livello di [[Astrazione (informatica)|astrazione]] raggruppando i container. All'interno di un pod i container condividono le risorse, mentre il pod si occupa di astrarre rete e storage al fine di poter spostare più facilmente un container all'interno del cluster. Ogni pod in Kubernetes ha il proprio [[Indirizzo IP]] dentro il cluster, questo permette alle applicazioni di usare diverse porte senza rischiare conflitti.<ref name="kubernetes-101-networking">{{Cita web|url=http://www.dasblinkenlichten.com/kubernetes-101-networking/}}</ref> Un pod può definire un volume, una sorta di disco locale o disco di rete e metterlo a disposizione a tutti i container all'interno del pod.<ref name="kubernetes-for-developers">{{Cita web|url=https://medium.com/fabric8-io/kubernetes-for-developers-2a9c7202fcd3#.b6u76jxar}}</ref> I pod possono essere gestiti manualmente tramite le [[Application programming interface|API]] di Kubernetes o tramite i controller.

==== LabelContainer runtime ====

Il carico di lavoro è composto da container che vengono eseguiti in un container runtime controllato dal kubelet. Il runtime astrae aspetti quali le risorse computazionali disponibili, lo storage e il networking. [[Docker]] è un esempio di container runtime compatibile con Kubernetes.

Kubernetes permette di aggiungere informazioni di tipo key-value chiamate "labels" a qualunque elemento all'interno del sistema, come ad esempio pod e [[Kubernetes#Kubernetes node|nodi]].

=== ServicesRisorse 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.

Un service Kubernetes è un insieme di pod che lavorano assieme, come uno strato di una applicazione [[Architettura multi-tier|multi-tier]]. Il set di pod che costituiscono un servizio sono definiti mediante label e selector. Di default un service è esposto all'interno di un cluster, ma può essere esposto anche all'esterno del cluster.<ref name="kubernetes-101-external-access">{{Cita web|url=http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/}}</ref>

L'utilizzo di un modello a risorse permette di descrivere con un [[Programmazione dichiarativa|linguaggio dichiarativo]] lo stato che il 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 informazionietichette di tipo keychiave-valuevalore chiamate "labels" a qualunque elemento all'interno del sistemarisorsa, come ad esempio a ''pod'' e [[Kubernetes#Kubernetes node|nodi]]. Questo permette di creare riferimenti tra le varie risorse per implementare molteplici funzionalità.

=== NodoPod ===

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.

=== Service ===

UnIl ''service'' Kubernetesdefinisce ècome unesporre insieme didei pod chesu lavoranouna assieme,rete comeinterna unoo stratoesterna. diIl unaservice applicazionedefinisce [[Architetturaun multi-tier|multi-tier]].nome Ilche setviene dirisolto dal DNS interno al cluster con uno dei pod chea costituisconoesso unassociati. servizioI pod associati al service sono definitiquelli medianteche hanno in comune la label edefinita selectordal service. Di default un service è esposto all'interno di un cluster, ma può essere esposto anche all'esterno del cluster.<ref name="kubernetes-101-external-access">{{Cita web|url=http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/}}</ref>

== Note ==

<references/>

== Voci correlate ==

* [[Container Linux di CoreOS]]

* [[OpenShift]]

== Altri progetti ==