Requisiti di rete

Questo documento illustra i requisiti di rete per l'installazione e il funzionamento di Google Distributed Cloud (solo software) su bare metal.

Questa pagina è rivolta ad amministratori e architetti, operatori e specialisti di networking che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base e progettano e progettano la rete per la propria organizzazione. Per approfondire i ruoli comuni e le attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud, consulta Ruoli e attività comuni degli utenti di GKE Enterprise.

Requisiti della rete esterna

Google Distributed Cloud richiede una connessione a internet per scopi operativi. Google Distributed Cloud recupera i componenti del cluster da Container Registry e il cluster viene registrato con Connect Agent.

Puoi connetterti a Google utilizzando internet pubblico tramite HTTPS, una rete privata virtuale (VPN) o una connessione Dedicated Interconnect.

Se le macchine che utilizzi per la workstation di amministrazione e i nodi del cluster utilizzano un server proxy per accedere a internet, il server proxy deve consentire alcune connessioni specifiche. Per maggiori dettagli, consulta la sezione relativa ai prerequisiti di Installazione dietro un proxy.

Requisiti della rete interna

Google Distributed Cloud può funzionare con connettività Layer 2 o Layer 3 tra i nodi del cluster. I nodi del bilanciatore del carico possono essere i nodi del control plane o un insieme di nodi dedicato. Per ulteriori informazioni, consulta Scegliere e configurare i bilanciatori del carico.

Quando utilizzi il bilanciamento del carico di livello 2 in bundle con MetalLB (spec.loadBalancer.mode: bundled e spec.loadBalancer.type: layer2), i nodi del bilanciatore del carico richiedono l'adiacenza di livello 2. Il requisito di adiacenza di livello 2 si applica sia che tu esegua il bilanciatore del carico sui nodi del piano di controllo sia in un insieme dedicato di nodi di bilanciamento del carico. Il bilanciamento del carico in bundle con BGP supporta il protocollo di livello 3, pertanto non è richiesta l'adiacenza rigorosa di livello 2.

I requisiti per le macchine del bilanciatore del carico sono i seguenti:

• Per il bilanciamento del carico di livello 2 in bundle, tutti i bilanciatori del carico per un determinato cluster devono trovarsi nello stesso dominio di livello 2. Inoltre, i nodi del piano di controllo devono trovarsi nello stesso dominio di livello 2.
• Per il bilanciamento del carico di livello 2 in bundle, tutti gli indirizzi IP virtuali (VIP) devono trovarsi nella subnet della macchina del bilanciatore del carico e essere indirizzabili al gateway della subnet.
• Gli utenti sono responsabili di consentire il traffico del bilanciatore del carico in entrata.

Networking di pod e servizi

Gli intervalli di indirizzi IP disponibili per i servizi e i pod sono specificati nel file di configurazione del cluster. Le sezioni seguenti illustrano i vincoli minimi e massimi per gli intervalli di indirizzi e alcuni dei fattori correlati che devi prendere in considerazione quando pianifichi l'installazione del cluster.

Il numero di pod e servizi che puoi avere nei tuoi cluster è controllato dalle seguenti impostazioni:

• clusterNetwork.pods.cidrBlocks specifica il numero di pod consentiti nel cluster.

• clusterNetwork.services.cidrBlocks specifica il numero di servizi consentiti nel cluster.

• nodeConfig.podDensity.maxPodsPerNode specifica il numero massimo di pod che possono essere eseguiti su un singolo nodo.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: admin-basic
  namespace: cluster-admin-basic
spec:
  type: admin
  profile: default
  ...
  clusterNetwork:
    pods:
      cidrBlocks:
      - 192.168.0.0/16
    services:
      cidrBlocks:
      - 10.96.0.0/20
  ...
  nodeConfig:
    podDensity:
      maxPodsPerNode: 250

Intervalli di indirizzi IP per pod e servizi

Specifica un intervallo di indirizzi IP come blocco CIDR (Classless Inter-Domain Routing) da utilizzare per i pod e un altro blocco CIDR da utilizzare per gli indirizzi ClusterIP dei servizi Kubernetes. Utilizza indirizzi IP nello spazio di indirizzi privati, come descritto nel documento RFC 1918. Il file di configurazione del cluster è precompilato con valori che rientrano nei limiti descritti nella tabella seguente:

