Account non VRF o con funzionalità VRF, dotato esclusivamente di un endpoint del servizio cloud pubblico

L'immagine seguente mostra i componenti del cluster e il modo in cui interagiscono in un account senza VRF o con VRF abilitato, quando è attivo solo l'L'endpoint del servizio cloud pubblico è abilitato.

Account compatibile con VRF con endpoint di servizi cloud privati e pubblici

L'immagine seguente mostra i componenti del cluster e il modo in cui interagiscono in un account con VRF abilitato quando si utilizza l'Gli endpoint dei servizi cloud pubblici e privati sono abilitati.

Componenti master Kubernetes

Il master Kubernetes ha il compito di gestire tutte le risorse di calcolo, di rete e di archiviazione nel cluster e garantisce che le tue applicazioni inserite in un contenitore e i tuoi servizi siano distribuiti equamente ai nodi di lavoro nel cluster. A seconda del modo in cui configuri l'applicazione e i servizi, il master determina il nodo di lavoro che dispone di risorse sufficienti per soddisfare i requisiti dell'applicazione.

Il master Kubernetes e tutti i componenti del master sono dedicati a te soltanto e non vengono condivisi con altri clienti IBM.

La seguente tabella descrive i componenti del master Kubernetes.

kube-apiserver

Il server API Kubernetes funge da punto di ingresso principale per tutte le richieste di gestione del cluster dal nodo di lavoro al master Kubernetes. Il server API Kubernetes convalida e elabora le richieste che modificano lo stato delle risorse Kubernetes, come i pod o i servizi, e archivia questo stato in etcd.

konnectivity-server

Il server Konnectivity collabora con l’agente Konnectivity per connettere in modo sicuro il nodo master al nodo worker. Questa connessione supporta le chiamate apiserver proxy ai tuoi pod e servizi e le chiamate kubectl exec, attach e logs a kubelet.

etcd

etcd è un archivio di valori chiave altamente disponibile che archivia lo stato di tutte le risorse Kubernetes di un cluster, quali servizi, distribuzioni e pod. I dati in etcd sono sottoposti a backup su un'istanza di archiviazione crittografata gestita da IBM.

kube-scheduler

Il programma di pianificazione (scheduler) Kubernetes controlla se sono presenti dei pod di nuova creazione e decide dove distribuirli in base a capacità, esigenze di prestazioni, vincoli delle politiche, specifiche di anti-affinità e requisiti di carico di lavoro. Se non è possibile trovare alcun nodo di lavoro che corrisponda ai requisiti, il pod non viene distribuito nel cluster.

kube-controller-manager

Il gestore controller Kubernetes è un daemon che controlla lo stato delle risorse del cluster, quali le serie di repliche. Quando lo stato di una risorsa viene modificato, ad esempio se si verifica un'interruzione di un pod in una serie di repliche, il gestore controller avvia le azioni correttive per raggiungere lo stato richiesto.

Componenti di nodo di lavoro

Ogni nodo di lavoro è una macchina fisica (bare metal) o una macchina virtuale che viene eseguita su hardware fisico nell'ambiente cloud. Quando esegui il provisioning di un nodo di lavoro, determini le risorse che sono disponibili nei contenitori ospitati su tale nodo di lavoro. I nodi di lavoro sono configurati con un runtime per container gestito da IBM, risorse di calcolo separate, rete e un servizio di volume. Le funzioni di sicurezza integrate forniscono isolamento, funzionalità di gestione delle risorse e conformità di sicurezza dei nodi di lavoro.

I nodi di lavoro e tutti i componenti del nodo di lavoro sono dedicati a te soltanto e non vengono condivisi con altri clienti IBM. Tuttavia, se utilizzi una macchina virtuale del nodo di lavoro, l'hardware sottostante potrebbe venire condiviso con altri clienti a seconda del livello di isolamento hardware che scegli.

La modifica dei componenti di nodo di lavoro predefiniti come ad esempio kubelet non è supportata e potrebbe causare dei risultati imprevisti.

Le tabelle seguenti descrivono i componenti di un nodo di lavoro.

kube-system Namespace

ibm-master-proxy

