Die deklarative Tanzu Kubernetes Grid-Dienst-API stellt mehrere Parameter für die Konfiguration von Tanzu Kubernetes zur Verfügung. Informationen zur Bereitstellung und Anpassung Ihrer Cluster finden Sie in der Liste und Beschreibung aller Parameter und Nutzungsrichtlinien.

YAML mit Anmerkungen für die Bereitstellung eines Tanzu Kubernetes-Clusters

Die gekennzeichnete YAML listet alle verfügbaren Parameter für die Bereitstellung eines Tanzu Kubernetes-Clusters mit zusammengefassten Kommentaren für jedes Feld auf.
Hinweis: Die gekennzeichnete YAML wird für die Bereitstellung eines Clusters nicht validiert. Weitere Informationen finden Sie in den Beispielen: Beispiele für die Bereitstellung von Tanzu Kubernetes-Clustern mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API. 
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: <tanzu kubernetes cluster name>
  namespace: <vsphere namespace where the cluster will be provisioned>
spec:
  distribution:
    version: <tanzu kubernetes release version string: full, point, short>      
  topology:                               
    controlPlane:
      count: <integer either 1 or 3>
      class: <vm class bound to the target vsphere namespace>
      storageClass: <vsphere storage policy bound to the target vsphere namespace>
      volumes: #optional setting for high-churn control plane component (such as etcd)
        - name: <user-defined string>
          mountPath: </dir/path>
          capacity:
            storage: <size in GiB> 
    workers:                              
      count: <integer from 0 to 150>
      class: <vm class bound to the target vsphere namespace>
      storageClass: <vsphere storage policy bound to the target vsphere namespace>
      volumes: #optional setting for high-churn worker node component (such as containerd)
        - name: <user-defined string>
          mountPath: </dir/path>
          capacity:
            storage: <size in GiB>              
  settings: #all spec.settings are optional
    storage: #optional storage settings
      classes: [<array of kubernetes storage classes for dynamic pvc provisioning>]
      defaultClass: <default kubernetes storage class>
    network: #optional network settings
      cni: #override default cni set in the tkgservicesonfiguration spec
        name: <antrea or calico>
      pods: #custom pod network
        cidrBlocks: [<array of pod cidr blocks>]
      services: #custom service network
        cidrBlocks: [<array of service cidr blocks>]
      serviceDomain: <custom service domain>
      proxy: #proxy server for outbound connections
        httpProxy: http://<IP:PORT> 
        httpsProxy: http://<IP:PORT>
        noProxy: [<array of CIDRs to not proxy>]
      trust: #trust fields for custom public certs for tls
        additionalTrustedCAs:
          - name: <first-cert-name>
            data: <base64-encoded string of PEM encoded public cert 1>
          - name: <second-cert-name>
            data: <base64-encoded string of PEM encoded public cert 2>

Parameter für die Bereitstellung von Tanzu Kubernetes-Clustern

In der Tabelle werden alle Parameter und akzeptablen Werte für die Bereitstellung eines Tanzu Kubernetes-Clusters beschrieben. Beispiele finden Sie unter Beispiele für die Konfiguration der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.

Tabelle 1. Parameter für die Bereitstellung von Tanzu Kubernetes-Clustern
Name Wert Beschreibung
apiVersion run.tanzu.vmware.com/v1alpha1 Gibt die Version der Tanzu Kubernetes Grid-Dienst-API an.
kind TanzuKubernetesCluster Gibt den Typ der zu erstellenden Kubernetes-Ressource an. Der einzige zulässige Wert ist TanzuKubernetesCluster (Groß-/Kleinschreibung beachten).
metadata Abschnitt für Clustermetadaten Beinhaltet Clustermetadaten wie name und namespace. Dies sind standardmäßige Kubernetes-Metadaten. Sie können daher generateName anstelle von name verwenden, Beschriftungen und Anmerkungen hinzufügen und so weiter.
name Eine benutzerdefinierte Zeichenfolge, die alphanumerische Zeichen und Bindestriche akzeptiert, z. B.: my-tkg-cluster-1 Gibt den Namen des zu erstellenden Clusters an. Aktuelle Einschränkungen für die Benennung von Clustern:
  • Der Name darf maximal 41 Zeichen lang sein.
  • Der Name muss mit einem Buchstaben beginnen.
  • Der Name darf Buchstaben, Ziffern und Bindestriche enthalten.
  • Der Name muss mit einem Buchstaben oder einer Ziffer enden.