Limite	Pod	Servizi
Intervallo minimo	Valore della maschera pari a /18 (16.384 indirizzi)	Valore della maschera /24 (256 indirizzi)
Intervallo precompilato	Valore della maschera /16 (65.536 indirizzi)	Valore della maschera /20 (4096 indirizzi)
Raggio massimo	Valore della maschera /8 (16.777.216 indirizzi)	Valore della maschera /12 (1.048.576 indirizzi)

Per evitare sovrapposizioni con gli indirizzi IP raggiungibili sulla tua rete, potrebbe essere necessario utilizzare intervalli CIDR diversi dai valori precompilati. In particolare, gli intervalli di servizi e pod non devono sovrapporsi a quanto segue:

• Indirizzi IP dei nodi in qualsiasi cluster

• VIP utilizzati dai nodi del control plane e dai bilanciatori del carico

• Indirizzi IP di server DNS o NTP

I controlli preflight bloccano la creazione e gli upgrade dei cluster se vengono identificati indirizzi IP in sovrapposizione.

Nota: i blocchi CIDR di pod e servizi per il cluster sono suddivisi in intervalli di indirizzi IP più piccoli per ciascun nodo del cluster. Google Distributed Cloud utilizza la Network Address Translation (NAT) per mappare questi intervalli di indirizzi IP del pod all'indirizzo IP del nodo. Se uno di questi indirizzi IP del pod corrisponde a un indirizzo IP esterno, questo indirizzo esterno è considerato non raggiungibile dall'interno del cluster.

Puoi aumentare l'intervallo della rete di servizio (clusterNetwork.services.cidrBlocks) dopo aver creato un cluster, ma non puoi ridurre il numero di indirizzi IP assegnati o apportare modifiche. Puoi modificare solo il suffisso del blocco CIDR, riducendo il valore della maschera per aumentare il numero di indirizzi IP.

Sia clusterNetwork.pods.cidrBlocks che nodeConfig.podDensity.maxPodsPerNode (descritti nella sezione seguente) sono immutabili, quindi pianifica attentamente la crescita futura del tuo cluster per evitare di esaurire la capacità dei nodi. Per i valori massimi consigliati per pod per cluster, pod per nodo e nodi per cluster in base ai test, consulta Limiti.

Numero massimo di pod per nodo

Su bare metal, Google Distributed Cloud ti consente di configurare un massimo di 250 pod per nodo. Kubernetes assegna un blocco CIDR a ogni nodo in modo che ogni pod possa avere un indirizzo IP univoco. Le dimensioni del blocco CIDR del pod corrispondono al numero massimo di pod per nodo.

Nota: l'impostazione maxPodsPerNode tiene conto solo dei pod in esecuzione, ovvero dei pod che utilizzano risorse. Ad esempio, un job Kubernetes crea uno o più pod per completare un'attività specifica. In genere i pod vengono eseguiti fino al completamento dell'attività (o al verificarsi di un errore) e poi si arrestano. Questi pod arrestati in genere non vengono puliti automaticamente, quindi vengono visualizzati sul nodo quando esegui kubectl get pods. Tuttavia, poiché i pod arrestati non consumano risorse, inclusi gli indirizzi IP, non contribuiscono al numero totale di pod per nodo.

Nella tabella seguente sono elencate le dimensioni del blocco CIDR che Kubernetes assegna a ogni nodo in base al numero massimo di pod configurati per nodo:

Numero massimo di pod per nodo	Blocco CIDR per nodo	Numero di indirizzi IP
32	/26	64
33-64	/25	128
65-128	/24	256
129-250	/23	512

L'esecuzione di 250 pod per nodo richiede che Kubernetes riservi un blocco CIDR di /23 per ogni nodo. Supponendo che il cluster utilizzi il valore predefinito /16 per il clusterNetwork.pods.cidrBlocks campo, il cluster ha un limite di (2^(23-16))=128 nodi.

Se intendi far crescere il cluster oltre questo limite, ti consigliamo vivamente di impostare clusterNetwork.pods.cidrBlocks su un blocco CIDR pod molto più grande del valore precompilato.

