Requisiti di rete
Requisiti di rete esterni
Cluster Anthos on bare metal richiede una connessione a Internet per scopi operativi. Cluster Anthos on bare metal 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 utilizzate 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 Eseguire l'installazione dietro un proxy.
Requisiti di rete interna
I cluster Anthos su Bare Metal possono funzionare con la connettività di Livello 2 o Livello 3 tra i nodi del cluster, ma richiedono che i nodi del bilanciatore del carico dispongano di connettività di livello 2. 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 Scelta e configurazione dei bilanciatori del carico.
Il requisito di connettività di livello 2 si applica se esegui il bilanciatore del carico sul pool di nodi del piano di controllo o su un set di nodi dedicato.
I requisiti per le macchine del bilanciatore del carico sono i seguenti:
- Tutti i bilanciatori del carico per un determinato cluster si trovano nello stesso dominio di livello 2.
- Tutti gli indirizzi IP virtuali (VIP) devono trovarsi nella subnet della macchina del bilanciatore del carico e instradarli al gateway della subnet.
- Gli utenti sono responsabili di consentire il traffico del bilanciatore del carico in entrata.
Networking di pod
I cluster Anthos su Bare Metal 1.7.0 e versioni successive consentono 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 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 |
Per eseguire 250 pod per nodo, Kubernetes richiede di prenotare un blocco CIDR /23 per ogni nodo. Se il cluster utilizza il valore predefinito /16 per il campo clusterNetwork.pods.cidrBlocks, il cluster ha un limite di (2(23-16))=128 nodi. Se vuoi far crescere il cluster oltre questo limite, puoi aumentare il valore di clusterNetwork.pods.cidrBlocks o diminuire il valore di nodeConfig.podDensity.maxPodsPerNode.
Deployment del cluster utente singolo con disponibilità elevata
Il seguente diagramma illustra una serie di concetti chiave di networking per Cluster Anthos on bare metal in un'unica configurazione di rete possibile.
Tieni presente le seguenti informazioni per soddisfare i requisiti di rete:
- I nodi del piano di controllo eseguono i bilanciatori del carico e hanno tutti una 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 anche i VIP per i seguenti scopi:
- Servizi
- Ingress
- Accesso al piano di controllo tramite l'API Kubernetes
- È necessaria una connessione a Google Cloud.
Utilizzo porta
Questa sezione mostra come vengono utilizzate le porte UDP e TCP sui nodi dei cluster e del bilanciatore del carico.
Nodi del piano di controllo
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzatori |
|---|---|---|---|---|
| UDP | In entrata | 6081 | GENEVE Incapsulamento | Indipendente |
| TCP | In entrata | 22 | Provisioning e aggiornamenti dei nodi del cluster di amministrazione | Workstation di amministrazione |
| TCP | In entrata | 6444 | Server API Kubernetes | Tutte |
| TCP | In entrata | 2379 - 2380 | API client etcd server | kube-apiserver e etcd |
| TCP | In entrata | 10250 | kubelet API | Me stesso 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 | Entrambi | 4240 | Controllo di integrità CNI | Tutte |
Nodi worker
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzatori |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamenti dei nodi del cluster utente | Nodi del cluster di amministrazione |
| UDP | In entrata | 6081 | GENEVE Incapsulamento | Indipendente |
| TCP | In entrata | 10250 | kubelet API | Me stesso e piano di controllo |
| TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutte |
| TCP | In entrata | 30.000-32.767 | Servizi NodePort | Indipendente |
| TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutte |
Nodi bilanciatore del carico
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzatori |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamenti dei nodi del cluster utente | Nodi del cluster di amministrazione |
| UDP | In entrata | 6081 | GENEVE Incapsulamento | Indipendente |
| TCP | In entrata | 443* | Gestione dei cluster | Tutte |
| TCP | Entrambi | 4240 | Controllo di integrità CNI | Tutte |
| TCP | In entrata | 7946 | Controllo di integrità del bilanciatore del carico in metallo | nodi del bilanciatore del carico |
| UDP | In entrata | 7946 | Controllo di integrità del bilanciatore del carico in metallo | nodi del bilanciatore del carico |
| TCP | In entrata | 10256 | Controllo di integrità del nodo | Tutte |
* Questa porta può essere configurata nella configurazione del cluster tramite il campo controlPlaneLBPort.
Requisiti delle porte multi-cluster
In una configurazione multi-cluster, i cluster aggiunti devono includere le porte seguenti per comunicare con il cluster di amministrazione.
| Protocollo | Direzione | Intervallo porte | Finalità | Utilizzatori |
|---|---|---|---|---|
| TCP | In entrata | 22 | Provisioning e aggiornamenti dei nodi del cluster | Tutti i nodi |
| TCP | In entrata | 443* | Server API Kubernetes per il cluster aggiunto | Nodi del piano di controllo e del bilanciatore del carico |
* Questa porta può essere configurata nella configurazione del cluster tramite il campo controlPlaneLBPort.
Configura porte con firewall
Non è necessario disabilitare il firewall per eseguire i cluster Anthos su Bare Metal su Red Hat Enterprise Linux (RHEL) o CentOS. Per utilizzare il firewall, devi aprire le porte UDP e TCP utilizzate dai nodi del piano di controllo, del worker e del 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à a riga di comando con firewall.
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 pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.
Configurazione di esempio dei nodi worker
Il blocco di comandi seguente 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 per i pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.
Configurazione di esempio dei nodi 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 per i pod configurati nel campo clusterNetwork.pods.cidrBlocks. Il blocco CIDR predefinito per i pod è 192.168.0.0/16.