Concetti

Edit This Page

I componenti di Kubernetes

Facendo il deployment di Kubernetes, ottieni un cluster.

Un cluster è un’insieme di macchine, chiamate nodi, che eseguono container e gestite da Kubernetes. Un cluster ha almeno un Worker Node e un Control Plane Node.

Il/I Worker Node ospitano i Pod che eseguono i workload dell’utente. Il/I Control Plane Node gestiscono i Worker Node e tutto quanto accade all’interno del cluster. Per garantire la high-availability e la possibilità di failover del cluster, vengono utilizzati più Control Plane Node.

Questo documento describe i diversi componenti che sono necessari per avere un cluster Kubernetes completo e funzionante.

Questo è un diagramma di un cluster Kubernetes con tutti i componenti e le loro relazioni.

I componenti di Kubernetes

Componenti della Control Plane

La Control Plane è responsabile di tutte le decisioni globali sul cluster (ad esempio, lo scheduling), e l’individuazione e la risposta ad eventi derivanti dal cluster (ad esempio, l’avvio di un nuovo podA Pod represents a set of running containers in your cluster. quando il valore replicas di un deployment non è soddisfatto).

I componenti della Control Plane possono essere eseguiti su qualsiasi nodo del cluster, ma solitamente gli script di installazione tendono a eseguire tutti i componenti della Control Plane sulla stessa macchina, separando la Control Plane dai workload dell’utente. Vedi creare un cluster in High-Availability per un esempio di un’installazione multi-master.

kube-apiserver

L’API server è un componente di Kubernetes control planeThe container orchestration layer that exposes the API and interfaces to define, deploy, and manage the lifecycle of containers. che espone le Kubernetes API. L’API server è il front end del control plane di Kubernetes.

La principale implementazione di un server Kubernetes API è kube-apiserver. kube-apiserver è progettato per scalare orizzontalmente, cioè scala aumentando il numero di istanze. Puoi eseguire multiple istanze di kube-apiserver e bilanciare il traffico tra queste istanze.

etcd

È un database key-value ridondato, che è usato da Kubernetes per salvare tutte le informazioni del cluster.

Se il tuo cluster utilizza etcd per salvare le informazioni, assicurati di avere una strategia di backup per questi dati.

Puoi trovare informazioni dettagliate su etcd sulla documentazione ufficiale.

kube-scheduler

Componente della Control Plane che controlla i pod appena creati che non hanno un nodo assegnato, e dopo averlo identificato glielo assegna.

I fattori presi in considerazioni nell’individuare un nodo a cui assegnare l’esecuzione di un Pod includono la richiesta di risorse del Pod stesso e degli altri workload presenti nel sistema, i vincoli delle hardware/software/policy, le indicazioni di affinity e di anti-affinity, requisiti relativi alla disponibilità di dati/Volumes, le interferenze tra diversi workload e le scadenze.

kube-controller-manager

Componente della Control Plane che gestisce controllersA control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. .

Da un punto di vista logico, ogni controllerA control loop that watches the shared state of the cluster through the apiserver and makes changes attempting to move the current state towards the desired state. è un processo separato, ma per ridurre la complessità, tutti i principali controller di Kubernetes vengono raggruppati in un unico container ed eseguiti in un singolo processo.

Alcuni esempi di controller gestiti dal kube-controller-manager sono:

  • Node Controller: Responsabile del monitoraggio dei nodi del cluster, e.g. della gestione delle azioni da eseguire quando un nodo diventa non disponibile.
  • Replication Controller: Responsabile per il mantenimento del corretto numero di Pod per ogni ReplicaSet presente nel sistema
  • Endpoints Controller: Popola gli oggetti Endpoints (cioè, mette in relazioni i Pods con i Services).
  • Service Account & Token Controllers: Creano gli account di default e i token di accesso alle API per i nuovi namespaces.

cloud-controller-manager

Il cloud-controller-manager esegue i controller che interagiscono con i cloud provider responsabili per la gestione dell’infrastruttura sottostante al cluster, in caso di deployment in cloud. Il cloud-controller-manager è una funzionalità alpha introdotta in Kubernetes 1.6.

