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.
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:
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"}'
Registrare l'indirizzo IP indicato come "host"
nell'output, ad esempio 192.168.104.107
.
Creare un record DNS A
che associ il nome di dominio completo all'indirizzo IP registrato.
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:
Generare il kubeconfig:
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
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
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.
È 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:
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.
NotaA partire dalla versione 4.0, VMware NSX-T Data Center è stato rinominato con "VMware NSX".
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.
AWS_PUBLIC_NODE_CIDR
per impostare un intervallo di indirizzi IP per i nodi pubblici.
AWS_PRIVATE_NODE_CIDR_1
o AWS_PRIVATE_NODE_CIDR_2
AWS_PRIVATE_NODE_CIDR
per impostare un intervallo di indirizzi IP per i nodi privati.
AWS_PRIVATE_NODE_CIDR_1
e AWS_PRIVATE_NODE_CIDR_2
10.0.0.0/16
.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.
AZURE_NODE_SUBNET_CIDR
per creare una nuova VNet con un blocco CIDR per gli indirizzi IP dei nodi worker.AZURE_CONTROL_PLANE_SUBNET_CIDR
per creare una nuova VNet con un blocco CIDR per gli indirizzi IP dei nodi del piano di controllo.AZURE_NODE_SUBNET_NAME
per assegnare gli indirizzi IP dei nodi worker dall'intervallo di una VNet esistente.AZURE_CONTROL_PLANE_SUBNET_NAME
per assegnare gli indirizzi IP dei nodi del piano di controllo dall'intervallo di una VNet esistente.Con L'IPAM dei nodi, un provider IPAM in-cluster gestisce gli indirizzi IP per i nodi cluster del carico di lavoro durante la creazione e la scalabilità dei cluster, eliminando qualsiasi necessità di configurare un DHCP esterno.
NotaQuesta 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.
Il pool di IP è configurato come subnet
, con indirizzi start
e end
facoltativi per limitare l'intervallo di indirizzi all'interno del CIDR della subnet.
Questo diagramma mostra in che modo l'IPAM dei nodi consente a CAPV di configurare gli indirizzi dei nodi statici dal relativo pool di IP. I componenti (contorno continuo) e le definizioni di risorse (contorno tratteggiato) specifici per il nodo IPAM sono visualizzati in verde.
kubectl
e CLI di Tanzu installati in localeL'IPAM dei nodi ha le seguenti limitazioni in TKG v2.1:
Per configurare un cluster nuovo o esistente con l'IPAM dei nodi:
Creare una definizione di oggetto InClusterIPPool
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. Ad esempio, per creare un oggetto inclusterippool
che riserva da 10.10.10.200
a 10.10.10.250
per i cluster nello spazio dei nomi default
:
---
apiVersion: ipam.cluster.x-k8s.io/v1alpha1
kind: InClusterIPPool
metadata:
name: inclusterippool
# the namespace where the workload cluster is deployed
namespace: default
spec:
# replace the IPs below with what works for your environment
subnet: 10.10.10.0/24
gateway: 10.10.10.1
# start and end are optional fields that restrict the allocatable address range
# within the subnet
start: 10.10.10.200
end: 10.10.10.250
Creare l'oggetto InClusterIPPool
:
kubectl apply -f my-ip-pool.yaml
Abilitare la funzionalità dei server dei nomi personalizzati nella configurazione della CLI di Tanzu:
tanzu config set features.cluster.custom-nameservers true
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
WORKER_NODE_NAMESERVERS: 10.10.10.10
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]
- name: worker
value:
network:
nameservers: [10.10.10.10]
Ora è possibile distribuire il cluster del carico di lavoro.
InClusterIPPool
attivo con un nuovo pool
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-???
È 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 o con un cluster di gestione autonomo in vSphere 8. 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:
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.
TKG_IP_FAMILY
su ipv6
.VSPHERE_CONTROL_PLANE_ENDPOINT
su un indirizzo IPv6 statico.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.
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.
TKG_IP_FAMILY
su ipv6
.VSPHERE_CONTROL_PLANE_ENDPOINT
su un indirizzo IPv6 statico.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.
NotaLo 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:
TKG_IP_FAMILY: ipv4,ipv6
.NotaSono 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.
NotaI 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.