Knotennetzwerk

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.

Konfigurieren von DHCP-Reservierungen für Knoten und DNS-Datensätzen für Endpoints (nur 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:
1. 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"}'
```
2. Notieren Sie sich die in der Ausgabe als "host" aufgeführte IP-Adresse wie z. B. 192.168.104.107.
3. Erstellen Sie einen DNS-A-Datensatz, der den FQDN der von Ihnen aufgezeichneten IP-Adresse zuweist.
4. Zum Testen des FQDN erstellen Sie eine neue kubeconfig-Datei, die den FQDN anstelle der IP-Adresse von NSX ALB verwendet:
  1. Generieren Sie die kubeconfig-Datei:
```
tanzu cluster kubeconfig get CLUSTER-NAME --admin --export-file ./KUBECONFIG-TEST
```
  2. 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
```
  3. 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.

Anpassen der IP-Adressen des Clusterknotens (eigenständiger Verwaltungscluster)

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:

vSphere

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.

Hinweis
Für v4.0 und höher wird VMware NSX-T Data Center in „VMware NSX“ umbenannt.

AWS

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).

Legen Sie AWS_PUBLIC_NODE_CIDR fest, um einen IP-Adressbereich für öffentliche Knoten festzulegen.
- Stellen Sie zusätzliche Bereiche zur Verfügung, indem Sie AWS_PRIVATE_NODE_CIDR_1 oder AWS_PRIVATE_NODE_CIDR_2 festlegen.
Legen Sie AWS_PRIVATE_NODE_CIDR fest, um einen IP-Adressbereich für private Knoten festzulegen.
- Stellen Sie zusätzliche Bereiche zur Verfügung, indem Sie AWS_PRIVATE_NODE_CIDR_1 und AWS_PRIVATE_NODE_CIDR_2 festlegen.
Alle Knoten-CIDR-Bereiche müssen innerhalb des VPC-Bereichs des Clusters liegen, der standardmäßig 10.0.0.0/16 ist.

Microsoft Azure

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).

Legen Sie AZURE_NODE_SUBNET_CIDR fest, um ein neues VNet mit einem CIDR-Block für Worker-Knoten-IP-Adressen zu erstellen.
Legen Sie AZURE_CONTROL_PLANE_SUBNET_CIDR fest, um ein neues VNet mit einem CIDR-Block für IP-Adressen der Knoten der Steuerungsebene zu erstellen.
Legen Sie AZURE_NODE_SUBNET_NAME fest, um Worker-Knoten-IP-Adressen aus dem Bereich eines vorhandenen VNet zuzuweisen.
Legen Sie AZURE_CONTROL_PLANE_SUBNET_NAME fest, um IP-Adressen der Knoten der Steuerungsebene aus dem Bereich eines vorhandenen VNet zuzuweisen.

Knoten-IPAM (vSphere)

Bei Verwendung von Knoten-IPAM kann ein Anbieter für clusterinternes IPAM IP-Adressen für Clusterknoten während der Clustererstellung und -skalierung zuordnen und verwalten, sodass kein externes DHCP konfiguriert werden muss.

Sie können Knoten-IPAM für eigenständige Verwaltungscluster auf vSphere und für die von ihnen verwalteten klassenbasierten Arbeitslastcluster konfigurieren. Mit dem folgenden Verfahren konfigurieren Sie Knoten-IPAM für klassenbasierte Arbeitslastcluster. Informationen zum Konfigurieren von Knoten-IPAM für einen Verwaltungscluster finden Sie im Abschnitt Konfigurieren von Knoten-IPAM unter Konfiguration des Verwaltungsclusters für vSphere.

Hinweis
Dieses 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.

Beim Zuweisen von Adressen zu Clusterknoten wählt Knoten-IPAM immer die niedrigste verfügbare Adresse im Pool aus.

Voraussetzungen

Eigenständiger TKG-Verwaltungscluster
Nameserver für die Steuerungsebenen- und Worker-Knoten des Arbeitslastclusters
- Erforderlich, weil Clusterknoten keine Nameserver über DHCP empfangen, um Namen in vCenter aufzulösen.
kubectl und die lokal installierte Tanzu CLI

Einschränkungen

Für Knoten-IPAM gelten in TKG v2.4 die folgenden Einschränkungen:

Nur für neue klassenbasierte Arbeitslastcluster, die von einem Verwaltungscluster auf vSphere bereitgestellt werden.
- Vorhandene DHCP-basierte Cluster können nicht in Knoten-IPAM konvertiert werden.
Keine Unterstützung für Windows-Knoten.
Nur für IPv4- oder IPv6-Umgebung, nicht für Dual-Stacks.
Teilt nur Knotenadressen zu, nicht den Cluster-Steuerungsebenen-Endpoint.
Knoten-IPAM überprüft nicht, ob der IP-Pool mit DHCP-Pools in Konflikt steht, die bereits von anderen Clustern verwendet werden.

