---
term: 'Kubernetes'
seoTitle: 'Kubernetes (K8s): che cos''è? Guida completa'
headline: 'Che cos''è Kubernetes (K8s)?'
slug: kubernetes
category: cloud-architecture
shortDefinition: 'Kubernetes è una piattaforma open-source che automatizza deployment, scalabilità e gestione di applicazioni containerizzate su molte macchine.'
relatedTerms:
  - containerization
  - infrastructure-as-a-service
  - microservices-vs-monolith
  - no-ops-development
  - ci-cd
contrastsWith:
  - no-ops-development
faq:
  - question: 'Che cos''è Kubernetes in parole semplici?'
    answer: 'Un direttore d''orchestra per i container. Si dichiara che cosa deve essere in esecuzione – questa app, tre copie, questa quantità di memoria – e Kubernetes fa coincidere la realtà con la dichiarazione, senza interruzioni: colloca i container sulle macchine, li riavvia quando crashano, li scala con il carico e indirizza il traffico verso le copie sane. Trasforma una flotta di macchine in un unico pool programmabile.'
  - question: 'Che cosa significa K8s?'
    answer: 'È un numeronimo: K, poi otto lettere, poi s – lo stesso schema di i18n per internationalization. Il nome in sé è greco: kubernetes significa timoniere o pilota, chi tiene la barra della nave, ed è anche il motivo per cui tanti strumenti del suo ecosistema portano nomi marinari e il logo è un timone.'
  - question: 'Kubernetes e Docker sono la stessa cosa?'
    answer: 'No: rispondono a domande diverse. Docker costruisce ed esegue singoli container su una macchina; Kubernetes orchestra molti container su molte macchine. Sono complementari: le immagini costruite con Docker girano sui cluster Kubernetes. Dalla versione 1.24 Kubernetes non usa più Docker come proprio runtime – parla con qualsiasi runtime di container standard – ma le immagini costruite con Docker funzionano esattamente come prima, perché seguono lo standard aperto OCI.'
  - question: 'Che cosa sono un cluster, un nodo e un pod?'
    answer: 'Il cluster è il sistema intero: un piano di controllo più le macchine worker. Un nodo è una macchina al suo interno, fisica o virtuale. Un pod è l''unità distribuibile più piccola: uno o più container strettamente accoppiati che condividono identità di rete e archiviazione. Un pod nudo non si esegue quasi mai; si dichiara un Deployment, e dei pod si occupa Kubernetes.'
  - question: 'Che cos''è il piano di controllo di Kubernetes?'
    answer: 'Il cervello del cluster: un API server attraverso cui passa tutto, un archivio chiave-valore che tiene lo stato desiderato e quello effettivo del cluster, uno scheduler che decide su quale nodo finisce ogni pod e dei controller che riconciliano senza sosta la realtà con le dichiarazioni. I nodi worker eseguono un agente, un proxy di rete e il runtime di container che esegue davvero i pod.'
  - question: 'Chi ha creato Kubernetes e quando?'
    answer: 'È stato rilasciato come open source nel giugno 2014, nato da più di un decennio di esperienza interna di orchestrazione di container in una delle più grandi aziende tecnologiche, e ha raggiunto la versione 1.0 nel luglio 2015, quando è stato donato alla neonata Cloud Native Computing Foundation (CNCF). Scritto in Go, da allora è diventato uno dei più grandi progetti open source del mondo.'
  - question: 'Quando Kubernetes è sovradimensionato?'
    answer: 'Più spesso di quanto l''entusiasmo ammetta. Un team piccolo che gestisce una manciata di container con traffico prevedibile guadagna poco da un cluster ed erediterà una curva di apprendimento ripida, una proliferazione di YAML e una disciplina operativa pensata per problemi su scala di flotta. Strade più semplici – un file compose su un solo host, una piattaforma di container gestita, un PaaS o un BaaS – coprono quasi tutti i carichi al di sotto della scala seria.'
  - question: 'Che cos''è il Kubernetes gestito?'
    answer: 'Un servizio cloud che esegue il piano di controllo al posto del team – aggiornamenti, disponibilità, archivio dello stato – mentre restano da gestire i carichi e i pool di nodi. Toglie di mezzo il livello operativo più difficile ed è il modo in cui gira davvero la maggior parte dei Kubernetes in produzione. Gestire un cluster da capo a fondo in autonomia resta dominio dei team di piattaforma con competenze dedicate: il piano di controllo è infrastruttura che non perdona.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'Kubernetes documentation — Overview'
    url: 'https://kubernetes.io/docs/concepts/overview/'
  - name: 'Kubernetes components (kubernetes.io)'
    url: 'https://kubernetes.io/docs/concepts/overview/components/'
  - name: 'Cloud Native Computing Foundation — Kubernetes'
    url: 'https://www.cncf.io/projects/kubernetes/'
  - name: 'Kubernetes (Wikipedia)'
    url: 'https://en.wikipedia.org/wiki/Kubernetes'