Per ulteriori informazioni su come il numero di pod e servizi e altri fattori influiscono sulla scalabilità del cluster, consulta Eseguire l'upgrade dei cluster Google Distributed Cloud.

Deployment di un cluster con un solo utente ad alta disponibilità

Il seguente diagramma illustra una serie di concetti chiave di networking per Google Distributed Cloud in una possibile configurazione di rete.

Prendi in considerazione le seguenti informazioni per soddisfare i requisiti di rete:

• I nodi del piano di controllo eseguono i bilanciatori del carico e dispongono tutti di connettività di livello 2, mentre altre connessioni, inclusi i nodi worker, richiedono solo connettività di livello 3.
• I file di configurazione definiscono gli indirizzi IP per i pool di nodi worker. I file di configurazione definiscono anche i VIP per le seguenti finalità:
  • Servizi
  • In entrata
  • Accesso al piano di controllo tramite l'API Kubernetes
• È necessaria una connessione a Google Cloud.

Utilizzo porta

Questa sezione identifica i requisiti delle porte per i cluster Google Distributed Cloud. Le tabelle seguenti mostrano come le porte UDP e TCP vengono utilizzate dai componenti Kubernetes sui nodi del cluster e del bilanciatore del carico.

Nodi del control plane

Versione 1.29

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster di amministrazione	Workstation di amministrazione
TCP	In entrata	2379 - 2381	API client del server etcd, metriche e stato	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client del server etcd-events, metriche e stato di salute	kube-apiserver e etcd-events
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	6444	Server API Kubernetes	Tutti
TCP	In entrata	9100	auth-proxy	node-exporter
TCP	In entrata	9101	Pubblica le metriche dei nodi solo su localhost (si applica alla versione 1.28 e successive)	node-exporter
TCP	In entrata	9977	Ricevere l'evento di controllo dal server API	audit-proxy
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	10257	kube-controller-manager (modifica del numero di porta per la versione 1.28 e successive)	Indipendente
TCP	In entrata	10259	kube-scheduler (modifica del numero di porta per la versione 1.28 e successive)	Indipendente
TCP	In entrata	11002	Il contenitore principale di GKE Identity Service si lega alla porta tramite hostPort (si applica alla versione 1.29 e successive)	Indipendente
TCP	In entrata	14443	Servizio webhook ANG	kube-apiserver e ang-controller-manager

Versione 1.28

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster di amministrazione	Workstation di amministrazione
TCP	In entrata	2379 - 2381	API client del server etcd, metriche e stato	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client del server etcd-events, metriche e stato di salute	kube-apiserver e etcd-events
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	6444	Server API Kubernetes	Tutti
TCP	In entrata	8444	Il contenitore principale di GKE Identity Service si lega alla porta tramite hostPort (si applica solo alla versione 1.28)	Tutti
TCP	In entrata	9100	auth-proxy	node-exporter
TCP	In entrata	9101	Pubblica le metriche dei nodi solo su localhost (si applica alla versione 1.28 e successive)	node-exporter
TCP	In entrata	9977	Ricevere l'evento di controllo dal server API	audit-proxy
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	10257	kube-controller-manager (modifica del numero di porta per la versione 1.28 e successive)	Indipendente
TCP	In entrata	10259	kube-scheduler (modifica del numero di porta per la versione 1.28 e successive)	Indipendente
TCP	In entrata	14443	Servizio webhook ANG	kube-apiserver e ang-controller-manager

Versione 1.16

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster di amministrazione	Workstation di amministrazione
TCP	In entrata	2379 - 2381	API client del server etcd, metriche e stato	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client del server etcd-events, metriche e stato di salute (si applica alla versione 1.16 e successive)	kube-apiserver e etcd-events
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	6444	Server API Kubernetes	Tutti
TCP	In entrata	9100	Metriche relative alla pubblicazione	node-exporter
TCP	In entrata	9443	Metriche di servizio/proxy per i componenti del piano di controllo (questo requisito della porta è per la versione 1.16 e precedenti del cluster).	kube-control-plane-metrics-proxy
TCP	In entrata	9977	Ricevere l'evento di controllo dal server API	audit-proxy
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10251	kube-scheduler	Indipendente
TCP	In entrata	10252	kube-controller-manager	Indipendente
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	14443	Servizio webhook ANG	kube-apiserver e ang-controller-manager