Konfigurieren von Knoten-IPAM für einen Arbeitslastcluster

Der Knoten-IPAM-Pool eines Arbeitslastclusters kann durch zwei verschiedene Objekttypen definiert werden, je nachdem, wie seine Adressen mit anderen Clustern gemeinsam genutzt werden:

InClusterIPPool konfiguriert IP-Pools, die nur für Arbeitslastcluster im selben Verwaltungscluster-Namespace (z. B. default) verfügbar sind.
- In TKG v2.1 und v2.2 war dies der einzige verfügbare Typ.
GlobalInClusterIPPool konfiguriert IP-Pools mit Adressen, die Arbeitslastclustern in mehreren Namespaces zugewiesen werden können.

So konfigurieren Sie einen neuen oder vorhandenen Cluster mit Knoten-IPAM:

Erstellen Sie die IP-Pool-Objektdefinitionsdatei my-ip-pool.yaml, in der ein Bereich von IP-Adressen aus einem Subnetz festlegt wird, den TKG für die Zuweisung statischer IP-Adressen für Ihren Arbeitslastcluster verwenden kann. Definieren Sie das Objekt entweder als InClusterIPPool oder als GlobalInClusterIPPool, je nachdem, wie Sie den Geltungsbereich des IP-Pools festlegen möchten. Beispiel:
- InClusterIPPool: Erstellen eines IP-Pools inclusterippool für Arbeitslastcluster im Namespace default, der den Bereich 10.10.10.2-10.10.10.100 plus 10.10.10.102 und 10.10.10.104 enthält:
```
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
```
  Hinweis
  In früheren TKG-Versionen wurde die Version valpha1 des InClusterIPPool-Objekts verwendet, die nur einen zusammenhängenden IP-Pool-Bereich unterstützte, der durch start und end angegeben wurde, wie in der Dokumentation zu TKG v2.1 beschrieben. Beim Upgrade von Clustern auf v2.4 werden ihre IP-Pools in eine neue Struktur konvertiert.
- GlobalInClusterIPPool: Erstellen eines IP-Pools inclusterippool für die gemeinsame Nutzung in Namespaces, der dieselben Adressen enthält wie InClusterIPPool oben:
```
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
```
Erstellen Sie das IP-Pool-Objekt:
```
kubectl apply -f my-ip-pool.yaml
```

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,10.10.10.11
WORKER_NODE_NAMESERVERS: 10.10.10.10,10.10.10.11

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,10.10.10.11]
  - name: worker
    value:
      network:
        nameservers: [10.10.10.10,10.10.10.11]

Jetzt können Sie Ihren Arbeitslastcluster bereitstellen.

Poolregeln

IP-Pool-Bereiche dürfen sich nicht überlappen
- Überlappende Pools können zu Fehlern führen, und TKG validiert weder Poolbereiche noch werden Überlappungen erkannt.
Aktuell zugewiesene IP-Adressen dürfen nicht aus einem IP-Pool entfernt werden.

Fehlerbehebung bei Knoten-IPAM

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
```

IPv6-Netzwerk (vSphere)

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 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:

Konfigurieren von vSphere für IPv6-Adressen, die vom Bootstrap-Cluster aus erreichbar sind.
Konfigurieren des DNS-Auflösers im Docker-Daemon mit einer IPv6-Adresse, die vom Bootstrap-Cluster erreicht werden kann.
Wenn die IPv6-Cluster ein IPv4-Netzwerk erreichen müssen, was in der Regel der Fall ist, konfigurieren Sie einen HTTP-Proxy, wie in Proxy-Konfiguration beschrieben.

Bereitstellen eines IPv6-Verwaltungsclusters

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.
- Legen Sie TKG_IP_FAMILY auf ipv6 fest.
- Legen Sie VSPHERE_CONTROL_PLANE_ENDPOINT auf eine statische IPv6-Adresse fest.
- (Optional) Legen Sie die 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.
- Für die IPv6-Unterstützung müssen Sie den Verwaltungscluster über eine Konfigurationsdatei und nicht über die Installationsprogramm-Schnittstelle bereitstellen.

Bereitstellen eines IPv6-Arbeitslastclusters

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.
- Legen Sie TKG_IP_FAMILY auf ipv6 fest.
- Legen Sie VSPHERE_CONTROL_PLANE_ENDPOINT auf eine statische IPv6-Adresse fest.
- (Optional) Legen Sie die 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.

Dualstapel-Cluster (Tech Preview)

Hinweis
Diese 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:
- Legen Sie die Konfigurationsvariable der IP-Familie fest: TKG_IP_FAMILY: ipv4,ipv6.
- Legen Sie optional die Dienst-CIDRs und Cluster-CIDRs fest.
Hinweis
Es 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.

Hinweis
Die 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.