L'ibm-master-proxy inoltra le richieste dal nodo di lavoro agli indirizzi IP delle repliche master altamente disponibili. Nei cluster a zona singola, il master ha tre repliche su host separati con un indirizzo IP e un nome di dominio del master. Per i cluster che si trovano in una zona che supporta il multizona, il master ha tre repliche che vengono distribuite tra le zone. In quanto tale, ogni master ha il proprio indirizzo IP registrato con DNS, con un nome di dominio per l'intero master cluster.

konnectivity-agent

L'agente Konnectivity collabora con il server Konnectivity per connettere in modo sicuro il nodo master al nodo worker. Questa connessione supporta le chiamate apiserver proxy ai tuoi pod e servizi e le chiamate kubectl exec, attach e logs a kubelet.

kubelet

Il kubelet è un pod che viene eseguito su ogni nodo di lavoro ed è responsabile del monitoraggio dell'integrità dei pod in esecuzione sul nodo di lavoro e del controllo degli eventi inviati dal server API Kubernetes. In base agli eventi, il kubelet crea o rimuove i pod, garantisce i probe di attività e disponibilità e segnala in risposta lo stato dei pod al server API Kubernetes.

coredns

Per impostazione predefinita, Kubernetes pianifica un pod CoreDNS (o un pod KubeDNS nella versione 1.12 e precedenti) e il servizio sul cluster. I contenitori utilizzano automaticamente l'IP del servizio DNS per risolvere i nomi DNS nelle loro ricerche di altri pod e servizi.

calico

Calico gestisce le politiche di rete per il tuo cluster e comprende alcuni componenti come i seguenti.

calico-cni: L'interfaccia di rete per container (CNI) di Calico gestisce la connettività di rete dei container e libera le risorse assegnate quando un container viene eliminato.

calico-ipam: L’IPAM ( Calico ) gestisce l’assegnazione degli indirizzi IP ai container.

calico-node: Il nodo " Calico " è un contenitore che raggruppa i vari componenti necessari per la gestione della rete dei container con " Calico ".

calico-policy-controller: Il controller delle politiche “ Calico ” monitora il traffico di rete in entrata e in uscita per verificarne la conformità alle politiche di rete definite. Se il traffico non è consentito nel cluster, l'accesso al cluster viene bloccato. Il controller delle politiche Calico viene inoltre utilizzato per creare e impostare le politiche di rete per un cluster.

kube-proxy

Il proxy di rete Kubernetes è un daemon che viene eseguito su ogni nodo di lavoro e che inoltra o che bilancia il carico del traffico di rete TCP e UDP per i servizi eseguiti nel cluster.

kube-dashboard

Il dashboard Kubernetes è una GUI basata sul web che consente agli utenti di gestire e risolvere i problemi relativi al cluster e alle applicazioni eseguiti nel cluster.

heapster

Heapster è un aggregatore a livello di cluster di dati di monitoraggio e di evento. Il pod Heapster rileva tutti i nodi nel cluster e interroga le informazioni sull'utilizzo dal kubelet di ciascun nodo. Puoi trovare i grafici di utilizzo nel dashboard Kubernetes.

ALB Ingress

Ingress è un servizio Kubernetes che puoi utilizzare per bilanciare i carichi di lavoro del traffico di rete nel tuo cluster inoltrando le richieste pubbliche o private a più applicazioni nel tuo cluster. Per esporre le tue applicazioni sulla rete pubblica o privata, devi creare una risorsa Ingress per registrare le applicazioni con l'ALB (application load balancer) Ingress. È quindi possibile accedere a più applicazioni utilizzando un singolo URL o indirizzo IP.

Provider di archiviazione

Ogni cluster è configurato con un plugin per eseguire il provisioning dell'archiviazione file. Puoi scegliere di installare altri componenti aggiuntivi, come ad esempio l'archiviazione blocchi.

ibm-system Namespace

Registrazione e metriche

Puoi utilizzare i servizi IBM Cloud Logs e IBM Cloud® Monitoring per espandere le tue funzionalità di raccolta e conservazione quando lavori con log e metriche. Programma di bilanciamento del carico

Un programma di bilanciamento del carico è un servizio Kubernetes che può essere utilizzato per bilanciare i carichi di lavoro del traffico di rete nel tuo cluster inoltrando richieste pubbliche o private a un'applicazione.

default Namespace

Servizi e pod dell'applicazione

Nel namespace default o nei namespace creati dall'utente, è possibile distribuire applicazioni in pod e servizi per comunicare con tali pod.