Versione 1.15 e precedenti

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster di amministrazione	Workstation di amministrazione
TCP	In entrata	2379 - 2381	API client del server etcd, metriche e stato	kube-apiserver e etcd
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	6444	Server API Kubernetes	Tutti
TCP	In entrata	9100	Metriche relative alla pubblicazione	node-exporter
TCP	In entrata	9443	Metriche di servizio/proxy per i componenti del piano di controllo (questo requisito della porta è per la versione 1.16 e precedenti del cluster).	kube-control-plane-metrics-proxy
TCP	In entrata	9977	Ricevere l'evento di controllo dal server API	audit-proxy
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10251	kube-scheduler	Indipendente
TCP	In entrata	10252	kube-controller-manager	Indipendente
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	14443	Servizio webhook ANG	kube-apiserver e ang-controller-manager

Nodi worker

Versione 1.29

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	9100	auth-proxy	node-exporter
TCP	In entrata	9101	Pubblica le metriche dei nodi solo su localhost (si applica alla versione 1.28 e successive)	node-exporter
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	30000 - 32767	Servizi NodePort	Indipendente

Versione 1.28

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	9100	auth-proxy	node-exporter
TCP	In entrata	9101	Pubblica le metriche dei nodi solo su localhost (si applica alla versione 1.28 e successive)	node-exporter
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	30000 - 32767	Servizi NodePort	Indipendente

Versione 1.16

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	9100	Metriche relative alla pubblicazione	node-exporter
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	30000 - 32767	Servizi NodePort	Indipendente

Versione 1.15 e precedenti

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	9100	Metriche relative alla pubblicazione	node-exporter
TCP	In entrata	10250	kubelet API	Me e piano di controllo
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	30000 - 32767	Servizi NodePort	Indipendente

Nodi del bilanciatore del carico

Versione 1.29

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	In entrata	443	Gestione dei cluster Questa porta può essere configurata nel file di configurazione del cluster con il campo controlPlaneLBPort.	Tutti
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP e UDP	In entrata	7946	Controllo di integrità di MetalLB	Nodi del bilanciatore del carico
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti
TCP	In entrata	11000	Porta di ascolto per le metriche HAProxy (immutabile) (si applica alla versione 1.29 e successive)	Tutti
TCP	In entrata	11001	Porta di ascolto per GKE Identity Service (non modificabile) (si applica alla versione 1.29 e successive)	Tutti

Versione 1.28

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	In entrata	443	Gestione dei cluster Questa porta può essere configurata nel file di configurazione del cluster con il campo controlPlaneLBPort.	Tutti
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP e UDP	In entrata	7946	Controllo di integrità di MetalLB	Nodi del bilanciatore del carico
TCP	In entrata	8443	Porta di ascolto per GKE Identity Service (non modificabile) (si applica solo alla versione 1.28)	Tutti
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti

Versione 1.16

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	In entrata	443	Gestione dei cluster Questa porta può essere configurata nel file di configurazione del cluster con il campo controlPlaneLBPort.	Tutti
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	7946	Controllo di integrità di MetalLB	Nodi del bilanciatore del carico
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti

Versione 1.15 e precedenti

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster utente	Nodi del cluster di amministrazione
TCP	In entrata	443	Gestione dei cluster Questa porta può essere configurata nel file di configurazione del cluster con il campo controlPlaneLBPort.	Tutti
TCP	Entrambi	4240	Controllo di integrità CNI	Tutti
UDP	In entrata	6081	Incapsulamento GENEVE	Indipendente
TCP	In entrata	7946	Controllo di integrità di MetalLB	Nodi del bilanciatore del carico
TCP	In entrata	10256	Controllo di integrità del nodo	Tutti

Requisiti per le porte multi-cluster

In una configurazione multi-cluster, i cluster aggiunti devono includere le seguenti porte per comunicare con il cluster di amministrazione.