namespace Eine benutzerdefinierte Zeichenfolge, die alphanumerische Zeichen und Bindestriche akzeptiert, z. B.: my-sns-1 Identifiziert den Namen des Supervisor-Namespace, in dem der Cluster bereitgestellt wird. Dies ist ein Verweis auf einen Supervisor-Namespace, der im Supervisor-Cluster vorhanden ist.
spec Abschnitt für technische Spezifikationen für den Cluster Enthält die deklarativ ausgedrückte Spezifikation für den Endzustand des Clusters, einschließlich toplogy für den Knoten und distribution für die Kubernetes-Software.
distribution Abschnitt zur Angabe der Tanzu Kubernetes Release-Version Gibt die Distribution für den Cluster an: die auf der Steuerungsebene und den Worker-Knoten installierte Tanzu Kubernetes-Cluster-Software, einschließlich Kubernetes selbst.
version Alphanumerische Zeichenfolge mit Bindestrichen für die Kubernetes-Version, z. B.: v1.20.2+vmware.1-tkg.1, v1.20.2 oder v1.20 Gibt unter Verwendung der semantischen Versionsnotation die Softwareversion der Kubernetes-Verteilung an, die auf Clusterknoten installiert werden soll. Kann die vollqualifizierte Version angeben oder Kurzschreibungen der Version verwenden, z. B. „version: v1.20.2“ (wird zum neuesten mit dieser Patchversion übereinstimmenden Image aufgelöst) oder „version: v1.20“ (wird zur neuesten übereinstimmenden Patchversion aufgelöst). Die aufgelöste Version wird in der Clusterbeschreibung als „fullVersion“ angezeigt, nachdem Sie sie erstellt haben.
topology Abschnitt für Clusterknotentopologien Enthält Felder, die die Anzahl, den Zweck und die Organisation der Clusterknoten sowie die diesen jeweils zugeteilten Ressourcen beschreiben. Clusterknoten werden basierend auf dem Verwendungszweck in Pools zusammengefasst: entweder control-plane oder worker. Jeder Pool ist homogen, weist dieselbe Ressourcenzuteilung auf und verwendet denselben Speicher.
controlPlane Abschnitt für Control Plane-Einstellungen Gibt die Topologie der Steuerungsebene des Clusters an, einschließlich der Anzahl der Knoten (count), des VM-Typs (class) und der jedem Knoten zugeordneten Speicherressourcen (storageClass).
count Eine Ganzzahl, die entweder 1 oder 3 lautet Gibt die Anzahl der Knoten der Steuerungsebene an. Die Steuerungsebene muss eine ungerade Anzahl an Knoten aufweisen.
class Ein systemdefiniertes Element in Form einer Zeichenfolge aus einem Enumerationssatz, z. B.: guaranteed-small oder best-effort-large Gibt den Namen der VirtualMachineClass zur Beschreibung der für jeden Knoten im Pool zu verwendenden virtuellen Hardwareeinstellungen an. Hiermit werden die Hardware, die dem Knoten (CPU und Arbeitsspeicher) zur Verfügung steht, sowie die Anforderungen und Grenzwerte für diese Ressourcen gesteuert. Weitere Informationen hierzu finden Sie unter VM-Klassen für Tanzu Kubernetes-Cluster.
storageClass Beispiel: node-storage Gibt die Speicherklasse an, die für den Speicher der Festplatten verwendet werden soll, auf denen die Root-Dateisysteme der Knoten der Steuerungsebene gespeichert werden. Führen Sie kubectl describe ns im Namespace aus, um die verfügbaren Speicherklassen anzuzeigen. Die verfügbaren Speicherklassen für den Namespace richten sich nach dem Speicher, der vom vSphere-Administrator festgelegt wurde. Die mit dem Supervisor-Namespace verknüpften Speicherklassen werden im Cluster repliziert. Mit anderen Worten: Die Speicherklasse muss im Supervisor-Namespace verfügbar sein, damit sie ein gültiger Wert für dieses Feld sein kann. Weitere Informationen finden Sie unter Konfigurieren und Verwalten von vSphere-Namespaces.
volumes
Optionale Speichereinstellung
  • volumes:
    • name: string
    • mountPath: /dir/path
    • Kapazität
      • storage: Größe in GiB
 Kann getrennte Datenträger- und Speicherparameter für etcd auf den Knoten der Steuerungsebene angeben. Sehen Sie sich das Beispiel Cluster mit separaten Festplatten und Speicherparametern an.
