Questo documento illustra i requisiti di rete per l'installazione e il funzionamento di Google Distributed Cloud.
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, 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, quest'ultimo deve consentire alcune connessioni specifiche. Per maggiori dettagli, consulta la sezione sui prerequisiti dell'articolo Installazione con un proxy.
Requisiti di rete interni
Google Distributed Cloud 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 saperne di più, consulta Scegliere e configurare i bilanciatori del carico.
Quando utilizzi il bilanciamento del carico di livello 2 in bundle con MetalLB (spec.loadBalancer.mode: bundled e spec.loadBalancer.type: layer2), i nodi del bilanciatore del carico richiedono l'aggressività di livello 2. Il requisito di adiacenza di livello 2 si applica se il bilanciatore del carico viene eseguito 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, pertanto non è richiesta un'adiacenza rigorosa 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 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 e instradabili al gateway della 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 blocco CIDR (Classless Inter-Domain Routing) a ciascun nodo, in modo che ogni pod possa avere un indirizzo IP univoco. Le dimensioni del blocco CIDR corrispondono al numero massimo di pod per nodo. Nella tabella seguente sono elencate le dimensioni del blocco CIDR assegnato da Kubernetes a ciascun 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 che Kubernetes prenoti 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 aumentare il cluster oltre questo limite, puoi aumentare il valore di clusterNetwork.pods.cidrBlocks o diminuire 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 e hanno tutti 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 inoltre i VIP per i seguenti 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 in che modo le porte UDP e TCP vengono utilizzate dai componenti di Kubernetes sui nodi del 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 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 | Entrambe | 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 | 8443 e 8444 | GKE Identity Service v2 | ais Deployment in esecuzione nello spazio dei nomi anthos-identity-service |
| TCP | In entrata | 9100 | auth-proxy | node-exporter |
| TCP | In entrata | 9101 | Pubblica 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 | Tutti |
| TCP | In entrata | 10257 | kube-controller-manager (Il numero di porta è cambiato per la versione 1.28 e successive). |
Indipendente |
| TCP | In entrata | 10259 | kube-scheduler Il numero di porta è cambiato 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 (Requisito per le porte aggiunte per la versione 1.16 e successive). |
kube-apiserver e etcd-events |
| TCP | Entrambe | 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 servizio/proxy per i componenti del piano di controllo (questo requisito delle porte si riferisce alla versione del cluster 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 | Entrambe | 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 servizio/proxy per i componenti del piano di controllo (questo requisito delle porte si riferisce alla versione del cluster 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.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 | Entrambe | 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 (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 | 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 | Entrambe | 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 | Entrambe | 4240 | Controllo di integrità CNI | Tutti |
| UDP | In entrata | 6081 | Incapsulamento di GENEVE | Indipendente |
| 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.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 nella configurazione del cluster, utilizzando il campo |
Tutti |
| TCP | Entrambe | 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 |
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 nella configurazione del cluster, utilizzando il campo |
Tutti |
| TCP | Entrambe | 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 nella configurazione del cluster, utilizzando il campo |
Tutti |
| TCP | Entrambe | 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 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 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 disabilitare il firewall per eseguire Google Distributed Cloud su Red Hat Enterprise Linux (RHEL). Per utilizzare firewall, devi aprire le porte UDP e TCP utilizzate dai nodi del piano di controllo, worker e del bilanciatore del carico, come descritto in 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 protetta da firewall. 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 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 per i tuoi 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 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 per i 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 del bilanciatore del carico
Il seguente blocco di comandi mostra un esempio di come aprire le porte necessarie 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
Sostituisci PODS_CIDR con i blocchi CIDR riservati per i tuoi pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.
Conferma la configurazione delle porte
Per verificare la configurazione della porta, segui questi passaggi sui nodi del piano di controllo, del worker e del bilanciatore del carico:
Esegui questo comando Network Mapper per vedere quali porte sono aperte:
nmap localhostEsegui questi comandi per ottenere le impostazioni di configurazione protette da 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-servicesSe necessario, esegui nuovamente i comandi delle sezioni precedenti per configurare correttamente i nodi. Potresti dover eseguire i comandi come utente root.
Problema noto per i firewall
Quando esegui Google Distributed Cloud con firewalld abilitato su Red Hat
Enterprise Linux (RHEL), le modifiche a firewalld possono rimuovere le catene Cilium iptables
sulla rete host. Le catene iptables vengono aggiunte dal pod anetd
all'avvio. La perdita delle catene Cilium iptables 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
firewalldin corso utilizzandosystemctlRicaricamento di
firewalldcon il client a riga di comando (firewall-cmd --reload)
Per applicare le modifiche a firewalld senza rimuovere le catene iptables, 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.