Protocollo	Direzione	Intervallo porte	Finalità	Utilizzata da
TCP	In entrata	22	Provisioning e aggiornamento dei nodi del cluster	Tutti i nodi
TCP	In entrata	443	Server API Kubernetes per il cluster aggiunto Questa porta può essere configurata nella configurazione del cluster utilizzando il campo controlPlaneLBPort.	Nodi del control plane e del bilanciatore del carico

Configura le porte firewalld

Non è necessario disattivare firewalld per eseguire Google Distributed Cloud su Red Hat Enterprise Linux (RHEL). Per utilizzare firewalld, devi aprire le porte UDP e TCP utilizzate dai nodi del piano di controllo, dei worker e del bilanciatore del carico come descritto in Utilizzo delle porte in questa pagina. Le seguenti configurazioni di esempio mostrano come aprire le porte con firewall-cmd, l'utilità da riga di comando firewalld. Devi eseguire i comandi come utente root.

Configurazione di esempio del nodo del piano di controllo

Il seguente blocco di comandi mostra un esempio di come aprire le porte necessarie sui server che eseguono i nodi del piano di controllo:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=10257/tcp
firewall-cmd --permanent --zone=public --add-port=10259/tcp
firewall-cmd --permanent --zone=public --add-port=2379-2380/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Per i requisiti specifici delle porte per la versione del cluster che intendi utilizzare, consulta la sezione Utilizzo delle porte precedente. Aggiorna i comandi di esempio di conseguenza.

Sostituisci PODS_CIDR con i blocchi CIDR riservati per i pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.

Configurazione di esempio del nodo worker

Il seguente blocco di comandi mostra un esempio di come aprire le porte necessarie sui server che eseguono i nodi worker:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Per i requisiti specifici delle porte per la versione del cluster che intendi utilizzare, consulta la sezione Utilizzo delle porte precedente. Aggiorna i comandi di esempio di conseguenza.

Sostituisci PODS_CIDR con i blocchi CIDR riservati per i pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.

Configurazione di esempio del nodo del bilanciatore del carico

Il seguente blocco di comandi mostra un esempio di come aprire le porte necessarie sui server che eseguono i nodi del bilanciatore del carico:

firewall-cmd --permanent --zone=public --add-port=22/tcp
firewall-cmd --permanent --zone=public --add-port=4240/tcp
firewall-cmd --permanent --zone=public --add-port=6444/tcp
firewall-cmd --permanent --zone=public --add-port=7946/tcp
firewall-cmd --permanent --zone=public --add-port=7946/udp
firewall-cmd --permanent --zone=public --add-port=6081/udp
firewall-cmd --permanent --zone=public --add-port=10250/tcp
firewall-cmd --permanent --zone=public --add-port=10256/tcp
firewall-cmd --permanent --zone=public --add-port=443/tcp
firewall-cmd --permanent --zone=public --add-port=30000-32767/tcp
firewall-cmd --permanent --new-zone=k8s-pods
firewall-cmd --permanent --zone=k8s-pods --add-source PODS_CIDR
firewall-cmd --permanent --zone=k8s-pods --set-target=ACCEPT
firewall-cmd --reload

Per i requisiti specifici delle porte per la versione del cluster che intendi utilizzare, consulta la sezione Utilizzo delle porte precedente. Aggiorna i comandi di esempio di conseguenza.

Sostituisci PODS_CIDR con i blocchi CIDR riservati per i pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.

Configurazione supplementare per RHEL 9.2 e 9.4

Le versioni 9.2 e 9.4 di Red Hat Enterprise Linux (RHEL) sono supportate come release a livello generale nelle versioni 1.29.400 e successive. Con le versioni RHEL 9.2 e 9.4, devi eseguire una configurazione aggiuntiva di firewalld sui nodi affinché i tuoi servizi e pod funzionino correttamente:

1. Elenca le interfacce attive del nodo per trovare l'interfaccia principale del nodo:

   firewall-cmd --list-interfaces
   

   In base alle convenzioni di denominazione per le interfacce della macchina Linux, il nome dell'interfaccia principale potrebbe essere uno dei seguenti: eth0, eno1, ens1 o enp2s0.

