Requisiti di rete

Requisiti di rete esterni

I cluster Anthos su Bare Metal richiedono una connessione a Internet per scopi operativi. I cluster Anthos su Bare Metal recuperano 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, quest'ultimo deve consentire alcune connessioni specifiche. Per maggiori dettagli, consulta la sezione relativa ai prerequisiti descritti in Installare un proxy.

Requisiti di rete interni

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 abbiano la connettività di livello 2. I nodi del bilanciatore del carico possono essere nodi del piano di controllo o set di nodi dedicato. Per ulteriori informazioni, consulta la pagina Scegliere e configurare i 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 in un set dedicato di nodi.

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 del traffico in entrata del bilanciatore del carico.

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. La tabella seguente elenca le dimensioni del blocco CIDR che Kubernetes assegna a ciascun nodo in base ai pod massimi 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 ogni nodo. Se il tuo cluster utilizza il valore predefinito di /16 per il campo clusterNetwork.pods.cidrBlocks, il cluster ha un limite di (2 (23-16) = 128 nodi. Se vuoi espandere il cluster oltre questo limite, puoi aumentare il valore di clusterNetwork.pods.cidrBlocks o diminuire il valore di nodeConfig.podDensity.maxPodsPerNode.

Deployment di un cluster utente singolo con disponibilità elevata

Il seguente diagramma illustra una serie di concetti di networking chiave per i cluster Anthos su Bare Metal in una possibile configurazione di rete.

Cluster Anthos su configurazione di rete tipica di Bare Metal

Esamina 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 attraverso l'API Kubernetes
  • È necessaria una connessione a Google Cloud.

Utilizzo porta

Questa sezione mostra come vengono utilizzate le porte UDP e TCP sui nodi del cluster e del bilanciatore del carico.

Nodi del piano di controllo

ProtocolloDirezioneIntervallo porteFinalitàUtilizzatori
UDPIn entrata6081Incapsulamento GENEVEIndipendente
TCPIn entrata22Provisioning e aggiornamenti dei nodi dei cluster di amministrazioneWorkstation di amministrazione
TCPIn entrata6444Server API di KubernetesTutti
TCPIn entrata2379 - 2380API etcd server clientkube-apiserver e etcd
TCPIn entrata10250kubelet APIPiano di controllo personale
TCPIn entrata10251kube-schedulerIndipendente
TCPIn entrata10252kube-controller-managerIndipendente
TCPIn entrata10256Controllo di integrità dei nodiTutti
TCPEntrambi4240Controllo di integrità CNITutti

Nodi worker

ProtocolloDirezioneIntervallo porteFinalitàUtilizzatori
TCPIn entrata22Provisioning e aggiornamenti dei nodi dei cluster utenteNodi del cluster di amministrazione
UDPIn entrata6081Incapsulamento GENEVEIndipendente
TCPIn entrata10250kubelet APIPiano di controllo personale
TCPIn entrata10256Controllo di integrità dei nodiTutti
TCPIn entrata30.000-32.767NodePort serviziIndipendente
TCPEntrambi4240Controllo di integrità CNITutti

Nodi bilanciatore del carico

ProtocolloDirezioneIntervallo porteFinalitàUtilizzatori
TCPIn entrata22Provisioning e aggiornamenti dei nodi dei cluster utenteNodi del cluster di amministrazione
UDPIn entrata6081Incapsulamento GENEVEIndipendente
TCPIn entrata443*Gestione dei clusterTutti
TCPEntrambi4240Controllo di integrità CNITutti
TCPIn entrata7946Controllo di integrità LB in metallonodi del bilanciatore del carico
UDPIn entrata7946Controllo di integrità LB in metallonodi del bilanciatore del carico
TCPIn entrata10256Controllo di integrità dei nodiTutti

* Questa porta può essere configurata nella configurazione del cluster utilizzando il campo controlPlaneLBPort.

Requisiti della porta multi-cluster

In una configurazione multi-cluster, i cluster aggiunti devono includere le seguenti porte per comunicare con il cluster di amministrazione.

ProtocolloDirezioneIntervallo porteFinalitàUtilizzatori
TCPIn entrata22Provisioning e aggiornamenti dei nodi del clusterTutti i nodi
TCPIn entrata443*Server API Kubernetes per il cluster aggiuntoNodi del piano di controllo e bilanciatore del carico

* Questa porta può essere configurata nella configurazione del cluster utilizzando il campo controlPlaneLBPort.

Configura porte con firewall

Non è necessario disabilitare il firewall per eseguire cluster Anthos su Bare Metal su Red Hat Enterprise Linux (RHEL) o CentOS. Per utilizzare i 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 piano di controllo

Il seguente blocco di comandi mostra un esempio di come aprire le porte necessarie 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=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 del 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.