cta:
  title: 'Il backend senza il cluster'
  text: 'Back4app ti dà ciò che la maggior parte dei team vuole davvero da Kubernetes – servizi di backend distribuiti, scalati e auto-riparanti – senza gestirne uno: database gestito, autenticazione, API e funzioni Cloud Code. E quando un container ti serve davvero, Back4app Containers lo esegue per te.'
  linkText: 'Inizia gratis'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-02'
translationKey: kubernetes
---

**Kubernetes è una piattaforma open-source che automatizza deployment, scalabilità e gestione di applicazioni containerizzate su molte macchine.** La sua idea centrale è dichiarativa: si enuncia lo stato finale desiderato – *tre repliche di questo container, questa quantità di memoria, raggiungibile su questa porta* – e il sistema lavora senza sosta perché la realtà coincida, riavviando, rischedulando e scalando senza che nessuno lo chieda.

## Punti chiave

| Domanda | Risposta |
| --- | --- |
| Che cos'è | Un sistema di controllo che trasforma molte macchine in un unico pool per container |
| L'idea centrale | Si dichiara lo stato desiderato; il cluster riconcilia la realtà con esso, per sempre |
| vs. Docker | Docker costruisce ed esegue container; Kubernetes ne orchestra flotte intere |
| Il nome | "Timoniere" in greco; K8s = K + otto lettere + s |
| L'avvertenza onesta | Potenza su scala di flotta, complessità su scala di flotta – a molti team non serve né l'una né l'altra |

## Il manifest: come si parla a Kubernetes

Tutto è dichiarazione. Questo è un Deployment minimo e reale, annotato in parole chiare:

```yaml
apiVersion: apps/v1
kind: Deployment              # "N copie di questo sempre in esecuzione"
metadata:
  name: api
spec:
  replicas: 3                 # lo stato desiderato: tre pod
  selector:
    matchLabels: { app: api }
  template:                   # ciò che contiene ogni pod
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry.example.com/api:1.4.2
          ports: [{ containerPort: 8080 }]
          resources:
            limits: { memory: "256Mi", cpu: "500m" }
# Si applica, si uccide un pod, si guarda Kubernetes resuscitarlo. È questo il prodotto.
```

Per contrasto, lo stesso risultato (un backend distribuito, scalato, auto-riparante) consumato come servizio, dove il manifest, il cluster e la riconciliazione alle 3 del mattino sono YAML di qualcun altro:

**JavaScript:**

```javascript
// JavaScript / Node.js — Back4app JS SDK
// The workload the manifest would have described — already running
const status = await Parse.Cloud.run('healthCheck');
console.log(status); // scheduling, scaling, restarts: the platform's job
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
final function = ParseCloudFunction('healthCheck');
final response = await function.execute();
if (response.success) {
  print(response.result); // no pods, no manifests, no cluster to run
}
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
ParseCloud.callFunction("healthCheck") { result in
  if case .success(let status) = result {
    print(status) // no pods, no manifests, no cluster to run
  }
}
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
ParseCloud.callFunctionInBackground<String>("healthCheck", hashMapOf()) { status, e ->
  if (e == null) Log.d("Health", status) // no pods, no manifests, no cluster
}
```

## Dentro un cluster

```mermaid
flowchart TB
  accTitle: Architettura di un cluster Kubernetes
  accDescr: Un piano di controllo con un API server, un archivio dello stato, uno scheduler e dei controller gestisce i nodi worker; ogni nodo esegue un agente, un proxy di rete e un runtime di container che ospita i pod.
  subgraph CP["Piano di controllo – il cervello"]
    a["API server"] --- b["Archivio dello stato"]
    a --- c["Scheduler"]
    a --- d["Controller<br/>(riconciliano desiderato vs. effettivo)"]
  end
  subgraph N1["Nodo worker"]
    e["Agente + proxy di rete"] --> f["Pod<br/>(container)"]
  end
  subgraph N2["Nodo worker"]
    g["Agente + proxy di rete"] --> h["Pod"]
  end
  CP --> N1
  CP --> N2
```

Il vocabolario, una riga per voce: un **cluster** è il sistema intero; un **nodo** è una macchina; un **pod** è l'unità distribuibile più piccola (uno o più container che condividono rete e archiviazione); un **Deployment** gestisce pod replicati con rolling update e rollback; un **Service** dà ai pod effimeri un indirizzo stabile; un **Ingress** instrada il traffico dall'esterno verso l'interno; **ConfigMap e Secret** trasportano la configurazione; i **namespace** suddividono un cluster tra più team. [La panoramica ufficiale](https://kubernetes.io/docs/concepts/overview/) è il passo canonico immediatamente più in basso.

