Kubernetes
software
Logo
Logo
Schermata di esempio
Schermata di esempio
GenereSoftware per gestione cluster (non in lista)
SviluppatoreCloud Native Computing Foundation
Data prima versione7 giugno 2014
Ultima versione1.36.2 (12 giugno 2026)
Sistema operativoMultipiattaforma
LinguaggioGo
Licenzalicenza Apache 2.0
(licenza libera)
Sito webkubernetes.io

Kubernetes (abbreviato K8s, pronunciato /ˌk(j)uːbərˈnɛtɪs/) è un sistema open source di orchestrazione e gestione di container.[1] Inizialmente sviluppato da Google, adesso è mantenuto da Cloud Native Computing Foundation. Funziona con molti sistemi di containerizzazione, compreso Docker.

Architettura

modifica
Architettura di un cluster Kubernetes

Kubernetes è un software formato da più componenti software distribuite in nodi master e nodi worker che formano il cluster kubernetes. Un nodo è un server fisico oppure un server virtuale. Essi si coordinano per l'esecuzione dei carichi di lavoro ovvero delle applicazioni containerizzate (container).

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[non chiaro]. 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

modifica

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'alta disponibilità del servizio.

kube-apiserver

modifica

Questo componente implementa e rende disponibili le 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 sia per gli operatori/amministratori.

kube-controller-manager

modifica

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.

kube-scheduler

modifica

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

modifica

Etcd è il componente del master che si occupa di mantenere lo stato del sistema. I componenti del control plane sono stateless e fanno riferimento, tramite kube-apiserver, allo stato mantenuto in etcd. Per questo motivo anche il demone etcd viene ridondato nelle installazioni ad alta disponibilità.

Worker Node

modifica

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

Un nodo è identificabile 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.

kubelet

modifica

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

modifica

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

modifica

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.

Risorse del cluster

modifica

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 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 etichette chiave-valore chiamate "labels" a qualunque risorsa, come ad esempio a pod e nodi. Questo permette di creare riferimenti tra le varie risorse per implementare molteplici funzionalità.

Pod

modifica

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 API di Kubernetes o più di frequente tramite i controller che assicurano il mantenimento della loro esecuzione.

Service

modifica

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 a esso associati. I pod associati al service sono quelli che hanno in comune la label definita dal service. Di default un service è esposto all'interno di un cluster, ma può essere esposto anche all'esterno del cluster.[2]

Note

modifica
  1. ^ github.com, https://github.com/kubernetes/kubernetes/.
  2. ^ dasblinkenlichten.com, http://www.dasblinkenlichten.com/kubernetes-101-external-access-into-the-cluster/.

Voci correlate

modifica

Altri progetti

modifica

Collegamenti esterni

modifica
Controllo di autoritàGND (DE1153019000
  Portale Informatica: accedi alle voci di Wikipedia che trattano di informatica

📚 Artikel Terkait di Wikipedia

Linux Foundation

Grade Linux AGL technology Carrier Grade Linux Cloud Foundry Cloud Native Computing Foundation Kubernetes CNI Containerd CoreDNS Envoy Fluentd gRPC Jaeger

Google Cloud Platform

Google rilascia la versione 1 di Kubernetes e la consegna alla Cloud Native Computing Foundation agosto 2015 - Google Cloud Dataflow, Google Cloud Pub/Sub

Contributor License Agreement

luglio 2020 (archiviato dall'url originale il 24 gennaio 2014). ^ Cloud Native Computing Foundation, github.com, https://github.com/kubernetes/community/blob/master/CLA

Query

Italiana, 2013. (EN) Denis Howe, query, in Free On-line Dictionary of Computing. Disponibile con licenza GFDL Portale Informatica: accedi alle voci di

Aruba (azienda)

oltre ad autenticazione SPID. Ad essi, si aggiungono soluzioni di Cloud Computing, Private e Public Cloud, Cloud della PA. Aruba è membro dell'AIIP e socio

ChatGPT

ricompensa prevista. I modelli sono addestrati sull'infrastruttura di cloud computing Microsoft Azure, che fornisce la potenza di calcolo necessaria tramite

Google

statunitense Mark Ontkush (che nella propria pagina personale si definisce green computing consultant, ossia consulente in informatica ecologica) pubblicò un articolo

XCF (formato di file)

immagini raster nativo di GIMP. Il nome deriva da eXperimental Computing Facility. XCF è considerato un formato "vivente" essendo il formato nativo di GIMP ed