Il cloud-controller-manager esegue esclusivamente i cicli di controllo specifici dei cloud provider. È possibile disabilitare questi cicli di controllo usando il kube-controller-manager. È inoltre possibile disabilitare i cicli di controllo settando il parametro --cloud-provider con il valore external durante l’esecuzione del kube-controller-manager.

Il cloud-controller-manager permette l’evoluzione indipendente al codice di Kubernetes e a quello dei singoli cloud vendor. Precedentemente, il codice core di Kubernetes dipendeva da implementazioni specifiche dei cloud provider. In futuro, implementazioni specifiche per singoli cloud provider devono essere mantenuti dai cloud provider interessati e collegati al cloud-controller-manager.

I seguenti controller hanno dipendenze verso implementazioni di specifici cloud provider:

  • Node Controller: Per controllare se sul cloud provider i nodi che hanno smesso di rispondere sono stati cancellati
  • Route Controller: Per configurare le regole di route nella sottostante infrastruttura cloud
  • Service Controller: Per creare, aggiornare ed eliminare i load balancer nella infrastruttura del cloud provider
  • Volume Controller: Per creare, associare e montare i volumi e per interagire con il cloud provider per orchestrare i volumi

Componenti dei Nodi

I componenti di Kubernetes che girano sui Worker Node sono responsabili dell’esecuzione dei workload degli utenti.

kubelet

Un agente che è eseguito su ogni nodo del cluster. Si assicura che i container siano eseguiti in un pod.

La kubelet riceve un set di PodSpecs che vengono forniti attraverso vari meccanismi, e si assicura che i container descritti in questi PodSpecs funzionino correttamente e siano sani. La kubelet non gestisce i container che non sono stati creati da Kubernetes.

kube-proxy

kube-proxy è un proxy eseguito su ogni nodo del cluster, responsabile della gestione dei Kubernetes ServiceA way to expose an application running on a set of Pods as a network service. .

I kube-proxy mantengono le regole di networking sui nodi. Queste regole permettono la comunicazione verso gli altri nodi del cluster o l’esterno.

Il kube-proxy usa le librerie del sistema operativo quando possible; in caso contrario il kube-proxy gestisce il traffico direttamente.

Container Runtime

Il container runtime è il software che è responsabile per l’esecuzione dei container.

Kubernetes supporta diversi container runtimes: Docker, containerd, cri-o, rktlet e tutte le implementazioni di Kubernetes CRI (Container Runtime Interface).

Addons

Gli Addons usano le risorse Kubernetes (DaemonSetEnsures a copy of a Pod is running across a set of nodes in a cluster. , DeploymentManages a replicated application on your cluster. , etc) per implementare nuove funzionalità a livello di cluster. Dal momento che gli addons forniscono funzionalità a livello di cluster, le risorse che necessitano di un namespace, vengono collocate nel namespace kube-system.

Alcuni addons sono descritti di seguito; mentre per una più estesa lista di addons, riferirsi ad Addons.

DNS

Mentre gli altri addons non sono strettamente richiesti, tutti i cluster Kubernetes dovrebbero essere muniti di un DNS del cluster, dal momento che molte applicazioni lo necessitano.

Il DNS del cluster è un server DNS aggiuntivo rispetto ad altri server DNS presenti nella rete, e si occupa specificatamente dei record DNS per i servizi Kubernetes.

I container eseguiti da Kubernetes possono utilizzare questo server per la risoluzione DNS.

Interfaccia web (Dashboard)

La Dashboard è una interfaccia web per i cluster Kubernetes. Permette agli utenti di gestire e fare troubleshooting delle applicazioni che girano nel cluster, e del cluster stesso.

Monitoraggio dei Container

Il Monitoraggio dei Container salva serie temporali di metriche generiche dei container in un database centrale e fornisce una interfaccia in cui navigare i dati stessi.

Log a livello di Cluster

Un log a livello di cluster è responsabile per il salvataggio dei log dei container in un log centralizzato la cui interfaccia permette di cercare e navigare nei log.

Voci correlate

Feedback