Configurazione delle risorse di rete per la creazione e la distribuzione dei cluster

Tabella di instradamento per subnet nodi di lavoro

Se si intende distribuire i nodi di lavoro in una subnet pubblica, la tabella di instradamento della subnet deve disporre di una regola di instradamento che specifichi il gateway Internet come destinazione per il blocco CIDR di destinazione 0.0.0.0/0.

Se si intende distribuire i nodi di lavoro in una subnet privata, la tabella di instradamento della subnet deve avere le seguenti caratteristiche:

• una regola di instradamento che specifica il gateway del servizio come destinazione per tutti i servizi <region> in Oracle Services Network;
• una regola di instradamento che specifica il gateway NAT come destinazione per il blocco CIDR di destinazione 0.0.0.0/0

Tabella di instradamento per subnet endpoint API Kubernetes

Se si intende distribuire l'endpoint API Kubernetes in una subnet pubblica, la tabella di instradamento della subnet deve disporre di una regola di instradamento che specifichi il gateway Internet come destinazione per il blocco CIDR di destinazione 0.0.0.0/0.

Se si intende distribuire l'endpoint API Kubernetes in una subnet privata, la tabella di instradamento della subnet deve avere le caratteristiche riportate di seguito.

• una regola di instradamento che specifica il gateway del servizio come destinazione per tutti i servizi <region> in Oracle Services Network;
• una regola di instradamento che specifica il gateway NAT come destinazione per il blocco CIDR di destinazione 0.0.0.0/0

Tabella di instradamento per le subnet del load balancer

Se si intende distribuire i load balancer nelle subnet pubbliche, la tabella di instradamento della subnet deve disporre di una regola di instradamento che specifichi il gateway Internet come destinazione per il blocco CIDR di destinazione 0.0.0.0/0.

Se si intende distribuire i load balancer nelle subnet private, la tabella di instradamento della subnet può essere vuota.

Tabella di instradamento per subnet pod

Se si intende utilizzare il plugin CNI di networking pod nativo VCN OCI per il networking pod, distribuire i pod in una subnet privata. La tabella di instradamento della subnet deve avere:

• una regola di instradamento che specifica il gateway del servizio come destinazione per tutti i servizi <region> in Oracle Services Network;
• una regola di instradamento che specifica il gateway NAT come destinazione per il blocco CIDR di destinazione 0.0.0.0/0

Se si intende utilizzare il plugin CNI flanella per il pod networking, non è necessaria una subnet pod.

Note sulla configurazione della tabella di instradamento

• Per evitare la possibilità di instradamento asimmetrico, una tabella di instradamento per una subnet pubblica non può contenere sia una regola di instradamento che si rivolge a un gateway Internet sia una regola di instradamento che si rivolge a un gateway di servizio (vedere Problemi con accesso alle istanze pubbliche dai servizi Oracle tramite un gateway di servizi).

• Per ulteriori informazioni sull'impostazione delle tabelle di instradamento, vedere:

  • Gateway Internet
  • Gateway NAT
  • Accesso ai servizi Oracle: gateway del servizio
  • Configurazioni delle risorse di rete di esempio

Configurazione della subnet dell'endpoint API Kubernetes

La subnet dell'endpoint API Kubernetes ospita un endpoint che fornisce l'accesso all'API Kubernetes sul piano di controllo del cluster.

La subnet dell'endpoint API Kubernetes deve essere una subnet regionale e può essere una subnet privata o pubblica:

