Rete di nodi

Questo argomento descrive come personalizzare la rete dei nodi per i cluster del carico di lavoro, inclusa la personalizzazione degli indirizzi IP dei nodi e la configurazione delle prenotazioni DHCP, IPAM dei nodi e IPv6 in vSphere.

Configurazione delle prenotazioni DHCP dei nodi e del record DNS dell'endpoint (solo vSphere)

Per i nuovi cluster in vSphere è necessario creare prenotazioni DHCP per i relativi nodi. Potrebbe inoltre essere necessario creare un record DNS per l'endpoint del piano di controllo:

Prenotazioni DHCP per i nodi del cluster:

Come precauzione di sicurezza negli ambienti in cui più nodi del piano di controllo potrebbero spegnersi o rimanere offline per lunghi periodi di tempo, modificare le prenotazioni DHCP per gli indirizzi IP dei nodi del piano di controllo di un cluster appena creato e dei nodi worker in modo che gli indirizzi rimangano statici e i lease non scadano mai.

Per istruzioni su come configurare le prenotazioni DHCP, consultare la documentazione del server DHCP.
Record DNS per l'endpoint del piano di controllo:

Se si utilizza NSX Advanced Load Balancer anziché Kube-Vip per l'endpoint del piano di controllo e si imposta VSPHERE_CONTROL_PLANE_ENDPOINT su un nome di dominio completo anziché su un indirizzo IP numerico, prenotare gli indirizzi come segue:
1. Recuperare l'indirizzo IP del piano di controllo che NSX ALB ha assegnato al cluster:
```
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
```
2. Registrare l'indirizzo IP indicato come "host" nell'output, ad esempio 192.168.104.107.
3. Creare un record DNS A che associ il nome di dominio completo all'indirizzo IP registrato.
4. Per testare il nome di dominio completo, creare un nuovo kubeconfig che utilizzi il nome di dominio completo anziché l'indirizzo IP da NSX ALB:
  1. Generare il kubeconfig:
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
```
  2. Modificare il file kubeconfig KUBECONFIG-TEST per sostituire l'indirizzo IP con il nome di dominio completo. Ad esempio, sostituire questo:
```
server: https://192.168.104.107:443
```
    con questo:
```
server: https://CONTROLPLANE-FQDN:443
```
  3. Recuperare i pod del cluster utilizzando il kubeconfig modificato:
```
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
```
    Se l'output elenca i pod, significa che DNS funziona per il nome di dominio completo.

Personalizzazione degli indirizzi IP dei nodi del cluster (MC autonomo)

È possibile configurare blocchi di indirizzi IP specifici del cluster per i nodi dei cluster di gestione autonomi e dei cluster del carico di lavoro che distribuiscono. La modalità di esecuzione di questa operazione dipende dall'infrastruttura cloud in cui viene eseguito il cluster:

vSphere

In vSphere, il file di configurazione del cluster VSPHERE_NETWORK imposta la rete della macchina virtuale utilizzata da Tanzu Kubernetes Grid per i nodi del cluster e gli altri oggetti Kubernetes. Gli indirizzi IP vengono allocati ai nodi da un server DHCP eseguito in questa rete della macchina virtuale, distribuito separatamente da Tanzu Kubernetes Grid.

Se si utilizza la rete di NSX, è possibile configurare i binding DHCP per i nodi del cluster seguendo le indicazioni di Configurazione dei binding statici DHCP in un segmento nella documentazione di VMware NSX-T Data Center.

Nota
A partire dalla versione 4.0, VMware NSX-T Data Center è stato rinominato con "VMware NSX".

AWS

Per configurare blocchi di indirizzi IP specifici del cluster in Amazon Web Services (AWS), impostare le variabili seguenti nel file di configurazione del cluster come descritto nella tabella AWS in Informazioni di riferimento sulle variabili del file di configurazione.

Specificare AWS_PUBLIC_NODE_CIDR per impostare un intervallo di indirizzi IP per i nodi pubblici.
- Rendere disponibili intervalli aggiuntivi impostando AWS_PRIVATE_NODE_CIDR_1 o AWS_PRIVATE_NODE_CIDR_2
Specificare AWS_PRIVATE_NODE_CIDR per impostare un intervallo di indirizzi IP per i nodi privati.
- Rendere disponibili intervalli aggiuntivi impostando AWS_PRIVATE_NODE_CIDR_1 e AWS_PRIVATE_NODE_CIDR_2
Tutti gli intervalli CIDR dei nodi devono trovarsi nell'intervallo VPC del cluster, che per impostazione predefinita è 10.0.0.0/16.

Microsoft Azure

Per configurare blocchi di indirizzi IP specifici del cluster in Azure, impostare le variabili seguenti nel file di configurazione del cluster come indicato nella tabella Microsoft Azure in Informazioni di riferimento sulle variabili del file di configurazione.

Impostare AZURE_NODE_SUBNET_CIDR per creare una nuova VNet con un blocco CIDR per gli indirizzi IP dei nodi worker.
Impostare AZURE_CONTROL_PLANE_SUBNET_CIDR per creare una nuova VNet con un blocco CIDR per gli indirizzi IP dei nodi del piano di controllo.
Impostare AZURE_NODE_SUBNET_NAME per assegnare gli indirizzi IP dei nodi worker dall'intervallo di una VNet esistente.
Impostare AZURE_CONTROL_PLANE_SUBNET_NAME per assegnare gli indirizzi IP dei nodi del piano di controllo dall'intervallo di una VNet esistente.

IPAM del nodo (vSphere)

Con l'IPAM del nodo, un provider IPAM in-cluster alloca e gestisce gli indirizzi IP per i nodi cluster durante la creazione e la scalabilità dei cluster, eliminando qualsiasi necessità di configurare un DHCP esterno.

È possibile configurare l'IPAM del nodo per i cluster di gestione autonomi in vSphere e i cluster del carico di lavoro basati sulla classe che gestiscono. La procedura seguente configura l'IPAM del nodo per i cluster del carico di lavoro basati sulla classe; per configurare l'IPAM del nodo per un cluster di gestione, vedere Configurazione dell'IPAM del nodo in Configurazione del cluster di gestione per vSphere.

Nota
Questa procedura non si applica a TKG con un supervisore vSphere with Tanzu o con un cluster di gestione autonomo in AWS o Azure.

Quando si configura l'IPAM dei nodi per un cluster del carico di lavoro nuovo o esistente, l'utente specifica un pool interno di IP da cui il provider IPAM alloca indirizzi IP statici, nonché un indirizzo gateway.

Quando si allocano indirizzi ai nodi del cluster, l'IPAM del nodo seleziona sempre l'indirizzo più basso disponibile nel pool.

Prerequisiti

Un cluster di gestione autonomo TKG
Server dei nomi per il piano di controllo e i nodi worker del cluster del carico di lavoro
- Obbligatorio perché i nodi del cluster non ricevono più i server dei nomi tramite DHCP per risolvere i nomi in vCenter.
kubectl e CLI di Tanzu installati in locale

Limitazioni

L'IPAM del nodo ha le seguenti limitazioni in TKG v2.3:

Solo per i nuovi cluster del carico di lavoro basati sulla classe distribuiti da un cluster di gestione in vSphere.
- Non è possibile convertire cluster basati su DHCP esistenti nell'IPAM del nodo.
Nessun supporto per nodi Windows.
Solo per l'ambiente IPv4 o IPv6, non dual stack.
Alloca solo gli indirizzi dei nodi, non l'endpoint del piano di controllo del cluster.
L'IPAM del nodo non verifica se il suo pool di IP è in conflitto con i pool DHCP già utilizzati da altri cluster.

Configurazione dell'IPAM dei nodi per un cluster del carico di lavoro

Il pool di IPAM del nodo di un cluster del carico di lavoro può essere definito da due tipi di oggetti diversi, in base alla modalità di condivisione dei relativi indirizzi con altri cluster:

InClusterIPPool configura i pool di IP disponibili solo per i cluster del carico di lavoro nello stesso spazio dei nomi del cluster di gestione, ad esempio default.
- Questo è l'unico tipo disponibile in TKG v2.1 e v2.2.
GlobalInClusterIPPool configura i pool di IP con indirizzi che possono essere allocati ai cluster del carico di lavoro in più spazi dei nomi.

Per configurare un cluster nuovo o esistente con l'IPAM dei nodi:

Creare un file di definizione di oggetto del pool di IP my-ip-pool.yaml che definisce un intervallo di indirizzi IP da una subnet che TKG può utilizzare per allocare indirizzi IP statici per il cluster del carico di lavoro. Definire l'oggetto come InClusterIPPool o GlobalInClusterIPPool in base all'ambito desiderato del pool di IP, ad esempio:
- InClusterIPPool: per creare un pool di IP inclusterippool per i cluster del carico di lavoro nello spazio dei nomi default che contiene l'intervallo 10.10.10.2-10.10.10.100 più 10.10.10.102 e 10.10.10.104:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool
  namespace: default
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
  Nota
  Nelle versioni di TKG precedenti è stata utilizzata la versione valpha1 dell'oggetto InClusterIPPool, che supportava solo un intervallo di pool di IP contigui specificato da start e end, come descritto nella documentazione di TKG v2.1. L'aggiornamento dei cluster alla versione 2.3 converte i pool di IP in una nuova struttura.
- GlobalInClusterIPPool: per creare un pool di IP inclusterippool da condividere tra gli spazi dei nomi che contengono gli stessi indirizzi del InClusterIPPool precedente:
```
apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: GlobalInClusterIPPool
metadata:
  name: inclusterippool
