Che cos'è Kubernetes (K8s)?

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

Il manifest: come si parla a Kubernetes

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

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 / 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 — 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
}

// 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
  }
}

// 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

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 è il passo canonico immediatamente più in basso.

Kubernetes vs. Docker

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, 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, 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

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 li esegue come servizio gestito: si fa il push di un’immagine e si ottiene l’orchestrazione, senza possedere il porto.