workers Abschnitt für Worker-Knoteneinstellungen Gibt die Topologie der Worker-Knoten des Clusters an, einschließlich der Anzahl der Knoten (count), des VM-Typs (class) und der jedem Knoten zugeordneten Speicherressourcen (storageClass).
count Eine Ganzzahl zwischen 0 und 150, z. B.: 1, 2 oder 7 Gibt die Anzahl der Worker-Knoten im Cluster an. Es kann ein Cluster mit null Worker-Knoten erstellt werden, also ein Cluster, der nur Knoten der Steuerungsebene umfasst. Es gibt zwar keinen strikten Höchstwert für die Anzahl der Worker-Knoten, aber ein angemessener Grenzwert liegt bei 150.
Hinweis: Einem mit 0 Worker-Knoten bereitgestellten Cluster werden keine Lastausgleichsdienste zugewiesen.
class Ein systemdefiniertes Element in Form einer Zeichenfolge aus einem Enumerationssatz, z. B.: guaranteed-small oder best-effort-large Gibt den Namen der VirtualMachineClass zur Beschreibung der für jeden Knoten im Pool zu verwendenden virtuellen Hardwareeinstellungen an. Hiermit werden die Hardware, die dem Knoten (CPU und Arbeitsspeicher) zur Verfügung steht, sowie die Anforderungen und Grenzwerte für diese Ressourcen gesteuert. Weitere Informationen hierzu finden Sie unter VM-Klassen für Tanzu Kubernetes-Cluster.
storageClass Beispiel: node-storage Gibt die Speicherklasse an, die für den Speicher der Festplatten verwendet werden soll, auf denen die Root-Dateisysteme der Worker-Knoten gespeichert werden. Führen Sie kubectl describe ns im Namespace aus, um die verfügbaren Speicherklassen aufzulisten. Die verfügbaren Speicherklassen für den Namespace richten sich nach dem Speicher, der vom vSphere-Administrator festgelegt wurde. Die mit dem Supervisor-Namespace verknüpften Speicherklassen werden im Cluster repliziert. Mit anderen Worten: Die Speicherklasse muss im Supervisor-Namespace verfügbar sein, damit sie gültig ist. Weitere Informationen finden Sie unter Konfigurieren und Verwalten von vSphere-Namespaces.
volumes
Optionale Speichereinstellung
  • volumes:
    • name: string
    • mountPath: /dir/path
    • Kapazität
      • storage: Größte in GiB
 Kann getrennte Datenträger- und Speicherparameter für Container-Images auf Worker-Knoten angeben. Sehen Sie sich das Beispiel Cluster mit separaten Festplatten und Speicherparametern an.