• Se si specifica una subnet pubblica per l'endpoint API Kubernetes, è possibile esporre facoltativamente l'endpoint a Internet assegnando un indirizzo IP pubblico all'endpoint. L'indirizzo IP pubblico consente ai servizi cloud di terze parti (ad esempio i servizi CI/CD SaaS) di accedere all'endpoint API Kubernetes. Tenere presente quanto riportato di seguito.
  • Se l'endpoint API Kubernetes dispone di un indirizzo IP pubblico, devono esistere regole di instradamento e regole di sicurezza per abilitare l'accesso all'endpoint mediante un gateway Internet (vedere l'Esempio 1: cluster con CNI Flannel) Plugin, endpoint API Kubernetes pubblico, nodi di lavoro privati e load balancer pubblici ed Esempio 3: cluster con plugin CNI OCI, endpoint API Kubernetes pubblico, nodi di lavoro privati e load balancer pubblici).
  • Se l'endpoint API Kubernetes non dispone di un indirizzo IP pubblico, devono esistere regole di instradamento e regole di sicurezza per abilitare l'accesso all'endpoint utilizzando un gateway di servizio e un gateway NAT (vedere l'Esempio 2: Cluster) con il plugin CNI Flannel, l'endpoint API Kubernetes privato, i nodi di lavoro privati e i load balancer pubblici e l'esempio 4: cluster con il plugin CNI OCI, endpoint API Kubernetes privato, nodi di lavoro privati e load balancer pubblici).
  • Dopo aver creato un cluster, è possibile modificare in seguito l'assegnazione di un indirizzo IP pubblico all'endpoint API Kubernetes. Se si modifica l'assegnazione di un indirizzo IP pubblico all'endpoint, tenere presente che è necessario aggiornare le regole di instradamento e le regole di sicurezza in modo appropriato.
• Se si specifica una subnet privata per l'endpoint API Kubernetes, il traffico può accedere alla subnet dell'endpoint API Kubernetes da un'altra subnet nella VCN, da un'altra VCN o dalla rete in locale (in peer con FastConnect). Puoi anche impostare un host bastion su una subnet pubblica per raggiungere l'endpoint API Kubernetes (vedere Impostazione di un bastion per l'accesso al cluster).

Configurazione subnet nodo di lavoro

Una subnet del nodo di lavoro ospita i nodi di lavoro. Tutti i nodi gestiti in un pool di nodi appartengono alla stessa subnet dei nodi di lavoro.

La subnet del nodo di lavoro può essere una singola subnet regionale o più subnet specifiche di AD (una in ciascuno dei domini di disponibilità).

Nodi gestiti/gestiti autonomamente: la subnet del nodo di lavoro può essere una subnet pubblica o privata. Tuttavia, si consiglia che la subnet del nodo di lavoro sia una subnet privata per la massima sicurezza.

Nodi virtuali: la subnet del nodo di lavoro può essere una subnet pubblica o privata. Tuttavia, si consiglia che la subnet del nodo di lavoro sia una subnet privata per la massima sicurezza. Si consiglia inoltre che la subnet del nodo di lavoro e la subnet del pod siano la stessa subnet (nel qual caso, la subnet del nodo di lavoro deve essere una subnet privata perché i nodi virtuali richiedono che la subnet del pod sia una subnet privata).

Configurazione subnet pod

Una subnet pod ospita i pod sui nodi di lavoro in un pool di nodi quando si utilizza il networking pod nativo VCN (vedere Uso del plugin CNI di networking pod nativo VCN OCI per il networking pod).

La subnet pod deve essere una singola subnet regionale.

Nodi gestiti: la subnet pod deve essere una subnet privata.

Nodi virtuali: la subnet pod deve essere una subnet privata. Si consiglia che la subnet pod e la subnet nodo di lavoro siano la stessa subnet (nel qual caso, anche la subnet nodo di lavoro deve essere una subnet privata).

Configurazione subnet load balancer

Le subnet del load balancer connettono i load balancer di Oracle Cloud Infrastructure creati dai servizi Kubernetes di tipo LoadBalancer.

Le subnet del load balancer possono essere singole subnet regionali o subnet specifiche di AD (una in ciascuno dei domini di disponibilità). Tuttavia, si consiglia di utilizzare subnet regionali.

