Quali sono i componenti principali dell'architettura Kubernetes e di cosa è responsabile ciascuno?

Un cluster Kubernetes è costituito da un piano di controllo più un insieme di macchine lavoratore, chiamate nodi, che eseguono applicazioni containerizzate nei pod. Ogni cluster necessita di almeno un nodo di lavoro per eseguire i pod.

Concettualmente, Kubernetes è dichiarativo: invii lo stato desiderato al server API (memorizzato in etcd) e i controller eseguono cicli di riconciliazione continui che controllano le differenze e agiscono per guidare lo stato effettivo verso quello desiderato.

Componenti del piano di controllo

Il piano di controllo prende decisioni globali sul cluster (come la pianificazione) e risponde agli eventi del cluster. In produzione viene solitamente eseguito su più macchine per garantire un'elevata disponibilità.

• kube-apiserver: il componente principale che espone l'API HTTP Kubernetes. È il front-end del piano di controllo e l'unico punto di contatto: tutta l'autenticazione, l'autorizzazione, la convalida delle richieste e le letture/scritture dello stato del cluster passano attraverso di esso. Si ridimensiona orizzontalmente. Nelle normali distribuzioni è l'unico componente Kubernetes che legge e scrive lo stato del cluster direttamente in etcd; tutti gli altri componenti interagiscono con lo stato tramite il server API.
• etcd: un archivio chiave-valore coerente e altamente disponibile utilizzato come archivio di backup di Kubernetes per tutti i dati del cluster: configurazione, stato e metadati. etcd è obbligatorio ed è l'unica fonte di verità: perderlo significa perdere tutto lo stato del cluster, quindi deve essere eseguito con il quorum (un numero dispari di membri) ed essere sottoposto a backup regolarmente.
• kube-scheduler: controlla i pod non ancora associati a un nodo e assegna ciascun pod a un nodo adatto, considerando risorse, vincoli e policy.
• kube-controller-manager: esegue controller che implementano il comportamento dell'API Kubernetes (ad esempio, controller Node, controller Job, controller EndpointSlice). Ciascun controller osserva lo stato desiderato e riconcilia lo stato effettivo con esso.
• cloud-controller-manager (facoltativo): si integra con il provider cloud sottostante, isolando la logica specifica del cloud dai componenti principali di Kubernetes.

Componenti del nodo

Questi vengono eseguiti su ogni nodo, mantenendo i pod in esecuzione e fornendo l'ambiente di runtime.

• kubelet: l'agente che garantisce l'esecuzione dei pod, inclusi i relativi contenitori. Controlla il server API per le assegnazioni dei pod, avvia i contenitori tramite il runtime, monta i volumi, esegue sondaggi di attività/idoneità e segnala lo stato del nodo.
• kube-proxy: implementa la rete dei servizi programmando iptables o regole IPVS sui nodi in modo che il traffico verso un servizio venga inoltrato agli IP pod corretti. È contrassegnato come facoltativo perché alcuni plugin CNI (ad esempio Cilium in modalità eBPF) assumono il suo lavoro, ma in un cluster standard è obbligatorio.
• Container runtime: il software responsabile dell'esecuzione dei container (containerd, CRI-O, ecc., tramite l'interfaccia CRI).

Componenti aggiuntivi

I componenti aggiuntivi estendono la funzionalità del cluster: DNS del cluster (CoreDNS per impostazione predefinita), interfaccia utente Web Dashboard, monitoraggio delle risorse del contenitore e registrazione a livello di cluster.

Follow-up comune: tutta la comunicazione scorre attraverso il server API: lo scheduler, i controller e i kubelet semplicemente la osservano e reagiscono, il che rende il server API l'hub critico del cluster.