Questo documento descrive i requisiti di networking per l'installazione e il funzionamento di GKE su Bare Metal.
Requisiti di rete esterna
GKE su Bare Metal richiede una connessione a internet per scopi operativi. GKE su Bare Metal recupera i componenti del cluster da Container Registry e il cluster è registrato con Connect.
Puoi connetterti a Google utilizzando la rete internet pubblica 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 in Installazione tramite proxy.
Requisiti di rete interni
GKE su Bare Metal può funzionare con la connettività di livello 2 o livello 3 tra i nodi del cluster. I nodi del bilanciatore del carico possono essere i nodi del piano di controllo o un insieme dedicato di nodi. Per maggiori informazioni, consulta 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 l'adjacency di livello 2. Il requisito di adjacency di livello 2 si applica a prescindere dall'esecuzione del bilanciatore del carico sui nodi del piano di controllo o in un set 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'adjacency 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 si trovano nello stesso dominio di livello 2. Anche 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 ed essere instradabili al gateway della subnet.
- È responsabilità degli utenti consentire il traffico del bilanciatore del carico in entrata.
Networking di pod
GKE su Bare Metal consente di configurare fino a 250 pod per nodo. Kubernetes assegna un blocco CIDR (Classless Inter-Domain Routing) a ciascun nodo in modo che ogni pod possa avere un indirizzo IP univoco. La dimensione del blocco CIDR corrisponde al numero massimo di pod per nodo. La seguente tabella elenca le dimensioni del blocco CIDR che Kubernetes assegna a ciascun 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 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 intendi far crescere
il cluster oltre questo limite, puoi aumentare il valore di
clusterNetwork.pods.cidrBlocks o diminuire il valore di
nodeConfig.podDensity.maxPodsPerNode. Questo metodo presentava alcuni svantaggi.
Deployment di cluster utente singolo con disponibilità elevata
Il seguente diagramma illustra una serie di concetti chiave di networking per GKE su Bare Metal in un'unica configurazione di rete possibile.
Per soddisfare i requisiti di rete, considera le seguenti informazioni:
- I nodi del piano di controllo eseguono i bilanciatori del carico e hanno tutti la connettività di livello 2, mentre 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 inoltre i VIP per gli scopi seguenti:
- 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 GKE su Bare Metal. Le seguenti tabelle mostrano in che modo le porte UDP e TCP vengono utilizzate dai componenti Kubernetes sui nodi cluster e del bilanciatore del carico.
Nodi del piano di controllo
Versione 1.28
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzata da |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamento dei nodi dei cluster di amministrazione | Workstation di amministrazione |
| TCP | In entrata | 2379 - 2381 | API, metriche e integrità del client server etcd | kube-apiserver e etcd |
| TCP | In entrata | 2382 - 2384 | API, metriche e integrità del client server etcd-events | kube-apiserver e etcd-events |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento GENEVE | Indipendente |
| TCP | In entrata | 6444 | Server API Kubernetes | Tutte |
| TCP | In entrata | 8443 e 8444 | GKE Identity Service v2 | ais deployment in esecuzione nello spazio dei nomi anthos-identity-service |
| TCP | In entrata | 9100 | proxy-auth | node-exporter |
| TCP | In entrata | 9101 | Gestisci le metriche dei nodi solo su localhost (Requisito per la porta aggiunta per la 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 | Tutte |
| TCP | In entrata | 10257 | kube-controller-manager (Numero di porta modificato per la versione 1.28 e successive). |
Indipendente |
| TCP | In entrata | 10259 | kube-scheduler (Numero di porta modificato 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 dei cluster di amministrazione | Workstation di amministrazione |
| TCP | In entrata | 2379 - 2381 | API, metriche e integrità del client server etcd | kube-apiserver e etcd |
| TCP | In entrata | 2382 - 2384 | API, metriche e integrità del client server etcd-events (Requisito per le porte aggiunte per la versione 1.16 e successive). |
kube-apiserver e etcd-events |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento GENEVE | Indipendente |
| TCP | In entrata | 6444 | Server API Kubernetes | Tutte |
| 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 di porta è 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 | Tutte |
| 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 dei cluster di amministrazione | Workstation di amministrazione |
| TCP | In entrata | 2379 - 2381 | API, metriche e integrità del client server etcd | kube-apiserver e etcd |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento GENEVE | Indipendente |
| TCP | In entrata | 6444 | Server API Kubernetes | Tutte |
| 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 di porta è 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 | Tutte |
| TCP | In entrata | 14443 | Servizio webhook ANG | kube-apiserver e ang-controller-manager |
Nodi worker
Versione 1.28
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzata da |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamento dei nodi dei cluster utente | Nodi del cluster di amministrazione |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento GENEVE | Indipendente |
| TCP | In entrata | 9100 | proxy-auth | node-exporter |
| TCP | In entrata | 9101 | Gestisci le metriche dei nodi solo su localhost (Requisito per la porta aggiunta per la 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 | Tutte |
| 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 dei cluster utente | Nodi del cluster di amministrazione |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento 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 | Tutte |
| 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 dei cluster utente | Nodi del cluster di amministrazione |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| UDP | In entrata | 6081 | Incapsulamento GENEVE | Indipendente |
| TCP | In entrata | 10250 | kubelet API |
Auto e piano di controllo |
| TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutte |
| TCP | In entrata | 30.000 - 32.767 | Servizi NodePort |
Indipendente |
Nodi del bilanciatore del carico
Versione 1.28
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzata da |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamento dei nodi dei cluster utente | Nodi del cluster di amministrazione |
| TCP | In entrata | 443 | Gestione dei cluster Questa porta può essere configurata nella configurazione del cluster utilizzando il campo |
Tutte |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| 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 | Tutte |
Versione 1.16
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzata da |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamento dei nodi dei cluster utente | Nodi del cluster di amministrazione |
| TCP | In entrata | 443 | Gestione dei cluster Questa porta può essere configurata nella configurazione del cluster utilizzando il campo |
Tutte |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| 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 | Tutte |
Versione 1.15 e precedenti
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzata da |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamento dei nodi dei cluster utente | Nodi del cluster di amministrazione |
| TCP | In entrata | 443 | Gestione dei cluster Questa porta può essere configurata nella configurazione del cluster utilizzando il campo |
Tutte |
| TCP | Entrambe | 4240 | Controllo di integrità CNI | Tutte |
| 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 | Tutte |
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 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 |
Nodi del piano di controllo e del bilanciatore del carico |
Configura porte con firewall
Non è necessario disabilitare firewall per eseguire GKE su Bare Metal su Red
Hat Enterprise Linux (RHEL). Per utilizzare firewalld, devi aprire le porte UDP e TCP utilizzate dai nodi del piano di controllo, del worker e del bilanciatore del carico, come descritto nella sezione Utilizzo delle porte in questa pagina. Le configurazioni di esempio seguenti mostrano come aprire le porte con firewall-cmd, l'utilità a 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=10250-10252/tcp
firewall-cmd --permanent --zone=public --add-port=10256/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
Sostituisci PODS_CIDR con i blocchi CIDR riservati ai pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco 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 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
Sostituisci PODS_CIDR con i blocchi CIDR riservati ai pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.
Configurazione di esempio di 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
Sostituisci PODS_CIDR con i blocchi CIDR riservati ai pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.
Conferma la configurazione della porta
Per verificare la configurazione della porta, utilizza questi passaggi sui nodi del piano di controllo, dei worker e del bilanciatore del carico:
Esegui il comando Network Mapper riportato di seguito per verificare quali porte sono aperte:
nmap localhostEsegui questi comandi per recuperare le impostazioni di configurazione firewalld:
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-servicesSe necessario, esegui nuovamente i comandi delle sezioni precedenti per configurare correttamente i nodi. Potresti dover eseguire i comandi come utente root.
Problema noto relativo a firewall
Durante l'esecuzione di GKE su Bare Metal con firewalld abilitato su Red Hat Enterprise Linux (RHEL), le modifiche a firewalld possono rimuovere le catene iptables Cilium sulla rete host. Le catene iptables vengono aggiunte dal pod anetd all'avvio. La perdita delle catene Cilium iptables causa la perdita della connettività di rete al di fuori del nodo nel pod.
Le modifiche a firewalld che rimuovono le catene iptables includono, a titolo esemplificativo:
Riavvio di
firewalldutilizzandosystemctlRicaricamento di
firewalldcon il client a riga di comando (firewall-cmd --reload)
Per applicare modifiche firewalld senza rimuovere iptables catene, riavvia anetd
sul nodo:
Individua ed elimina il pod
anetdcon i seguenti comandi per riavviareanetd:kubectl get pods -n kube-system kubectl delete pods -n kube-system ANETD_XYZSostituisci ANETD_XYZ con il nome del pod
anetd.