2. Elenca le zone per il nodo per trovare la zona utilizzata dall'interfaccia principale:

   firewall-cmd --list-all-zones
   

   Ad esempio, se l'interfaccia principale è eno1, la sezione seguente della risposta indica che l'interfaccia principale si trova nella zona public:

   ...
   public (active)
     target: default
     icmp-block-inversion: no
     interfaces: eno1
     sources:
     ...
   

3. Esegui i seguenti comandi firewalld per configurare i dettagli personalizzati delle zone e dei criteri per RHEL 9.2 o 9.4:

   firewall-cmd --permanent --new-zone=cilium
   firewall-cmd --permanent --zone=cilium --add-interface=cilium_host
   firewall-cmd --permanent --zone=cilium --set-target ACCEPT
   firewall-cmd --permanent --zone=cilium --add-masquerade
   firewall-cmd --permanent --zone=cilium --add-forward
   firewall-cmd --permanent --new-policy cilium-host-port-forwarding
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-ingress-zone IN_ZONE
   firewall-cmd --permanent --policy cilium-host-port-forwarding --add-egress-zone cilium
   firewall-cmd --permanent --policy cilium-host-port-forwarding --set-target ACCEPT
   firewall-cmd --reload
   

   Sostituisci IN_ZONE con uno dei seguenti valori, in base a quanto trovato nei passaggi precedenti:

   • public: zona predefinita da utilizzare nelle aree pubbliche in cui sono accettate solo connessioni in arrivo selezionate.
   • trusted: zona predefinita in un ambiente controllato in cui sono accettate tutte le connessioni di rete.
   • Il nome di una zona personalizzata che hai definito.

4. Segui la documentazione del fornitore per configurare la soluzione di archiviazione.

   Ad esempio, se utilizzi Portworx per gestire i carichi di lavoro con stato, i requisiti di rete di Portworx elencano le porte che devono rimanere aperte.

   Per ciascuna delle porte elencate nella documentazione del fornitore, esegui il seguente comando:

   firewall-cmd --permanent --zone=public --add-port=PORT_INFO
   

   Sostituisci PORT_INFO con il numero di porta o l'intervallo di numeri di porta seguito dal protocollo. Ad esempio, 10250-10252/tcp.

Nota: un bug in alcuni kernel Linux per Red Hat Enterprise Linux (RHEL) 9.2 potrebbe determinare download di immagini molto lenti. Per ulteriori informazioni, incluse le istruzioni per la risoluzione dei problemi, consulta Download lenti all'interno dei contenitori su RHEL 9.2.

Conferma la configurazione della porta

Per verificare la configurazione delle porte, segui i passaggi che seguono sui nodi del piano di controllo, di lavoro e del bilanciatore del carico:

1. Esegui il seguente comando Network Mapper per vedere quali porte sono aperte:

   nmap localhost
   

2. Esegui i seguenti comandi per ottenere le impostazioni di configurazione di firewalld:

   firewall-cmd --info-zone=public
   firewall-cmd --info-zone=k8s-pods
   firewall-cmd --list-all-policies
   

3. Se necessario, esegui di nuovo i comandi delle sezioni precedenti per configurare correttamente i nodi. Potresti dover eseguire i comandi come utente root.

Problema noto per firewalld

Quando esegui Google Distributed Cloud con firewalld abilitato su Red Hat Enterprise Linux (RHEL), le modifiche a firewalld possono rimuovere le catene iptables di Cilium sulla rete host. Le catene iptables vengono aggiunte dal pod anetd al suo avvio. La perdita delle catene iptables di Cilium fa sì che il pod sul nodo perda la connettività di rete all'esterno del nodo.

Le modifiche a firewalld che rimuovono le catene iptables includono, a titolo esemplificativo:

• Riavvio di firewalld utilizzando systemctl

• Ricaricamento di firewalld con il client a riga di comando (firewall-cmd --reload)

Per applicare le modifiche a firewalld senza rimuovere le catene iptables, riavvia anetd sul Nodo:

1. Individua ed elimina il pod anetd con i seguenti comandi per riavviare anetd:

   kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
   

   Sostituisci ANETD_XYZ con il nome del pod anetd.