Cluster pubblici e privati
In Compute Cloud@Customer, prima di creare un cluster, decidere il tipo di accesso alla rete richiesto dal cluster: se è necessario un cluster pubblico o privato. Non è possibile creare cluster sia pubblici che privati in una VCN.
La differenza fondamentale tra un cluster pubblico e un cluster privato è se si configurano subnet pubbliche o private per l'endpoint API Kubernetes e il load balancer del worker.
Le subnet per i nodi di lavoro e i nodi del piano di controllo sono sempre private.
Per i nodi di lavoro e i nodi del piano di controllo, puoi configurare regole di instradamento che consentono l'accesso solo all'interno della VCN o all'esterno della VCN. Questa documentazione nomina le tabelle di instradamento "vcn_private" e "nat_private". È possibile scegliere una di queste configurazioni di subnet privata per i nodi di lavoro e i nodi del piano di controllo, indipendentemente dal fatto che il cluster sia privato o pubblico.
Cluster pubblici
Un cluster pubblico richiede le seguenti risorse di rete:
-
Subnet pubblica per l'endpoint API Kubernetes. Vedere le istruzioni per creare una subnet pubblica di "endpoint del piano di controllo" in Creazione di una subnet del piano di controllo OKE (overlay del canale) e Creazione di una subnet del piano di controllo (VCN-Native Pod).
-
Subnet pubblica per il load balancer del worker. Vedere le istruzioni per la creazione di una subnet pubblica "service-lb" in Creazione di una subnet del load balancer di worker (overlay del canale) e Creazione di una subnet del load balancer di worker (VCN-Native Pod).
-
Gateway Internet per connettere le risorse in una subnet pubblica a Internet utilizzando indirizzi IP pubblici.
-
Gateway NAT. Utilizzare un gateway NAT per l'accesso a Internet in uscita. Un gateway NAT connette le risorse in una subnet privata a Internet senza esporre gli indirizzi IP privati.
-
Almeno tre indirizzi IP pubblici gratuiti. Gli indirizzi IP pubblici gratuiti sono necessari per il gateway NAT, il load balancer del piano di controllo e il load balancer del worker.
Il load balancer del worker richiede un indirizzo IP pubblico gratuito per esporre le applicazioni. Il load balancer di lavoro potrebbe richiedere un numero maggiore di indirizzi IP pubblici gratuiti a seconda delle applicazioni in esecuzione sui pod.
Cluster privati
Se si creano più reti VCN OKE, ogni CIDR deve essere univoco. I CIDR di VCN diverse per i cluster privati non possono sovrapporsi ad altri CIDR VCN o a qualsiasi CIDR on premise. Gli indirizzi IP utilizzati devono essere esclusivi di ogni VCN.
Un cluster privato dispone delle risorse di rete riportate di seguito.
-
Subnet privata per l'endpoint API Kubernetes. Vedere le istruzioni per creare una subnet privata di "endpoint del piano di controllo" in Creazione di una subnet del piano di controllo OKE (overlay del canale) e Creazione di una subnet del piano di controllo (VCN-Native Pod).
-
Subnet privata per il load balancer del worker. Vedere le istruzioni per creare una subnet privata "service-lb" in Creazione di una subnet del load balancer del piano di controllo OKE (overlay del canale) e Creazione di una subnet del load balancer del piano di controllo (VCN-Native Pod).
-
Tabella di instradamento senza regole di instradamento. Questa tabella di instradamento consente l'accesso solo all'interno della VCN.
-
(Opzionale) Local Peering Gateway (LPG). Utilizzare un GPL per consentire l'accesso da altre reti VCN. Un GPL consente l'accesso al cluster da un'istanza in esecuzione su una VCN diversa. Crea un GPL nella VCN OKE e crea un GPL in una seconda VCN nella computazione Cloud@Customer. Utilizzare il comando di connessione GPL per eseguire il peer dei due GPL. Le VCN di peering possono trovarsi in tenancy diverse. I CIDR per le reti VCN sottoposte a peering non possono sovrapporsi. Vedere Connessione di VCN tramite Local Peering Gateway.
Creare una regola di instradamento per indirizzare il traffico della subnet VCN da e verso i GPL e le regole di sicurezza per consentire o negare determinati tipi di traffico. Vedere Creazione di una VCN (overlay canale) o Creazione di una VCN (pod nativo VCN) per la tabella di instradamento da aggiungere alla VCN OKE e a una tabella di instradamento simile da aggiungere alla seconda VCN. Aggiungere la stessa regola di instradamento nella seconda VCN, specificando il CIDR della VCN OKE come destinazione.
Installare l'SDK OCI e
kubectlnell'istanza nella seconda VCN e connettersi al cluster privato. Vedere Creazione di un file di configurazione Kubernetes. -
(Facoltativo) Gateway di routing dinamico (DRG). Utilizza un gateway DRG per abilitare l'accesso dalla rete in locale. Un gateway DRG consente il traffico tra la VCN OKE e lo spazio di indirizzi IP della rete in locale. Creare il DRG nel compartimento VCN OKE, quindi collegare la VCN OKE a tale DRG. Vedere Connessione alla rete in locale tramite un gateway di instradamento dinamico (DRG).
Creare una regola di instradamento per indirizzare il traffico verso lo spazio di indirizzi IP della rete del data center in locale. Vedere Creazione di una VCN (overlay canale) o Creazione di una VCN (pod nativo VCN) per la tabella di instradamento da aggiungere alla VCN OKE.