Requisiti di rete

Questo documento descrive i requisiti di networking per l'installazione e il funzionamento di Google Distributed Cloud (solo software) su Bare Metal.

Questa pagina è rivolta ad amministratori, architetti, operatori e specialisti di networking che gestiscono il ciclo di vita dell'infrastruttura tecnologica di base e progettano e realizzano l'architettura di rete per la propria organizzazione. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

Requisiti di rete esterni

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

Nota: anche se Container Registry è stato chiuso, Artifact Registry utilizza ancora gli stessi URL gcr.io utilizzati da Container Registry. Per ulteriori informazioni, vedi repository gcr.io.

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 dei prerequisiti di Installazione dietro un proxy.

Requisiti di 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 dedicato di nodi. 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 l'adiacenza di livello 2. Il requisito di adiacenza di livello 2 si applica indipendentemente dal fatto che tu esegua il bilanciatore del carico sui nodi del control plane o in un insieme dedicato di nodi di bilanciamento del carico. Il bilanciamento del carico in bundle con BGP supporta il protocollo di livello 3, quindi non è richiesta un'adiacenza di livello 2 rigorosa.

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 si trovano nello stesso dominio di livello 2. Anche i nodi del control plane 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 ed essere instradabili al gateway della subnet.
• Gli utenti sono responsabili dell'autorizzazione del 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 descrivono i vincoli minimi e massimi per gli intervalli di indirizzi e alcuni dei fattori correlati che devi considerare quando pianifichi l'installazione del cluster.

Il numero di pod e servizi che puoi avere nei 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

Specifichi un intervallo di indirizzi IP come blocco Classless Inter-Domain Routing (CIDR) 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 in 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 maschera di /18 (16.384 indirizzi)	Valore maschera di /24 (256 indirizzi)
Intervallo precompilato	Valore della maschera di /16 (65.536 indirizzi)	Valore della maschera di /20 (4096 indirizzi)
Portata massima	Valore maschera di /8 (16.777.216 indirizzi)	Valore maschera di /12 (1.048.576 indirizzi)

Per evitare sovrapposizioni con gli indirizzi IP raggiungibili sulla tua rete, potresti dover 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 dei server DNS o NTP

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

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 conversione dell'indirizzo di rete (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,

Puoi aumentare l'intervallo della rete di servizi (clusterNetwork.services.cidrBlocks) dopo aver creato un cluster, ma non puoi ridurre il numero di indirizzi IP assegnati o modificarli. 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 cluster per evitare di esaurire la capacità dei nodi. Per i massimi consigliati per pod per cluster, pod per nodo e nodi per cluster in base ai test, vedi Limiti.

Numero massimo di pod per nodo

Su bare metal, Google Distributed Cloud 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 dei 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 di Kubernetes crea uno o più pod per svolgere un'attività specifica. I pod vengono in genere eseguiti fino al completamento (o all'errore) dell'attività e si arrestano. Questi pod arrestati di solito 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 totale massimo di pod per nodo.

La tabella seguente elenca le dimensioni del blocco CIDR assegnato da Kubernetes a ogni nodo in base al numero massimo di pod per nodo configurato:

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 a Kubernetes di riservare un blocco CIDR /23 per ogni nodo. Supponendo che il cluster utilizzi il valore predefinito di /16 per il campo clusterNetwork.pods.cidrBlocks, il cluster ha un limite di (2^(23-16))=128 nodi.

Se intendi espandere 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 Scalare i cluster Google Distributed Cloud.

Deployment di un singolo cluster 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.

Per soddisfare i requisiti di rete, tieni presente le seguenti informazioni:

• I nodi del control plane eseguono i bilanciatori del carico e dispongono tutti della connettività di livello 2, mentre le altre connessioni, inclusi i nodi worker, richiedono solo la connettività di livello 3.
• I file di configurazione definiscono gli indirizzi IP per i pool di nodi worker. I file di configurazione definiscono anche gli IP virtuali per i seguenti scopi:
  • Servizi
  • In entrata
  • Accesso al control plane 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 vengono utilizzate le porte UDP e TCP dai componenti Kubernetes sui nodi del cluster e del bilanciamento del carico.

Nodi del control plane

Versione 1.29 e successive

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, metriche e stato del server etcd	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client server etcd-events, metriche e stato	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	Self e control plane
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 container principale di GKE Identity Service si associa 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, metriche e stato del server etcd	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client server etcd-events, metriche e stato	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 container principale di GKE Identity Service si associa 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	Self e control plane
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, metriche e stato del server etcd	kube-apiserver e etcd
TCP	In entrata	2382 - 2384	API client server etcd-events, metriche e stato (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 control plane (questo requisito della porta riguarda 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	Self e control plane
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, metriche e stato del server etcd	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 control plane (questo requisito della porta riguarda 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	Self e control plane
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 e successive

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	Self e control plane
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	Self e control plane
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	Self e control plane
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	Self e control plane
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 e successive

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 (immutabile) (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 (immutabile) (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 delle 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

Configurare le porte di 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 control plane, worker e 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.

Esempio di configurazione del nodo control plane

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

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 di porta specifici 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 ai tuoi 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 di porta specifici 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 ai tuoi pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.

Esempio di configurazione 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 di porta specifici 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 ai tuoi 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

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

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

   firewall-cmd --list-interfaces
   

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

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

   firewall-cmd --list-all-zones
   

   Ad esempio, se l'interfaccia principale è eno1, la seguente sezione 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 di zona e policy 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 hai trovato nei passaggi precedenti:

   • public: zona predefinita da utilizzare nelle aree pubbliche in cui vengono accettate solo connessioni in entrata selezionate.
   • trusted: zona predefinita in un ambiente controllato in cui vengono 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 workload stateful, 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 comportare download di immagini molto lenti. Per ulteriori informazioni, incluse le istruzioni per la soluzione alternativa, consulta Download lenti all'interno dei container su RHEL 9.2.

Conferma la configurazione della porta

Per verificare la configurazione delle porte, segui questi passaggi sui nodi del control plane, worker e bilanciatore del carico:

1. Esegui questo comando di 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 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 quando viene avviato. La perdita delle catene Cilium iptables fa sì che il pod sul nodo perda la connettività di rete al di fuori del nodo.

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

• Riavvio di firewalld in corso, utilizzando systemctl

• Ricaricamento di firewalld con il client della 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.