Progettazione dei componenti della topologia

Rivedere le opzioni architetturali per progettare la rete per la topologia Kubernetes, decidere se sono necessari host di base e di amministrazione e progettare i pool di nodi.

Progettare la rete

Decidere i requisiti di accesso semaforo delle applicazioni in container e determinare le risorse di rete necessarie.

Considerare i requisiti di scala del carico di lavoro quando si decide la dimensione di rete, ovvero gli intervalli CIDR per la VCN e le subnet.

Collega i nodi dei lavoratori a una subnet distinta all'interno della VCN. Utilizzare subnet separate per le altre risorse, ad esempio i nodi del load balancer, l'host di base e l'host di amministrazione.

L'approccio consigliato consiste nel collegare i nodi di lavoro di Kubernetes a una subnet privata. Ogni nodo del lavoratore dispone solo di un indirizzo IP privato. Utilizzare un load balancer (interno o pubblico) per distribuire il traffico ai nodi dei lavoratori. Per consentire ai nodi operativi di avviare l'accesso agli host in Internet pubblico, utilizzare un gateway NAT.

Se si intende creare servizi di tipo NodePort, allegare i nodi di lavoro di Kubernetes a una subnet pubblica. Il traffico verso e dai nodi viene instradato attraverso il gateway Internet. Ogni nodo lavoratore dispone di un indirizzo IP pubblico e di un indirizzo privato. È necessario configurare in modo esplicito le regole di sicurezza per consentire l'accesso ai nodi lavoratore dalla rete Internet pubblica.

È possibile utilizzare un gateway di servizi per instradare qualsiasi traffico dai nodi dei lavoratori ad altri servizi Oracle Cloud (ad esempio, Oracle Cloud Infrastructure Object Storage ) all'interno dell'area.

Limita accesso amministrativo

Utilizzare un host di base e un host di amministrazione per accedere e gestire la topologia nel cloud.

Per proteggere i nodi operativi Kubernetes dall'accesso non autorizzato dal cloud, isolarli in una subnet che non dispone di un instradamento verso e da Internet pubblico.

Distribuire un host di base e utilizzarlo come unico punto di accesso per le connessioni SSH alle altre istanze di calcolo nella topologia, incluso i nodi dei lavoratori. Per una maggiore sicurezza, si consiglia di consentire l'accesso SSH all'host di base solo a un set noto di indirizzi IP esterni al cloud.

Per le operazioni amministrative della topologia Kubernetes nel cloud, valutare la possibilità di creare un host di amministrazione nel cloud con gli strumenti richiesti, ad esempio kubectl e l'interfaccia CLI di Oracle Cloud Infrastructure installata nel cloud. Utilizzare l'host di base come server di collegamento per le connessioni SSH all'host di amministrazione.

Progettazione dei pool di nodi

Un pool di nodi è un gruppo di istanze di calcolo configurate in modo identico all'interno di un cluster Kubernetes. I pool di nodi consentono di distribuire e gestire le applicazioni con requisiti di risorse diversi in modo efficiente. Ad esempio, è possibile creare un pool di nodi distinto per ogni applicazione o servizio in container.

Decidere il numero di pool di nodi da creare e il numero di nodi dei lavoratori in ogni pool in base al numero e alla dimensione dei carichi di lavoro in container. In ogni pool vengono creati almeno tre nodi lavoratore. Tutti i nodi operativi all'interno di un determinato pool vengono creati con la stessa forma specificata.

Disponibilità alta

Assicurarsi che i carichi di lavoro container nel cloud non siano interessati dalle indisponibilità nel centro dati.

Le aree Oracle Cloud Infrastructure contengono uno o più domini di disponibilità con tolleranza degli errori. I domini di disponibilità non condividono infrastruttura quali alimentazione, raffreddamento e rete interna. Un errore in un dominio di disponibilità è improbabile che gli altri utenti all'interno della stessa area. In un'area che contiene più domini di disponibilità, i nodi dei lavoratori vengono distribuiti nei domini di disponibilità. È possibile collegare i nodi alle subnet regionali, che si estendono su tutti i domini di disponibilità.

Ogni dominio di disponibilità contiene tre domini di errore, ciascuno per un raggruppamento isolato di hardware e infrastruttura. Un evento di errore hardware o di gestione che interessa un dominio di errore non ha effetto sulle risorse presenti negli altri domini di errore. Nelle aree che dispongono di un singolo dominio di disponibilità, i nodi dei lavoratori vengono distribuiti nei domini di errore del centro dati.