In diesem Thema wird beschrieben, wie Sie das Knotennetzwerk für Arbeitslastcluster anpassen, einschließlich der Anpassung von Knoten-IP-Adressen und der Konfiguration von DHCP-Reservierungen, Knoten-IPAM und IPv6 auf vSphere.
Für neue Cluster in vSphere müssen Sie DHCP-Reservierungen für die zugehörigen Knoten erstellen. Unter Umständen müssen Sie auch einen DNS-Datensatz für den Endpoint der Steuerungsebene erstellen:
DHCP-Reservierungen für Clusterknoten:
Als Sicherheitsmaßnahme in Umgebungen, in denen mehrere Steuerungsebenenknoten möglicherweise für einen längeren Zeitraum aus- oder offline geschaltet werden, passen Sie die DHCP-Reservierungen für die IP-Adressen der Steuerungsebene und Worker-Knoten eines neu erstellten Clusters so an, dass die Adressen statisch bleiben und die Leases nie ablaufen.
Anweisungen zum Konfigurieren von DHCP-Reservierungen finden Sie in der Dokumentation zum DHCP-Server.
DNS-Datensatz für den Steuerungsebenen-Endpoint:
Wenn Sie NSX Advanced Load Balancer (nicht Kube-Vip) für Ihren Steuerungsebenen-Endpoint verwenden und VSPHERE_CONTROL_PLANE_ENDPOINT
auf einen FQDN anstelle einer numerischen IP-Adresse festlegen, reservieren Sie die Adressen wie folgt:
Rufen Sie die IP-Adresse der Steuerungsebene ab, die NSX ALB dem Cluster zugewiesen hat:
kubectl get cluster CLUSTER-NAME -o=jsonpath='{.spec.controlPlaneEndpoint} {"\n"}'
Notieren Sie sich die in der Ausgabe als "host"
aufgeführte IP-Adresse wie z. B. 192.168.104.107
.
Erstellen Sie einen DNS-A
-Datensatz, der den FQDN der von Ihnen aufgezeichneten IP-Adresse zuweist.
Zum Testen des FQDN erstellen Sie eine neue kubeconfig-Datei, die den FQDN anstelle der IP-Adresse von NSX ALB verwendet:
Generieren Sie die kubeconfig-Datei:
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
Bearbeiten Sie die kubeconfig-Datei KUBECONFIG-TEST
, um die IP-Adresse durch den FQDN zu ersetzen. Ersetzen Sie beispielsweise diese Adresse:
server: https://192.168.104.107:443
mit:
server: https://CONTROLPLANE-FQDN:443
Rufen Sie die Pods des Clusters mithilfe der geänderten kubeconfig-Datei ab:
kubectl get pods -A --kubeconfig=./KUBECONFIG-TEST
Wenn in der Ausgabe die Pods aufgelistet sind, funktioniert DNS für den FQDN.
Sie können clusterspezifische IP-Adressblöcke für Knoten in eigenständigen Verwaltungsclustern und den von ihnen bereitgestellten Arbeitslastclustern konfigurieren. Wie Sie dies tun, hängt von der Cloudinfrastruktur ab, auf der der Cluster ausgeführt wird:
Auf vSphere legt das VSPHERE_NETWORK
der Clusterkonfigurationsdatei das VM-Netzwerk fest, das Tanzu Kubernetes Grid für Clusterknoten und andere Kubernetes-Objekte verwendet. IP-Adressen werden Knoten von einem DHCP-Server zugeteilt, der in diesem VM-Netzwerk ausgeführt und separat von Tanzu Kubernetes Grid bereitgestellt wird.
Wenn Sie das NSX-Netzwerk verwenden, können Sie DHCP-Bindungen für Ihre Clusterknoten konfigurieren, indem Sie Konfigurieren von statischen DHCP-Bindungen in einem Segment in der Dokumentation zu VMware NSX-T Data Center befolgen.
HinweisFür v4.0 und höher wird VMware NSX-T Data Center in „VMware NSX“ umbenannt.
Um clusterspezifische IP-Adressblöcke auf Amazon Web Services (AWS) zu konfigurieren, legen Sie die folgenden Variablen in der Clusterkonfigurationsdatei fest (siehe Beschreibung in der Tabelle AWS der Variablenreferenz für Konfigurationsdatei).
AWS_PUBLIC_NODE_CIDR
fest, um einen IP-Adressbereich für öffentliche Knoten festzulegen.
AWS_PRIVATE_NODE_CIDR_1
oder AWS_PRIVATE_NODE_CIDR_2
festlegen.AWS_PRIVATE_NODE_CIDR
fest, um einen IP-Adressbereich für private Knoten festzulegen.
AWS_PRIVATE_NODE_CIDR_1
und AWS_PRIVATE_NODE_CIDR_2
festlegen.10.0.0.0/16
ist.Um clusterspezifische IP-Adressblöcke in Azure zu konfigurieren, legen Sie die folgenden Variablen in der Clusterkonfigurationsdatei fest (siehe Beschreibung in der Tabelle Microsoft Azure der Variablenreferenz für Konfigurationsdatei).
AZURE_NODE_SUBNET_CIDR
fest, um ein neues VNet mit einem CIDR-Block für Worker-Knoten-IP-Adressen zu erstellen.AZURE_CONTROL_PLANE_SUBNET_CIDR
fest, um ein neues VNet mit einem CIDR-Block für IP-Adressen der Knoten der Steuerungsebene zu erstellen.AZURE_NODE_SUBNET_NAME
fest, um Worker-Knoten-IP-Adressen aus dem Bereich eines vorhandenen VNet zuzuweisen.AZURE_CONTROL_PLANE_SUBNET_NAME
fest, um IP-Adressen der Knoten der Steuerungsebene aus dem Bereich eines vorhandenen VNet zuzuweisen.Bei Knoten-IPAM verwaltet ein Anbieter für clusterinternes IPAM IP-Adressen für Arbeitslastclusterknoten während der Clustererstellung und -skalierung, sodass externes DHCP nicht konfiguriert werden muss.
HinweisDieses Verfahren gilt nicht für TKG mit einem vSphere with Tanzu Supervisor oder mit einem eigenständigen Verwaltungscluster auf AWS oder Azure.
Beim Konfigurieren von Knoten-IPAM für einen neuen oder vorhandenen Arbeitslastcluster gibt der Benutzer einen internen IP-Pool, aus dem der IPAM-Anbieter statische IP-Adressen zuteilt, sowie eine Gateway-Adresse an.
Der IP-Pool ist als subnet
mit optionalen start
- und end
-Adressen konfiguriert, um den Adressbereich innerhalb des Subnetz-CIDR einzuschränken.
Dieses Diagramm zeigt, wie Knoten-IPAM es CAPV ermöglicht, statische Knotenadressen aus seinem IP-Pool zu konfigurieren. Komponenten (durchgezogene Umrandung) und Ressourcendefinitionen (gestrichelte Umrandung), die spezifisch für Knoten-IPAM sind, werden grün angezeigt.
kubectl
und die lokal installierte Tanzu CLIFür Knoten-IPAM gelten in TKG v2.2 die folgenden Einschränkungen:
So konfigurieren Sie einen neuen oder vorhandenen Cluster mit Knoten-IPAM:
Erstellen Sie eine InClusterIPPool
-Objektdefinition, die einen Bereich von IP-Adressen aus einem Subnetz festlegt, mit dem TKG statische IP-Adressen für Ihren Arbeitslastcluster zuteilen kann. Um beispielsweise ein inclusterippool
-Objekt zu erstellen, das 10.10.10.200
bis 10.10.10.250
für Cluster im Namespace default
reserviert:
---
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
Erstellen Sie das InClusterIPPool
-Objekt:
kubectl apply -f my-ip-pool.yaml
Aktivieren Sie die Funktion für benutzerdefinierte Nameserver in der Tanzu CLI-Konfiguration:
tanzu config set features.cluster.custom-nameservers true
Konfigurieren Sie den Arbeitslastcluster so, dass er den IP-Pool entweder innerhalb einer flachen Clusterkonfigurationsdatei oder einer Objektspezifikation im Kubernetes-Stil verwendet, wie in Konfigurationsdateien beschrieben.
Beispiel:
Flache Konfigurationsdatei (zum Erstellen neuer 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
Objektspezifikation (zu Erstellung neuer Cluster oder zum Ändern vorhandener Cluster):
---
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]
Jetzt können Sie Ihren Arbeitslastcluster bereitstellen.
InClusterIPPool
-Objekt mit einem neuen Pool.
Um zu sehen, ob Clusterknoten IP-Adressen zugewiesen wurden, führen Sie kubectl get
aus, um die IaaS-spezifischen Maschinenobjekte vspherevms
aufzulisten und deren Status IPAddressClaimed
zu überprüfen. True
bedeutet, dass die Adressbeanspruchung des Knotens erfolgreich ist. Wenn der Status False
lautet, meldet die Befehlsausgabe einen Reason
, warum die Bedingung nicht bereit ist:
kubectl -n CLUSTER-NAMESPACE get vspherevms
Um die IP-Adressbeanspruchungen anzuzeigen, listen Sie ipaddressclaims
auf. Bei jeder Maschine führt der Eintrag addressesFromPools
dazu, dass ein IPAddressClaim
erstellt wird:
kubectl -n CLUSTER-NAMESPACE get ipaddressclaims
Um die IP-Adressen anzuzeigen, listen Sie ipaddress
auf. Der Anbieter für clusterinternes IPAM sollte jede IPAddressClaim
erkennen und ein entsprechendes IPAddress
-Objekt erstellen:
kubectl -n CLUSTER-NAMESPACE get ipaddress
Wenn alle Beanspruchungen für eine bestimmte VM mit IP-Adressen abgeglichen wurden, schreibt CAPV die zugewiesenen IP-Adressen in die cloud-init-Metadaten der VM und erstellt die VM. Informationen zum Anzeigen der Schritte für den Abgleich von IP-Adressen finden Sie in den CAPV- und CAIP-Protokollen (Cluster-API-IPAM-Provider):
kubectl logs ???n capv-system capv-controller-manager-???
kubectl logs ???n caip-in-cluster-system capi-in-cluster-controller-manager-???
Sie können Verwaltungs- und Arbeitslastcluster in einer auf IPv6 beschränkten Netzwerkumgebung auf vSphere mit Kube-Vip unter Verwendung von Ubuntu-basierten Knoten ausführen.
Hinweise Sie können keine IPv6-Cluster mit einem vSphere with Tanzu-Supervisor-Cluster oder mit einem eigenständigen Verwaltungscluster auf vSphere 8 erstellen. Sie können keine IPv6-Cluster bei Tanzu Mission Control registrieren. NSX Advanced Load Balancer-Dienste und Dual-Stack-IPv4/IPv6-Netzwerke werden derzeit nicht unterstützt.
Voraussetzungen:
Führen Sie die folgenden Schritte auf Ihrer Bootstrap-Maschine aus, um einen Verwaltungscluster in einer IPv6-Netzwerkumgebung bereitzustellen:
Konfigurieren Sie Linux so, dass Routerankündigungen akzeptiert werden, um sicherzustellen, dass die standardmäßige IPv6-Route nicht aus der Routing-Tabelle entfernt wird, wenn der Docker-Dienst gestartet wird. Weitere Informationen finden Sie unter Docker CE deletes IPv6 Default route. sudo sysctl net.ipv6.conf.eth0.accept_ra=2
Erstellen Sie eine Maskierungsregel für den Bootstrap-Cluster, um ausgehenden Datenverkehr vom Bootstrap-Cluster zu senden: sudo ip6tables -t nat -A POSTROUTING -s fc00:f853:ccd:e793::/64 ! -o docker0 -j MASQUERADE
Weitere Informationen zu Maskierungsregeln finden Sie unter MASQUERADE.
Legen Sie die folgenden Variablen in der Konfigurationsdatei für den Verwaltungscluster fest.
TKG_IP_FAMILY
auf ipv6
fest.VSPHERE_CONTROL_PLANE_ENDPOINT
auf eine statische IPv6-Adresse fest.CLUSTER_CIDR and SERVICE_CIDR
fest. Standardmäßig sind dies fd00:100:64::/48
und fd00:100:96::/108
.Stellen Sie den Verwaltungscluster bereit, indem Sie tanzu mc create
ausführen, wie unter Bereitstellen von Verwaltungsclustern über eine Konfigurationsdatei beschrieben.
Wenn Sie einen IPv6-Verwaltungscluster bereitgestellt haben, stellen Sie einen IPv6-Arbeitslastcluster wie folgt bereit:
Legen Sie die folgenden Variablen in der Konfigurationsdatei für den Arbeitslastcluster fest.
TKG_IP_FAMILY
auf ipv6
fest.VSPHERE_CONTROL_PLANE_ENDPOINT
auf eine statische IPv6-Adresse fest.CLUSTER_CIDR and SERVICE_CIDR
fest. Standardmäßig sind dies fd00:100:64::/48
und fd00:100:96::/108
.Stellen Sie einen Arbeitslastcluster gemäß der Beschreibung unter Erstellen von Arbeitslastclustern bereit.
HinweisDiese Funktion befindet sich im nicht unterstützten Tech Preview-Zustand. Weitere Informationen finden Sie unter TKG-Funktionsstatus.
Mit der Dualstapel-Funktion können Sie Cluster mit IPv4- und IPv6-IP-Familien bereitstellen. Die primäre IP-Familie ist jedoch IPv4. Bevor Sie mit dieser Funktion experimentieren, konfigurieren Sie Ihren vCenter Server so, dass sowohl IPv4- als auch IPv6-Konnektivität unterstützt werden.
Im Folgenden sind die Einschränkungen der Dualstapelfunktion in dieser Version aufgeführt:
Die Dualstapelfunktion unterstützt vSphere als einziges IaaS-Produkt (Infrastructure as a Service).
Sie können Dualstapel nicht auf Clustern mit Photon OS-Knoten konfigurieren. Nur Cluster, die mit einem OS_NAME
von ubuntu
konfiguriert sind, werden unterstützt.
Sie können kein Dualstapel-Netzwerk für vSphere with Tanzu Supervisor-Cluster oder die Arbeitslastcluster konfigurieren, die sie erstellen.
Sie können keinen Dualstapel-Verwaltungscluster mit der Installationsprogramm-Schnittstelle bereitstellen.
Sie können die Dualstapel- oder IPv6-Dienste nicht auf den von NSX Advanced Load Balancer (ALB) bereitgestellten Lastausgleichsdiensten verwenden. Sie können kube-vip als Endpoint-Anbieter der Steuerungsebene für einen Dualstapel-Cluster verwenden. Die Verwendung von NSX ALB als Endpoint-Anbieter der Steuerungsebene für einen Dualstapel-Cluster wurde nicht validiert.
Nur die Kern-Add-On-Komponenten wie Antrea, Calico, CSI, CPI und Pinniped wurden für die Dualstapelunterstützung in dieser Version validiert.
So konfigurieren Sie Dualstapel auf den Clustern:
Setzen Sie das Dualstapel-Funktions-Flag:
a. Um die Funktion auf dem Verwaltungscluster zu aktivieren, führen Sie den folgenden Befehl aus:
tanzu config set features.management-cluster.dual-stack-ipv4-primary true
b. Um die Funktion auf dem Arbeitslastcluster zu aktivieren, führen Sie den folgenden Befehl aus:
tanzu config set features.cluster.dual-stack-ipv4-primary true
Stellen Sie Verwaltungscluster bereit oder erstellen Sie Arbeitslastcluster, je nachdem, was erforderlich ist.
In der Clusterkonfigurationsdatei:
TKG_IP_FAMILY: ipv4,ipv6
.HinweisEs gibt zwei CIDRs für jede Variable. Die IP-Familien dieser CIDRs folgen der Reihenfolge der konfigurierten
TKG_IP_FAMILY
. Der größte für die IPv4-Adressen zulässige CIDR-Bereich ist /12, und der größte IPv6-SERVICE_CIDR-Bereich ist /108. Wenn Sie die CIDRs nicht festlegen, werden die Standardwerte verwendet.
Legen Sie den folgenden Konfigurationsdateiparameter fest, wenn Sie Antrea als CNI für Ihren Cluster verwenden:
ANTREA_ENDPOINTSLICES: true
Auf die Dienste, deren ipFamilyPolicy
in ihren Spezifikationen von PreferDualStack
oder RequireDualStack
angegeben ist, kann jetzt über IPv4 oder IPv6 zugegriffen werden.
HinweisDie End-to-End-Tests für die Dualstapelfunktion in einem vorgelagerten Kubernetes können fehlschlagen, da ein Clusterknoten nur seine primäre IP-Adresse (in diesem Fall die IPv4-Adresse) als seine IP-Adresse veröffentlicht.