## Kubernetes vs. Docker

| Domanda | Docker | Kubernetes |
| --- | --- | --- |
| Ruolo | Costruire, impacchettare, eseguire container | Orchestrare container tra più macchine |
| Ambito | Una macchina | Un cluster |
| Unità | Il container | Il pod (di container) |
| Scalabilità | Manuale | Dichiarativa e automatica |
| Relazione | Costruisce le immagini | Le esegue, via qualsiasi runtime OCI standard |

La confusione perenne ha una data attaccata: dalla v1.24 (2022) Kubernetes ha abbandonato lo shim di runtime specifico per Docker e parla soltanto con runtime di container standard. Niente si è rotto – le immagini seguono lo standard aperto OCI – ma i ruoli sono diventati nitidi: Docker è il cantiere navale, Kubernetes è l'autorità portuale. Il nome lo sapeva da sempre: *kubernetes* in greco significa timoniere, e il progetto è stato [rilasciato come open source nel giugno 2014, ha raggiunto la 1.0 nel 2015 e ha dato origine alla CNCF](https://www.cncf.io/projects/kubernetes/), distillando un decennio di gestione di container su scala di flotta in un bene comune pubblico.

## Casi d'uso tipici

- **Flotte di microservizi.** Decine di servizi con scalabilità e rilasci indipendenti: il carico di lavoro che ha dato forma a Kubernetes.
- **Team di piattaforma.** Costruire una piattaforma interna su un substrato che gira identico su qualsiasi cloud o on-premises.
- **Carichi su larga scala a picchi.** Job batch, pipeline di dati, addestramento di modelli di ML, bin-packati su capacità condivisa.
- **Strategie multi-cloud e di portabilità.** Il livello di calcolo di una difesa dal [vendor lock-in](/glossary/it/vendor-lock-in-cloud/), con la riserva che i servizi gestiti attorno continuano a legare.
- **Parchi di produzione auto-riparanti.** Ovunque "una macchina è morta alle 3 del mattino" debba essere un non evento invece di una chiamata in reperibilità.

## Conviene eseguire Kubernetes? Matrice decisionale

| Eseguire Kubernetes quando… | Lasciar perdere quando… |
| --- | --- |
| Molti servizi, molti team, scalabilità indipendente | Un'app, un team, carico prevedibile |
| Un team di piattaforma possiede il cluster come proprio prodotto | Nessuno si occupa di ops a tempo pieno |
| La portabilità tra cloud è un requisito inderogabile | La velocità di arrivo sul mercato è l'unico requisito |
| I carichi sono containerizzati e hanno forma di flotta | Le esigenze di backend sono CRUD e autenticazione standard |
| Le orchestrazioni più semplici sono state superate | Un file compose o una piattaforma gestita bastano ancora |

Il consenso silenzioso del settore: la maggior parte dei team che gestiscono Kubernetes sta sotto la scala in cui si ripaga. La scala delle alternative – un host con un file compose, un servizio di container gestito, un PaaS, un BaaS – copre tutto fino ai veri problemi di flotta, e il Kubernetes gestito copre quasi tutto il resto.

## Limiti e trade-off

- **La curva di apprendimento è l'ombra del prodotto.** Pod, service, ingress, RBAC, operator, Helm: la scioltezza si misura in mesi, e il cluster non aspetta.
- **La superficie operativa.** Aggiornamenti, rotazione dei certificati, plugin di rete e salute dell'archivio dello stato non perdonano; è il motivo per cui i piani di controllo gestiti hanno vinto.
- **La proliferazione di YAML.** La configurazione dichiarativa su larga scala diventa una codebase a sé, con le proprie revisioni, i propri bug e la propria deriva.
- **Orchestra container, non architettura.** Un sistema con confini mal tracciati su Kubernetes è lo stesso sistema, ora distribuito: il cluster amplifica la progettazione, buona o cattiva.
- **Kubernetes non è un PaaS.** Per scelta di progetto non porta CI/CD, né database predefinito, né servizi a livello applicativo: la piattaforma al di sopra resta da assemblare, che è precisamente il lavoro che le astrazioni più alte rivendono come prodotto.

## Kubernetes su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il rapporto con Kubernetes è un'onesta divisione del lavoro: ciò che la maggior parte dei team applicativi vuole davvero da un cluster – servizi di backend distribuiti, scalati, auto-riparanti – è esattamente quanto il livello BaaS consegna con zero manifest da scrivere. E per i carichi che sono davvero container, [Back4app Containers](https://www.back4app.com/container-as-a-service) li esegue come servizio gestito: si fa il push di un'immagine e si ottiene l'orchestrazione, senza possedere il porto.