Le subnet del load balancer possono essere subnet pubbliche o private, a seconda della modalità di accesso alle applicazioni distribuite nel cluster. Se l'accesso alle applicazioni avverrà internamente dall'interno della VCN, utilizzare le subnet private per le subnet del load balancer. Se si accede alle applicazioni da Internet, utilizzare le subnet pubbliche per le subnet del load balancer.

Configurazione subnet bastion (facoltativa)

Un bastion facoltativo in una subnet bastion può fornire l'accesso sicuro all'endpoint API Kubernetes e l'accesso SSH ai nodi di lavoro. Vedere Impostazione di un bastion per l'accesso al cluster.

Regole di sicurezza per l'endpoint API Kubernetes

È necessario definire le regole di entrata seguenti per l'endpoint API Kubernetes, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È possibile definire le seguenti regole di entrata facoltative per l'endpoint API Kubernetes, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È necessario definire le regole di uscita seguenti per l'endpoint API Kubernetes, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

Regole di sicurezza per i nodi di lavoro

I nodi di lavoro vengono creati con indirizzi IP pubblici o privati, a seconda che si specifichino subnet pubbliche o private durante la definizione dei pool di nodi in un cluster. Il motore Kubernetes deve essere in grado di accedere ai nodi di lavoro.

Per i nodi di lavoro, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza è necessario definire le regole di entrata riportate di seguito.

È possibile definire le seguenti regole di entrata facoltative per i nodi di lavoro (solo nodi gestiti), in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È necessario definire le regole di uscita seguenti per i nodi di lavoro, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È possibile definire le seguenti regole di uscita facoltative per i nodi di lavoro, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

Regole di sicurezza per le subnet pod

Quando si utilizza il plugin CNI Networking pod VCN nativo OCI per il networking pod:

• le regole di sicurezza definite per la subnet del nodo di lavoro, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza, devono includere:

  • Regole di entrata e uscita con conservazione dello stato che consentono tutto il traffico tra i nodi di lavoro
  • Regole di entrata e uscita con conservazione dello stato che consentono tutto il traffico tra i nodi di lavoro e il load balancer
  • Regole di uscita con conservazione dello stato che consentono il traffico tra i nodi di lavoro e il motore Kubernetes
• le regole di sicurezza definite per la subnet pod, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza, devono includere regole di entrata e uscita con conservazione dello stato che consentano tutto il traffico tra i pod

È necessario definire le seguenti regole di entrata per le subnet pod, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È necessario definire le regole di uscita seguenti per le subnet pod, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

È possibile definire le seguenti regole di uscita facoltative per una subnet pod, in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza:

Regole di sicurezza per i load balancer e i load balancer di rete

Quando Kubernetes Engine esegue il provisioning di un load balancer o di un load balancer di rete OCI per un servizio Kubernetes di tipo LoadBalancer, devono esistere regole di sicurezza appropriate per consentire il traffico in entrata e in uscita verso e dalla subnet del load balancer o del load balancer di rete. Nel caso dei nodi gestiti (non dei nodi virtuali), queste regole di sicurezza vengono create automaticamente per impostazione predefinita per i load balancer, ma non vengono create automaticamente per impostazione predefinita per i load balancer di rete. Per ulteriori informazioni sul provisioning di un load balancer o di un load balancer di rete OCI per un servizio Kubernetes di tipo LoadBalancer, vedere Definizione dei servizi Kubernetes di tipo LoadBalancer.

Puoi definire regole di sicurezza in entrata e in uscita per la subnet in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza. Per ulteriori informazioni, fare riferimento agli argomenti sotto riportati.

• Specifica dei gruppi di sicurezza di rete (consigliata)
• Specifica delle opzioni di gestione delle liste di sicurezza durante il provisioning di un load balancer OCI
• Specifica delle opzioni di gestione delle liste di sicurezza durante il provisioning di un load balancer di rete OCI

Definire la regola di sicurezza in entrata seguente in uno o in entrambi i casi:

