Requisiti di rete

Questo documento illustra i requisiti di rete per l'installazione e il funzionamento. Google Distributed Cloud.

Questa pagina è rivolta agli amministratori e agli architetti, agli operatori e Specialisti di networking che gestiscono il ciclo di vita della tecnologia sottostante dell'infrastruttura, progettare e progettare la rete per la propria organizzazione. A scopri di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento per i contenuti di Google Cloud, consulta Ruoli e attività utente comuni di GKE Enterprise.

Requisiti di 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.

Puoi connetterti a Google utilizzando la rete internet pubblica tramite HTTPS, un rete privata (VPN) o 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 sui prerequisiti di Installazione dietro un proxy.

Requisiti della rete interna

Google Distributed Cloud può funzionare con la 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 la sezione 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 il livello 2 adiacenza. 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. Supporta il bilanciamento del carico in bundle con BGP Protocollo di livello 3, quindi non è richiesta una rigorosa adiacenza di livello 2.

I requisiti per le macchine dei bilanciatori 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 nella 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 tuo cluster.

• clusterNetwork.services.cidrBlocks specifica il numero di servizi consentiti nel tuo 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 gli indirizzi IP nello spazio di indirizzi privati, come descritto nel documento RFC 1918. Il cluster file di configurazione sia precompilato con valori che rientrano nei limiti descritti nella seguente tabella:

Limite	Pod	Servizi
Intervallo minimo	Valore della maschera pari a /18 (16.384 indirizzi)	Valore della maschera /24 (256 indirizzi)
Intervallo precompilato	Valore maschera /16 (65.536 indirizzi)	Valore maschera /20 (4096 indirizzi)
Portata massima	Valore maschera /8 (16.777.216 indirizzi)	Valore 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 del cluster se gli indirizzi IP si sovrappongono vengono identificati.

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 dei 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 la rete di servizi gamma (clusterNetwork.services.cidrBlocks) dopo aver creato un cluster, ma non puoi ridurre il numero di destinazione o modificare. Puoi modificare solo il suffisso del blocco CIDR, riducendo il per aumentare il numero di indirizzi IP.

Sia clusterNetwork.pods.cidrBlocks che nodeConfig.podDensity.maxPodsPerNode (descritti nella sezione seguente) sono immutabili, quindi pianifica con attenzione della 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

Google Distributed Cloud (solo software) on bare metal consente di configurare un fino a un massimo di 250 pod per nodo. Kubernetes assegna un blocco CIDR a ciascun 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 prende in considerazione solo i pod in esecuzione, i pod che utilizzano Google Cloud. Ad esempio, un cluster Kubernetes Crea job a uno o più pod per svolgere un'attività specifica. In genere i pod vengono eseguiti fino al completamento dell'attività (o al verificarsi di un errore) e poi si arrestano. In genere, questi pod arrestati non vengono cleanup 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 assegnato da Kubernetes 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 di /16 per clusterNetwork.pods.cidrBlocks, 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 influisce sulla scalabilità del cluster, Fai lo scale up dei cluster Google Distributed Cloud.

Deployment di cluster utente con disponibilità elevata

Il seguente diagramma illustra una serie di concetti chiave del 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 VIP per scopi:
  • 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 da 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, metriche e integrità del client etcd del server	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API, metriche e integrità del client server etcd-events	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, metriche e integrità del client etcd del server	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API, metriche e integrità del client server etcd-events	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 (solo 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, metriche e integrità del client etcd del server	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 di 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, metriche e integrità del client etcd del server	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 di 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 di 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 di 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à 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à MetalLB	Nodi del bilanciatore del carico
TCP	In entrata	8443	Porta di ascolto per GKE Identity Service (immutabile) (solo 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à 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à 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 piano di controllo e del bilanciatore del carico

Configura le porte firewalld

Non è necessario disattivare il firewall per eseguire Google Distributed Cloud on Red RHEL (Hat Enterprise Linux). Per utilizzare il firewall, devi aprire UDP e TCP utilizzate dai nodi del piano di controllo, dei worker e del bilanciatore del carico, come descritto Utilizzo delle porte in questa pagina. Le configurazioni di esempio che seguono mostra come aprire le porte con firewall-cmd, la riga di comando protetta da firewall utilità. 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 il file porte sui server che eseguono 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 il tuo configurati nel campo clusterNetwork.pods.cidrBlocks. Il CIDR predefinito per i pod è 192.168.0.0/16.

Configurazione di esempio di nodo worker

Il seguente blocco di comandi mostra un esempio di come aprire il file porte sui server che eseguono 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 precedente Utilizzo delle porte. Aggiorna i comandi di esempio di conseguenza.

Sostituisci PODS_CIDR con i blocchi CIDR riservati per il tuo 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 il file porte sui server che eseguono 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 il tuo 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

Red Hat Enterprise Linux (RHEL) versione 9.2 e 9.4 sono supportate come GA in 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 per il nodo in modo da trovare l'interfaccia del nodo principale:

   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 in modo da trovare quella utilizzata dall'interfaccia principale:

   firewall-cmd --list-all-zones
   

   Ad esempio, se la tua interfaccia principale è eno1, la seguente sezione della la 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 protetti da firewall per configurare una zona e un criterio personalizzati dettagli 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 su quanto hai 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 tutta la rete connessioni accettate.
   • 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 quanto segue :

   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 comportano download delle immagini molto lenti. Per ulteriori informazioni, incluse le soluzioni alternative istruzioni, vedi Download lenti all'interno dei container su RHEL 9.2.

Conferma la configurazione della porta

Per verificare la configurazione della porta, segui questi passaggi sul piano di controllo: nodi worker 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 nuovamente i comandi delle sezioni precedenti per configurare i nodi correttamente. 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.