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 e 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, uno 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 con un proxy.
Requisiti di rete interni
Google Distributed Cloud può funzionare con il livello 2 o Livello 3 e la connettività tra i nodi del cluster. I nodi del bilanciatore del carico possono essere nodi del piano o un insieme dedicato di nodi. Per ulteriori informazioni, vedi Scelta e configurazione dei 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 a prescindere dall'esecuzione del caricamento
sui nodi del piano di controllo o in un set dedicato di nodi con 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 nello stesso dominio di livello 2. Anche i nodi del piano di controllo devono trovarsi nella stessa posizione Dominio di livello 2.
- Per il bilanciamento del carico di livello 2 in bundle, tutti gli indirizzi IP virtuali (VIP) devono essere nella subnet della macchina del bilanciatore del carico e instradabile al gateway una subnet.
- Gli utenti sono responsabili di consentire il traffico del bilanciatore del carico in entrata.
Networking di pod
Google Distributed Cloud consente di configurare fino a 250 pod per nodo. Kubernetes assegna un Classless Inter-Domain Routing (CIDR) blocca a ciascun nodo, in modo che ogni pod possa avere un indirizzo IP univoco. Le dimensioni del CIDR corrisponde al numero massimo di pod per nodo. La tabella seguente elenca le dimensioni del blocco CIDR assegnato da Kubernetes a ciascun nodo in base il 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 prenoti un blocco CIDR /23
per ciascun 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 hai intenzione di far crescere il
oltre questo limite, puoi aumentare il valore
clusterNetwork.pods.cidrBlocks
o riduci il valore di
nodeConfig.podDensity.maxPodsPerNode
. Questo metodo presenta alcuni svantaggi.
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.
Considera le seguenti informazioni per soddisfare i requisiti di rete:
- I nodi del piano di controllo eseguono i bilanciatori del carico, che hanno tutti il livello 2 e la connettività, mentre le altre connessioni, inclusi i nodi worker, richiedono 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 di GENEVE | Indipendente |
TCP | In entrata | 6444 | Server API Kubernetes | Tutti |
TCP | In entrata | 9100 | auth-proxy | node-exporter |
TCP | In entrata | 9101 | Pubblica metriche dei nodi solo su localhost
(si applica alla versione 1.28 e successive) |
node-exporter |
TCP | In entrata | 9977 | Ricevi evento di controllo dal server API | audit-proxy |
TCP | In entrata | 10250 | kubelet API |
Auto 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 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, 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 di GENEVE | Indipendente |
TCP | In entrata | 6444 | Server API Kubernetes | Tutti |
TCP | In entrata | 8444 | Il container principale di GKE Identity Service si associa alla portabilità
hostPort
(solo versione 1.28) |
Tutti |
TCP | In entrata | 9100 | auth-proxy | node-exporter |
TCP | In entrata | 9101 | Pubblica metriche dei nodi solo su localhost
(si applica alla versione 1.28 e successive) |
node-exporter |
TCP | In entrata | 9977 | Ricevi evento di controllo dal server API | audit-proxy |
TCP | In entrata | 10250 | kubelet API |
Auto 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, metriche e integrità del client server etcd-events
(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 di 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 pubblicazione/proxy per i componenti del piano di controllo (questa porta il requisito è per il cluster versione 1.16 e precedenti). | kube-control-plane-metrics-proxy |
TCP | In entrata | 9977 | Ricevi evento di controllo dal server API | audit-proxy |
TCP | In entrata | 10250 | kubelet API |
Auto 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 di 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 pubblicazione/proxy per i componenti del piano di controllo (questa porta il requisito è per il cluster versione 1.16 e precedenti). | kube-control-plane-metrics-proxy |
TCP | In entrata | 9977 | Ricevi evento di controllo dal server API | audit-proxy |
TCP | In entrata | 10250 | kubelet API |
Auto 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 di GENEVE | Indipendente |
TCP | In entrata | 9100 | auth-proxy | node-exporter |
TCP | In entrata | 9101 | Pubblica metriche dei nodi solo su localhost
(si applica alla versione 1.28 e successive) |
node-exporter |
TCP | In entrata | 10250 | kubelet API |
Auto e piano di controllo |
TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutti |
TCP | In entrata | 30.000 - 32.767 | 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 di GENEVE | Indipendente |
TCP | In entrata | 9100 | auth-proxy | node-exporter |
TCP | In entrata | 9101 | Pubblica metriche dei nodi solo su localhost
(si applica alla versione 1.28 e successive) |
node-exporter |
TCP | In entrata | 10250 | kubelet API |
Auto e piano di controllo |
TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutti |
TCP | In entrata | 30.000 - 32.767 | 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 di GENEVE | Indipendente |
TCP | In entrata | 9100 | Metriche di pubblicazione | node-exporter |
TCP | In entrata | 10250 | kubelet API |
Auto e piano di controllo |
TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutti |
TCP | In entrata | 30.000 - 32.767 | 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 di GENEVE | Indipendente |
TCP | In entrata | 9100 | Metriche di pubblicazione | node-exporter |
TCP | In entrata | 10250 | kubelet API |
Auto e piano di controllo |
TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutti |
TCP | In entrata | 30.000 - 32.767 | 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 cluster
di configurazione del deployment con il campo |
Tutti |
TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutti |
UDP | In entrata | 6081 | Incapsulamento di 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 (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 cluster
di configurazione del deployment con il campo |
Tutti |
TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutti |
UDP | In entrata | 6081 | Incapsulamento di 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 cluster
di configurazione del deployment con il campo |
Tutti |
TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutti |
UDP | In entrata | 6081 | Incapsulamento di 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 cluster
di configurazione del deployment con il campo |
Tutti |
TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutti |
UDP | In entrata | 6081 | Incapsulamento di 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 quanto segue 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 cluster aggiunto Questa porta può essere configurata
nella configurazione del cluster, utilizzando il campo |
Nodi del piano di controllo e del bilanciatore del carico |
Configura porte protette da firewall
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à. Dovresti 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 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 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 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 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 CIDR predefinito
per i pod è 192.168.0.0/16
.
Conferma la configurazione delle porte
Per verificare la configurazione della porta, segui questi passaggi sul piano di controllo: nodi worker e del bilanciatore del carico:
Esegui questo comando Network Mapper per vedere quali porte sono aperte:
nmap localhost
Esegui questi comandi per ottenere le impostazioni di configurazione del firewall:
firewall-cmd --zone=public --list-all-policies firewall-cmd --zone=public --list-ports firewall-cmd --zone=public --list-services firewall-cmd --zone=k8s-pods --list-all-policies firewall-cmd --zone=k8s-pods --list-ports firewall-cmd --zone=k8s-pods --list-services
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 i firewall
Durante l'esecuzione di Google Distributed Cloud con firewalld
abilitato su Red Hat
Enterprise Linux (RHEL), le modifiche a firewalld
possono rimuovere Cilium iptables
o catene sulla rete host. Le catene iptables
vengono aggiunte dal pod anetd
all'avvio. La perdita delle catene Cilium iptables
provoca l'attivazione del pod
perde la connettività di rete all'esterno del nodo.
Le modifiche a firewalld
che rimuovono le catene iptables
includono, ma non sono
limitato a:
Riavvio di
firewalld
in corso utilizzandosystemctl
Ricaricamento di
firewalld
con il client a riga di comando (firewall-cmd --reload
)
Per applicare le modifiche a firewalld
senza rimuovere iptables
catene, riavvia anetd
sul nodo:
Individua ed elimina il pod
anetd
con i seguenti comandi per riavviarlo.anetd
:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZ
Sostituisci ANETD_XYZ con il nome del pod
anetd
.