settings Abschnitt für clusterspezifische Einstellungen; alle spec.settings sind optional Identifiziert optionale Laufzeitkonfigurationsinformationen für den Cluster, einschließlich network-Details zum Knoten und persistentem storage für Pods.
storage Abschnitt zur Angabe des Speichers Identifiziert Speichereinträge persistenter Volumes (PV) für Containerarbeitslasten.
classes Array aus einer oder mehreren benutzerdefinierten Zeichenfolgen, z. B.: ["gold", "silver"] Gibt Speicherklassen benannter persistenter Volumes (PV) für Containerarbeitslasten an. Die mit dem Supervisor-Namespace verknüpften Speicherklassen werden im Cluster repliziert. Mit anderen Worten: Die Speicherklasse muss im Supervisor-Namespace verfügbar sein, damit sie ein gültiger Wert sein kann. Sehen Sie sich das Beispiel Cluster mit Speicherklassen und einer Standardklasse für persistente Volumes an.
defaultClass Beispiel: silver Gibt eine benannte Speicherklasse an, die als Standard im Cluster gekennzeichnet werden soll. Unterlassen Sie diese Angabe, gibt es keinen Standard. Sie müssen nicht eine oder mehrere classes angeben, um eine defaultClass anzugeben. Für einige Arbeitslasten ist möglicherweise eine Standardklasse erforderlich, wie z. B. „Helm“. Sehen Sie sich das Beispiel Cluster mit Speicherklassen und einer Standardklasse für persistente Volumes an.
network Abschnittsmarkierung für Netzwerkeinstellungen Gibt netzwerkbezogene Einstellungen für den Cluster an.
cni Abschnittsmarkierung zum Festlegen der CNI Identifiziert das CNI-Plug-In (Container Networking Interface) für den Cluster. Die Standardeinstellung lautet „Antrea“ und muss nicht für neue Cluster angegeben werden.
name Zeichenfolge antrea oder calico Gibt das zu verwendende CNI an. Antrea und Calico werden unterstützt. In der Systemkonfiguration wird Antrea als Standard-CNI festgelegt. Die Standard-CNI kann geändert werden. Bei Verwendung des Standardwerts muss in diesem Feld keine Angabe vorgenommen werden.
services Abschnittsmarkierung für die Angabe von Subnetzen für Kubernetes-Dienste Identifiziert Netzwerkeinstellungen für Kubernetes-Dienste. Standardwert ist 10.96.0.0/12.
cidrBlocks Beispiel: Array ["198.51.100.0/12"] Gibt einen IP-Adressbereich an, der für Kubernetes-Dienste verwendet werden soll. Standardwert ist 10.96.0.0/12. Dieser darf sich nicht mit den für den Supervisor-Cluster ausgewählten Einstellungen überschneiden. Obwohl es sich bei diesem Feld um ein Array für mehrere Bereiche handelt, ist derzeit nur ein einzelner IP-Bereich zulässig. Netzwerkbeispiele finden Sie unter Beispiele für die Bereitstellung von Tanzu Kubernetes-Clustern mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.
pods Abschnittsmarkierung für die Angabe von Subnetzen für Kubernetes-Pods Gibt Netzwerkeinstellungen für Pods an. Standardwert ist 192.168.0.0/16. Die Mindestblockgröße beträgt /24.
cidrBlocks Beispiel: Array ["192.0.2.0/16"] Gibt einen IP-Adressbereich an, der für Kubernetes-Pods verwendet werden soll. Standardwert ist 192.168.0.0/16. Dieser darf sich nicht mit den für den Supervisor-Cluster ausgewählten Einstellungen überschneiden. Die Subnetzgröße der Pods muss größer oder gleich /24 sein. Obwohl es sich bei diesem Feld um ein Array für mehrere Bereiche handelt, ist derzeit nur ein einzelner IP-Bereich zulässig. Netzwerkbeispiele finden Sie unter Beispiele für die Bereitstellung von Tanzu Kubernetes-Clustern mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.
serviceDomain "cluster.local" Gibt die Dienstdomäne für den Cluster an. Der Standardwert lautet cluster.local.
proxy Abschnitt, der die HTTP(s)-Proxy-Konfiguration für den Cluster festlegt. Ist dies implementiert, sind alle Felder erforderlich. Stellt Felder für die festgelegten Proxy-Einstellungen bereit. Diese werden automatisch mit Daten gefüllt, wenn ein globaler Proxy und kein einzelner Cluster-Proxy konfiguriert ist. Sehen Sie sich das Beispiel Cluster mit einem Proxy-Server an.
httpProxy http://<user>:<pwd>@<ip>:<port> Legt eine Proxy-URL fest, die zum Erstellen von HTTP-Verbindungen außerhalb des Clusters verwendet werden soll.
httpsProxy http://<user>:<pwd>@<ip>:<port> Legt eine Proxy-URL fest, die zum Erstellen von HTTPS-Verbindungen außerhalb des Clusters verwendet werden soll.
noProxy

Array von CIDR-Blöcken ohne Proxy, z. B.: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20].

Die erforderlichen Werte kommen aus dem Arbeitslastnetzwerk im Supervisor-Cluster: Pod CIDRs, Ingress CIDRs und Egress CIDRs.

In der Abbildung unten finden Sie Informationen darüber, welche Werte im Array-Feld noProxy enthalten sein sollen.

Sie dürfen die Subnetze, die vom Arbeitslastnetzwerk im Supervisor-Cluster für Pods, Ingress und Egress verwendet werden, nicht über einen Proxy weiterleiten.

Es ist nicht erforderlich, dass Sie die Dienst-CIDR vom Supervisor-Cluster in das Feld noProxy eingeben. Tanzu Kubernetes-Cluster interagieren nicht mit solchen Diensten.

Die Endpoints localhost und 127.0.0.1 werden automatisch nicht über einen Proxy weitergeleitet. Sie müssen sie nicht zum Feld noProxy hinzufügen.

Die Pod- und Dienst-CIDRs für Tanzu Kubernetes-Cluster werden automatisch nicht über einen Proxy weitergeleitet. Sie müssen sie nicht zum Feld noProxy hinzufügen.

Sehen Sie sich das Beispiel Cluster mit einem Proxy-Server an.
trust Abschnittsmarkierung für trust-Parameter. Akzeptiert keine Daten.
additionalTrustedCAs Akzeptiert ein Array von Zertifikaten mit name und data für jedes Zertifikat. Akzeptiert keine Daten.
name String Name des TLS-Zertifikats
data String Die Base64-codierte Zeichenfolge eines PEM-codierten öffentlichen Zertifikats.

Rufen Sie die erforderlichen noProxy-Werte aus dem Arbeitslastnetzwerk wie im Supervisor-Cluster dargestellt ab.

Das Fenster „Arbeitslastnetzwerk“ mit den hervorgehobenen Werten für „Pod-CIDRs“, „Ingress-CIDRs“ und „Egress-CIDRs“.