• un gruppo di sicurezza di rete (consigliato) a cui è stato aggiunto il load balancer o la risorsa del load balancer di rete
• una lista di sicurezza associata alla subnet del load balancer o del load balancer di rete

Impostare il protocollo e la porta di destinazione della regola di entrata in modo appropriato per requisiti specifici dell'applicazione. Ad esempio, specificare UDP come protocollo per un'applicazione che gestisce il traffico UDP.

Definire la regola di sicurezza di uscita seguente in uno o in entrambi i casi:

• un gruppo di sicurezza di rete (consigliato) a cui è stato aggiunto il load balancer o la risorsa del load balancer di rete
• una lista di sicurezza associata alla subnet del load balancer o del load balancer di rete

Per impostazione predefinita, i load balancer OCI o i load balancer di rete di cui è stato eseguito il provisioning dalle richieste proxy del motore Kubernetes a tutti i nodi di lavoro nel cluster. Quando le richieste vengono inviate ai nodi di lavoro nel cluster, devono esistere le regole di sicurezza di entrata e uscita seguenti (in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza) affinché il load balancer o il load balancer di rete comunichino con i nodi di lavoro sulla porta 10256 (la porta di integrità kube-proxy):

• Regola di sicurezza in entrata per la lista di sicurezza (o il gruppo di sicurezza di rete) della subnet del nodo di lavoro per consentire al load balancer o al load balancer di rete di comunicare con kube-proxy sui nodi di lavoro:

  Stato	Origine	Protocollo/destinazione. Porta	descrizione;
  Con conservazione dello stato	CIDR della subnet del load balancer o del load balancer di rete	TUTTI/10256	Consenti al load balancer o al load balancer di rete OCI di comunicare con kube-proxy sui nodi di lavoro.

• Regola di sicurezza in uscita per la lista di sicurezza (o il gruppo di sicurezza di rete) della subnet del load balancer o del load balancer di rete per consentire al load balancer o al load balancer di rete di comunicare con il proxy kube sui nodi di lavoro:

  Stato	Destinazione	Protocollo/destinazione. Porta	descrizione;
  Con conservazione dello stato	CIDR subnet nodo di lavoro	TUTTI/10256	Consenti al load balancer o al load balancer di rete OCI di comunicare con kube-proxy sui nodi di lavoro.

Quando si esegue il provisioning di un load balancer di rete per un servizio Kubernetes di tipo LoadBalancer:

• È possibile specificare che le richieste vengano terminate all'indirizzo IP del client specificato nelle intestazioni dei pacchetti IP, anziché essere proxyate ad altri nodi di lavoro nel cluster (impostando externalTrafficPolicy: Local). Vedere Terminazione delle richieste nel nodo di ricezione.
• Se si specifica che le richieste terminano all'indirizzo IP del client, è anche possibile specificare se conservare l'indirizzo IP del client nelle intestazioni dei pacchetti IP (utilizzando l'annotazione oci-network-load-balancer.oraclecloud.com/is-preserve-source). Vedere Preserving the Client IP Address.

In entrambi i casi, è necessario aver impostato una regola di sicurezza (in un gruppo di sicurezza di rete (consigliato) e/o in una lista di sicurezza) per i nodi di lavoro nel cluster per consentire il traffico in entrata dal blocco CIDR in cui vengono effettuate le connessioni client a tutte le porte dei nodi (da 30000 a 32767). Se l'applicazione è esposta a Internet, impostare il blocco CIDR Origine della regola di sicurezza su 0.0.0.0/0. In alternativa, impostare il blocco CIDR Origine della regola di sicurezza su un blocco CIDR specifico (ad esempio, se le connessioni client provengono da una subnet specifica).

Regole di sicurezza per le subnet bastion

Un bastion facoltativo in una subnet bastion può fornire l'accesso sicuro all'endpoint API Kubernetes e l'accesso SSH ai nodi di lavoro. Per informazioni sulle regole di sicurezza di entrata e uscita da definire, vedere Impostazione di un bastion per l'accesso al cluster.