spec:
  gateway: 10.10.10.1
  addresses:
  - 10.10.10.2-10.10.10.100
  - 10.10.10.102
  - 10.10.10.104
  prefix: 24
```
Creare l'oggetto pool di IP:
```
kubectl apply -f my-ip-pool.yaml
```

Configurare il cluster del carico di lavoro in modo che utilizzi il pool di IP all'interno di un file di configurazione del cluster flat oppure di una specifica di oggetto di tipo Kubernetes, come descritto in File di configurazione.

Ad esempio:

File di configurazione semplice (per creare nuovi cluster):

# The name of the InClusterIPPool object specified above
NODE_IPAM_IP_POOL_NAME: inclusterippool
CONTROL_PLANE_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11
WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11

Specifica oggetto (per creare nuovi cluster o modificare quelli esistenti):

---
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
spec:
topology:
  variables:
  - name: network
    value:
      addressesFromPools:
      - apiGroup: ipam.cluster.x-k8s.io
        kind: InClusterIPPool
        name: inclusterippool
  - name: controlplane
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]

Ora è possibile distribuire il cluster del carico di lavoro.

Regole relative ai pool

Gli intervalli dei pool di IP non devono sovrapporsi
- La sovrapposizione dei pool può causare errori, e TKG non convalida gli intervalli dei pool o rileva sovrapposizioni.
Non rimuovere un indirizzo IP attualmente allocato da un pool di IP.

Risoluzione dei problemi relativi all'IPAM dei nodi

Per verificare se ai nodi del cluster sono assegnati indirizzi IP, eseguire kubectl get per elencare gli oggetti macchina specifici di IaaS, vspherevms, e verificarne lo stato IPAddressClaimed. True indica che la richiesta dell'indirizzo del nodo è riuscita; se lo stato è False, l'output del comando segnala un motivo (Reason) per cui non è presente la condizione di pronto:
```
kubectl -n CLUSTER-NAMESPACE get vspherevms
```
Per visualizzare le attestazioni degli indirizzi IP, elencare ipaddressclaims. Per ciascuna macchina, la voce addressesFromPools causa la creazione di una IPAddressClaim:
```
kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
```
Per visualizzare gli indirizzi IP, elencare ipaddress. Il provider IPAM in-cluster dovrebbe rilevare ciascun IPAddressClaim e creare un oggetto IPAddress corrispondente:
```
kubectl -n CLUSTER-NAMESPACE get ipaddress
```
Quando tutte le attestazioni per una determinata macchina virtuale sono associate agli indirizzi IP, CAPV scrive gli indirizzi IP assegnati nei metadati cloud-init della macchina virtuale e crea la macchina virtuale. Per visualizzare i passaggi di riconciliazione degli indirizzi IP, vedere i registri CAPV e Cluster API IPAM Provider (CAIP):
```
kubectl logs -n capv-system capv-controller-manager
kubectl logs -n caip-in-cluster-system capi-in-cluster-controller-manager
```

Rete IPv6 (vSphere)

È possibile eseguire i cluster di gestione e del carico di lavoro in un ambiente di rete single-stack solo IPv6 in vSphere con Kube-Vip utilizzando nodi basati su Ubuntu.

Note Non è possibile creare cluster IPv6 con un cluster supervisore vSphere with Tanzu. Non è possibile registrare cluster IPv6 in Tanzu Mission Control. I servizi NSX Advanced Load Balancer e la rete dual stack IPv4/IPv6 non sono attualmente supportati.

Prerequisiti:

Configurare vSphere per gli indirizzi IPv6 raggiungibili dal cluster di bootstrap.
Configurare il resolver DNS nel daemon Docker con un indirizzo IPv6 raggiungibile dal cluster di bootstrap.
Se i cluster IPv6 devono raggiungere una rete IPv4, come succede di solito, configurare un proxy HTTP come descritto in Configurazione del proxy.

Distribuzione di un cluster di gestione IPv6

Eseguire le operazioni seguenti nella macchina di bootstrap per distribuire un cluster di gestione in un ambiente di rete IPv6:

Configurare Linux in modo che accetti gli annunci del router per garantire che la route IPv6 predefinita non venga rimossa dalla tabella di routing all'avvio del servizio Docker. Per ulteriori informazioni, vedere Docker CE elimina la route predefinita IPv6. sudo sysctl net.ipv6.conf.eth0.accept_ra=2
Creare una regola di mascheramento per il cluster di bootstrap per inviare il traffico in uscita dal cluster di bootstrap: sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE Per ulteriori informazioni sulle regole di mascheramento, vedere MASCHERAMENTO.
Impostare le seguenti variabili del file di configurazione per il cluster di gestione.
- Impostare TKG_IP_FAMILY su ipv6.
- Impostare VSPHERE_CONTROL_PLANE_ENDPOINT su un indirizzo IPv6 statico.
- (Facoltativo) Impostare CLUSTER_CIDR and SERVICE_CIDR. Le impostazioni predefinite di queste variabili sono rispettivamente fd00:100:64::/48 e fd00:100:96::/108.
Distribuire il cluster di gestione eseguendo tanzu mc create come indicato in Distribuzione di cluster di gestione da un file di configurazione.
- Per il supporto di IPv6, è necessario distribuire il cluster di gestione da un file di configurazione, non dall'interfaccia del programma di installazione.

Distribuzione di un cluster del carico di lavoro IPv6

Se è stato distribuito un cluster di gestione IPv6, distribuire un cluster del carico di lavoro IPv6 nel modo seguente:

Impostare le seguenti variabili del file di configurazione per il cluster del carico di lavoro.
- Impostare TKG_IP_FAMILY su ipv6.
- Impostare VSPHERE_CONTROL_PLANE_ENDPOINT su un indirizzo IPv6 statico.
- (Facoltativo) Impostare CLUSTER_CIDR and SERVICE_CIDR. Le impostazioni predefinite di queste variabili sono rispettivamente fd00:100:64::/48 e fd00:100:96::/108.
Distribuire il cluster del carico di lavoro come descritto in Creazione di cluster del carico di lavoro.

Cluster dual stack (Anteprima tecnica)

Nota
Lo stato di questa funzionalità è Anteprima tecnica e non è quindi supportata. Vedere Stati delle funzionalità di TKG.

La funzionalità dual stack consente di distribuire cluster con famiglie di IP IPv4 e IPv6. Tuttavia, la famiglia di IP primari è IPv4. Prima di sperimentare questa funzionalità, configurare vCenter Server per supportare la connettività IPv4 e IPv6.

Di seguito sono elencate le limitazioni della funzionalità dual stack in questa versione:

La funzionalità dual stack supporta vSphere come unico prodotto IaaS (Infrastruttura distribuita come servizio).
Non è possibile configurare dual stack nei cluster con nodi Photon OS. Sono supportati solo i cluster configurati con OS_NAME ubuntu.
Non è possibile configurare la rete dual stack per i cluster supervisore vSphere with Tanzu o per i cluster del carico di lavoro che questi creano.
Non è possibile distribuire un cluster di gestione dual stack con l'interfaccia del programma di installazione.
Non è possibile utilizzare i servizi dual stack o IPv6 nei servizi di bilanciamento del carico forniti da NSX Advanced Load Balancer (ALB). È possibile utilizzare kube-vip come provider dell'endpoint del piano di controllo per un cluster dual stack. L'utilizzo di NSX ALB come provider dell'endpoint del piano di controllo per un cluster dual stack non è stato convalidato.
Solo i componenti aggiuntivi principali, come Antrea, Calico, CSI, CPI e Pinniped, sono stati convalidati per il supporto dual stack in questa versione.

Per configurare dual stack nei cluster:

Impostare il flag di funzionalità dual stack:

a. Per abilitare la funzionalità nel cluster di gestione, eseguire il comando seguente:
```
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
```
b. Per abilitare la funzionalità nel cluster del carico di lavoro, eseguire il comando seguente:
```
tanzu config set features.cluster.dual-stack-ipv4-primary true
```
Distribuzione dei cluster di gestione o Creazione dei cluster del carico di lavoro in base alle esigenze.

Nel file di configurazione del cluster:
- Impostare la variabile di configurazione della famiglia IP TKG_IP_FAMILY: ipv4,ipv6.
- Facoltativamente, impostare i CIDR di servizio e i CIDR del cluster.
Nota
Sono disponibili due CIDR per ogni variabile. Le famiglie di IP di questi CIDR seguono l'ordine della TKG_IP_FAMILY configurata. L'intervallo CIDR più grande consentito per gli indirizzi IPv4 è /12 e l'intervallo di SERVICE_CIDR IPv6 più grande è /108. Se non si impostano i CIDR, vengono utilizzati i valori predefiniti.
- Impostare il seguente parametro del file di configurazione, se si utilizza Antrea come CNI per il cluster:
```
ANTREA_ENDPOINTSLICES: true
```
È ora possibile accedere ai servizi di ipFamilyPolicy specificati nelle specifiche di PreferDualStack o RequireDualStack tramite IPv4 o IPv6.

Nota
I test end-to-end per la funzionalità dual stack in Kubernetes upstream possono non riuscire perché un nodo del cluster comunica solo il proprio indirizzo IP primario (in questo caso, l'indirizzo IPv4) come indirizzo IP.