Come Funziona il Control Plane di Kubernetes

Kubernetes è diventato lo standard di fatto per l’orchestrazione di container in ambiente enterprise. Ma dietro le quinte, prima che i vostri container vengano eseguiti, c’è un complesso sistema di componenti che lavorano insieme per gestire l’intero cluster: il Control Plane (chiamato in precedenza Master Node).

In questo articolo esploreremo in dettaglio come funziona il control plane di Kubernetes, quali sono i suoi componenti principali e come questi si coordinano per mantenere lo stato desiderato del vostro cluster.

Cos’è il Control Plane?

Il control plane è il cervello del cluster Kubernetes. È responsabile di:

• Gestire lo stato: Mantiene traccia dello stato desiderato del cluster
• Orchestrare i workload: Decide dove e quando eseguire i container
• Monitorare la salute: Monitora costantemente lo stato dei nodi e dei pod
• Esporre le API: Fornisce l’interfaccia attraverso cui interagire con il cluster

Quando eseguite un comando kubectl per distribuire un’applicazione, non state comunicando direttamente con i nodi worker. State comunicando con il control plane, che poi orchestrerà l’esecuzione sui nodi appropriati.

Componenti Principali del Control Plane

1. API Server (kube-apiserver)

L’API Server è il cuore del control plane. È un’API REST che espone tutte le operazioni di Kubernetes.

Responsabilità:

• Accetta e processa le richieste da kubectl e da altri client
• Valida le richieste in base alle policy
• Salva lo stato nel database etcd
• Comunica con gli altri componenti del control plane

# L'API Server è raggiungibile su:
kubectl cluster-info

Quando eseguite il comando kubectl apply, la vostra richiesta finisce direttamente all’API Server, che la valida e ne registra le informazioni all’interno di etcd.

2. etcd - Il Database Distribuito

etcd è un database distribuito key-value ad alta disponibilità che memorizza tutto lo stato del cluster Kubernetes.

Cosa viene memorizzato:

• Configurazione di tutti i pod, servizi, e deployment
• Lo stato desiderato dei vostri workload
• Credenziali e configurazioni segrete
• Informazioni sullo stato dei nodi

Caratteristiche importanti:

• È il “source of truth” del cluster: tutto ciò che viene salvato all’interno del database rappresenta una fotografia puntuale della situazione del cluster, così che possa essere possibile ricostruire lo stato corrente del cluster.
• Deve essere sempre disponibile e resiliente: questo significa che se si verifica un errore, il cluster potrebbe diventare instabile o addirittura non funzionare. Per questo motivo, è fondamentale configurare etcd in modalità alta disponibilità.
• Utilizza il consenso (RAFT) per la replicazione: ogni nodo ha una copia del database, e se un nodo leader va in errore, un nuovo leader viene eletto automaticamente (il funzionamento di RAFT è certamente più complesso di così, ma questa è sicuramente un’idea iniziale utile)

3. Controller Manager (kube-controller-manager)

Il Controller Manager è un demone che esegue continuamente i controller - loop di riconciliazione che monitorano lo stato del cluster.

Controller principali:

• Replication Controller: Assicura che il numero desiderato di pod sia in esecuzione
• Deployment Controller: Gestisce i deployment e gli aggiornamenti
• StatefulSet Controller: Gestisce applicazioni stateful
• DaemonSet Controller: Assicura che ogni nodo esegua una copia di un pod
• Service Controller: Crea e gestisce i load balancer
• Node Controller: Monitora la salute dei nodi e li rimuove dal cluster se non raggiungibili

Ogni controller esegue continuamente un loop che:

1. Osserva lo stato attuale
2. Lo confronta con lo stato desiderato
3. Esegue azioni per riconciliare le differenze
4. Ripeti

Questo vuol dire che non è l’API server che si occupa di ripristinare un Pod che è stato cancellato o che ha un errore: l’API server memorizza lo stato delle risorse e invia notifiche alle risorse interessante. Così come lo scheduler si occupa di assegnare i Pod ai nodi, ma non di crearli: infatti, è il controller manager che, tramite questo meccanismo implementato con un loop, osserva eventuali cambiamenti nel cluster e riporta il cluster allo stato desiderato.

Ad esempio, se un pod viene eliminato da un Deployment, il controller manager rimuove il pod dal cluster. Salvo che il ReplicaSet, ossia la risorsa creata dal Deployment, rileva che il numero di Pod in esecuzione non è più sufficiente e ne crea uno nuovo, seguendo quanto descritto in termini di stato all’interno di etcd.

Il funzionamento è del tutto simile in qualsiasi altro controller, con la differenza che ognuno valuta lo stato delle risorse che gestisce.

La domanda è: come fa un controller ad accorgersi che un pod è stato eliminato o che c’è stato qualche cambiamento di stato? Viene utilizzata l’API Watch: quando un controller crea una connessione con l’API Server, questa connessione rimane aperta e l’API Server invia notifiche al controller ogni volta che c’è un cambiamento di stato. In questo modo, il controller è sempre aggiornato e può agire tempestivamente per mantenere lo stato desiderato del cluster.

4. Scheduler (kube-scheduler)

Lo Scheduler è responsabile dell’assegnazione dei pod ai nodi worker.

Il processo di scheduling:

Pod creato → Entra in coda di scheduling
           ↓
Scheduler verifica:
  - Risorse disponibili (CPU, memoria)
  - Tolleranze e affinity rules
  - Node selector
  - Vincoli di sicurezza (PodSecurityPolicy)
           ↓
Pod assegnato al miglior nodo disponibile
           ↓
Kubelet sul nodo riceve l'ordine e crea il container

Lo scheduler non esegue il pod - lo assegna semplicemente a un nodo. È il kubelet del nodo worker che realmente esegue il container.

Capacità di self-healing

Quando si parla di self-healing, si intende che il cluster rimanga in uno stato funzionante anche in caso di errori. Questo avviene con una combinazione di utilizzo di API usate in formato dichiarativo e con i loop controllo che monitorano lo stato del cluster.

Di base, il funzionamento è il seguente: tu dichiari lo stato desiderato delle risorse, i controller monitorano lo stato e se ne trovano delle differenze, le applicano.

Questo processo funziona molto bene, finché non ci ricordiamo che esiste un timeout che ha ogni controller per monitorare lo stato della situazione. Nel caso dei nodi, ad esempio, questo timeout è di 5 minuti, e questo esiste per evitare che se un nodo smetta di rispondere, il controller non assuma immediatamente che il nodo non risponda più, ma attendo un tempo minimo di recovery.

Questo porta una riflessione molto importante: Kubernetes mette a disposizione degli strumenti per gestire il recovery automatico, ma non l’alta disponibilità: mentre la prima significa che il sistema potrebbe ripristinare il cluster in caso di errore in maniera automatica e senza intervento umano, la seconda significa che il sistema è progettato per essere sempre disponibile, anche in caso di errori.

Per questo motivo, è importante comprendere le limitazioni di Kubernetes e progettare soluzioni che si integrino con altri strumenti per garantire l’alta disponibilità del cluster, e che tengano conto che avere una replica e un meccanismo di self-healing, producono un ambiente fragile, soprattutto in contesti di produzione.

Risorse utili

• Docker - per cominciare bene con Docker e Kubernetes
• Kubernetes - Guida per gestire e orchestrare i container
• LearnKube