Beispiele für die Bereitstellung von Tanzu Kubernetes-Clustern mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API

Die Tanzu Kubernetes Grid-Dienst-API bietet intelligente Standardwerte und eine Reihe von Optionen zum Anpassen von Tanzu Kubernetes-Clustern. Schauen Sie sich die Beispiele an, um Cluster verschiedener Typen mit unterschiedlichen Konfigurationen und Anpassungen für Ihre Anforderungen bereitzustellen.

Minimale YAML-Konfiguration für die Bereitstellung eines Tanzu Kubernetes-Clusters

Die folgende Beispiel-YAML ist die Minimalkonfiguration, die zum Aufrufen des Tanzu Kubernetes Grid-Dienst und Bereitstellen eines Tanzu Kubernetes-Clusters erforderlich ist, der alle Standardeinstellungen verwendet.

Zu den Merkmalen der Minimalbeispiels-YAML gehören:

Die als v1.19 aufgelistete Tanzu Kubernetes-Version-Version wird als neueste Verteilung aufgelöst, die der Nebenversion entspricht, zum Beispiel v1.19.7+vmware.1-tkg.1.xxxxxx. Weitere Informationen hierzu finden Sie unter Überprüfen der Tanzu Kubernetes-Cluster-Kompatibilität für ein Update.
Die VM-Klasse best-effort-<size> weist keine Reservierungen auf. Weitere Informationen finden Sie unter VM-Klassen für Tanzu Kubernetes-Cluster.
Der Cluster enthält keinen dauerhaften Speicher für Container. Bei Bedarf wird dies in spec.settings.storage festgelegt. Weitere Informationen finden Sie im folgenden Speicherbeispiel.
Für einige Arbeitslasten, wie z. B. Helm, ist möglicherweise spec.settings.storage.defaultClass erforderlich. Weitere Informationen finden Sie im folgenden Speicherbeispiel.
Der spec.settings.network-Abschnitt ist nicht angegeben. Das bedeutet, dass der Cluster die folgenden Standardnetzwerkeinstellungen verwendet:
- Standard-CNI: antrea
- Standard-Pod-CIDR: 192.168.0.0/16
- Standard-CIDR der Dienste: 10.96.0.0/12
- Standarddienstdomäne: cluster.local
Hinweis: Der IP-Standardbereich für Pods ist 192.168.0.0/16. Wenn dieses Subnetz bereits verwendet wird, müssen Sie einen anderen CIDR-Bereich angeben. Betrachten Sie die Beispiele für benutzerdefinierte Netzwerke unten.

apiVersion: run.tanzu.vmware.com/v1alpha1      #TKGS API endpoint
kind: TanzuKubernetesCluster                   #required parameter
metadata:
  name: tkgs-cluster-1                         #cluster name, user defined
  namespace: tgks-cluster-ns                   #vsphere namespace
spec:
  distribution:
    version: v1.20                             #Resolves to latest TKR 1.20
  topology:
    controlPlane:
      count: 1                                 #number of control plane nodes
      class: best-effort-medium                #vmclass for control plane nodes
      storageClass: vwt-storage-policy         #storageclass for control plane
    workers:
      count: 3                                 #number of worker nodes
      class: best-effort-medium                #vmclass for worker nodes
      storageClass: vwt-storage-policy         #storageclass for worker nodes

Cluster mit separaten Festplatten und Speicherparametern

Die folgende Beispiel-YAML zeigt, wie ein Cluster mit separaten Festplatten und Speicherparametern für Cluster-Steuerungsebene und Worker-Knoten bereitgestellt werden kann.

Das Trennen von Festplatten und Speicherparametern für Daten mit hoher Änderungsrate hilft Ihnen dabei, neben anderen Vorteilen den Lese-Schreib-Overhead im Zusammenhang mit der Verwendung von verknüpften Klonen zu minimieren. Es gibt zwei primäre Anwendungsfälle:

Anpassung der Speicherleistung auf Steuerebenenknoten für die etcd-Datenbank
Anpassung der Größe der Festplatte für Container-Images auf den Worker-Knoten

Das Beispiel beinhaltet folgende Eigenschaften:

Die spec.topology.controlPlane.volumes-Einstellungen geben das getrennte Volume für die etcd-Datenbank an.
Die spec.topology.workers.volumes-Einstellungen geben das getrennte Volume für die Container-Images an.
Der Pfad mountPath: /var/lib/containerd für Container-Images wird für Tanzu Kubernetes, Versionen 1.17 und höher unterstützt.

apiVersion: run.tanzu.vmware.com/v1alpha1      
kind: TanzuKubernetesCluster                   
metadata:
  name: tkgs-cluster-5                         
  namespace: tgks-cluster-ns                   
spec:
  distribution:
    version: v1.20                            
  topology:
    controlPlane:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy
      volumes:
        - name: etcd
          mountPath: /var/lib/etcd
          capacity:
            storage: 4Gi       
    workers:
      count: 3                                 
      class: best-effort-medium                 
      storageClass: vwt-storage-policy        
      volumes:
        - name: containerd
          mountPath: /var/lib/containerd
          capacity:
            storage: 16Gi

Cluster mit einem benutzerdefinierten Antrea-Netzwerk

Das folgende YAML-Beispiel veranschaulicht, wie Sie einen Tanzu Kubernetes-Cluster mit benutzerdefinierten Netzwerkbereichen für das Antrea-CNI bereitstellen.

Da benutzerdefinierte Netzwerkeinstellungen angewendet werden, ist der Parameter cni.name erforderlich, obwohl die standardmäßige Antrea-CNI verwendet wird.
- CNI-Name: antrea
- CIDR für benutzerdefinierte Pods: 193.0.2.0/16
- CIDR für benutzerdefinierte Dienste: 195.51.100.0/12
- Benutzerdefinierte Dienstdomäne: managedcluster.local
Die benutzerdefinierten CIDR-Blöcke dürfen sich nicht mit dem Supervisor-Cluster überschneiden. Weitere Informationen finden Sie unter Konfigurationsparameter für Tanzu Kubernetes-Cluster mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkg-cluster-3-antrea
  namespace: tkgs-cluster-ns
spec:
  distribution:
    version: v1.20
  topology:
    controlPlane:
      class: guaranteed-medium
      count: 3
      storageClass: vwt-storage-policy
    workers:
      class: guaranteed-medium
      count: 5
      storageClass: vwt-storage-policy
  settings:
    network:
      cni:
        name: antrea                       #Use Antrea CNI
      pods:
        cidrBlocks:
        - 193.0.2.0/16                     #Must not overlap with SVC
      services:
        cidrBlocks:
        - 195.51.100.0/12                  #Must not overlap with SVC
      serviceDomain: managedcluster.local

Cluster mit einem benutzerdefinierten Calico-Netzwerk

Die folgende YAML zeigt, wie Sie einen Tanzu Kubernetes-Cluster mit dem benutzerdefinierte Calico-Netzwerk bereitstellen.

Calico ist nicht das standardmäßige CNI, daher wird es explizit im Manifest benannt. Informationen zum Ändern der Standard-CNI auf Dienstebene finden Sie unter Beispiele für die Konfiguration der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.
- CNI-Name: calico
- CIDR für benutzerdefinierte Pods: 198.51.100.0/12
- CIDR für benutzerdefinierte Dienste: 192.0.2.0/16
- Benutzerdefinierte Dienstdomäne: managedcluster.local
Das Netzwerk verwendet benutzerdefinierte CIDR-Bereiche und nicht die Standardwerte. Diese Bereiche dürfen sich nicht mit dem Supervisor-Cluster überschneiden. Weitere Informationen finden Sie unter Konfigurationsparameter für Tanzu Kubernetes-Cluster mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.

apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-2                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-large                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy      
  settings:
    network:
      cni:
        name: calico                           #Use Calico CNI for this cluster
      services:
        cidrBlocks: ["198.51.100.0/12"]        #Must not overlap with SVC
      pods:
        cidrBlocks: ["192.0.2.0/16"]           #Must not overlap with SVC
      serviceDomain: managedcluster.local

Cluster mit Speicherklassen und einer Standardklasse für persistente Volumes

Das folgende YAML-Beispiel zeigt die Bereitstellung eines Clusters mit einer Speicherklasse für dynamische PVC-Bereitstellung und einer Standardspeicherklasse.

Die spec.settings.storage.classes-Einstellung gibt zwei Speicherklassen für persistenten Speicher für Container im Cluster an.
Die spec.settings.storage.defaultClass ist angegeben. Einige Anwendungen erfordern eine Standardklasse. Beispiel: Sie möchten Helm oder Kubeapps als defaultClass verwenden möchten, auf die in vielen Diagrammen verwiesen wird.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: default-storage-spec
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
    workers:
      count: 3
      class: best-effort-medium
      storageClass: vwt-storage-policy
  distribution:
    version: v1.20
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "tanzukubernetescluster.local"
    storage:
      classes: ["gold", "silver"]              #Array of named PVC storage classes
      defaultClass: silver                     #Default PVC storage class

Cluster mit einem Proxy-Server

Sie können einen Proxy-Server mit einem individuellen Tanzu Kubernetes-Cluster verwenden, indem Sie die Konfiguration des Proxyservers auf das Clustermanifest anwenden.

Beachten Sie die folgenden Merkmale:

Der Abschnitt spec.settings.network.proxy gibt die HTTP(s)-Proxy-Konfiguration für diesen Tanzu Kubernetes-Cluster an.
Die Syntax für beide proxy-Serverwerte ist http://<user>:<pwd>@<ip>:<port>.
Bestimmte Endpoints werden automatisch nicht mit dem Pod verbunden, einschließlich localhost und 127.0.0.1 sowie der Pod- und Dienst-CIDRs für Tanzu Kubernetes-Cluster. Sie müssen diese nicht in das noProxy-Feld eingeben.
Das Feld noProxy akzeptiert ein Array von CIDRs ohne Proxy. Rufen Sie die erforderlichen Werte aus dem Arbeitslastnetzwerk im Supervisor-Cluster ab. Weitere Informationen finden Sie in der Abbildung unter Konfigurationsparameter für Tanzu Kubernetes-Cluster mit der Tanzu Kubernetes Grid-Dienst-v1alpha1-API.
Wenn ein globaler Proxy für die TkgServiceConfiguration konfiguriert ist, werden diese Proxy-Informationen nach der ersten Bereitstellung des Clusters an das Clustermanifest weitergegeben. Die globale Proxy-Konfiguration wird nur dann zum Clustermanifest hinzugefügt, wenn beim Erstellen des Clusters keine Proxy-Konfigurationsfelder vorhanden sind. Anders ausgedrückt: Die Konfiguration pro Cluster hat Vorrang und überschreibt eine globale Proxy-Konfiguration.

apiVersion: run.tanzu.vmware.com/v1alpha1    
kind: TanzuKubernetesCluster                 
metadata:
  name: tkgs-cluster-with-proxy                                
  namespace: tkgs-cluster-ns                     
spec:
  distribution:
    version: v1.20                              
  topology:
    controlPlane:
      count: 3                                                        
      class: guaranteed-medium                  
      storageClass: vwt-storage-policy        
    workers:
      count: 5                                                      
      class: guaranteed-xlarge                           
      storageClass: vwt-storage-policy       
  settings:
    storage:
      classes: ["gold", "silver"]              
      defaultClass: silver                     
    network:
      cni:
        name: antrea 
      pods:
        cidrBlocks:
        - 193.0.2.0/16
      services:
        cidrBlocks:
        - 195.51.100.0/12           
      serviceDomain: managedcluster.local
      proxy:
        httpProxy: http://10.186.102.224:3128  #Proxy URL for HTTP connections
        httpsProxy: http://10.186.102.224:3128 #Proxy URL for HTTPS connections
        noProxy: [10.246.0.0/16,192.168.144.0/20,192.168.128.0/20] #SVC Pod, Egress, Ingress CIDRs

Cluster mit benutzerdefinierten Zertifikaten für TLS

Analog dazu, wie Sie trust.additionalTrustedCAs in der TkgServiceConfiguration angeben können (siehe Konfigurationsparameter für die Tanzu Kubernetes Grid-Dienst-v1alpha1-API), können Sie auch trust.additionalTrustedCAs unter dem spec.settings.network in die TanzuKubernetesCluster-Spezifikation aufnehmen. Beispiel:

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
  name: tkgs-cluster-with-custom-certs-tls
  namespace: tkgs-cluster-ns
spec:
  topology:
    controlPlane:
      count: 3
      class: guaranteed-medium
      storageClass: vwt-storage-profile
    workers:
      count: 3
      class: guaranteed-large
      storageClass: vwt-storage-profile
  distribution:
    version: 1.20.2
  settings:
    network:
      cni:
        name: antrea
      services:
        cidrBlocks: ["198.51.100.0/12"]
      pods:
        cidrBlocks: ["192.0.2.0/16"]
      serviceDomain: "managedcluster.local"
      trust:
        additionalTrustedCAs:
          - name: custom-selfsigned-cert-for-tkc
            data: |
              LS0aaaaaaaaaaaaaaabase64...

Cluster, der globale Einstellungen aus der TkgServiceConfiguration-Spezifikation übernimmt oder nicht übernimmt

Hinweis: Die folgenden Cluster-Beispielkonfigurationen erfordern vCenter Server Version 7.0U2a oder höher und mindestens Supervisor-Cluster Version 1.18.10.

Um einen Tanzu Kubernetes-Cluster bereitzustellen, der eine globale Einstellung aus der TkgServiceConfiguration übernimmt, konfigurieren Sie den Cluster so, dass die globale Einstellung entweder nicht angegeben oder ausgenullt ist.

Beispiel: Wenn Sie einen Cluster konfigurieren möchten, der die proxy-Einstellung übernimmt, könnten Sie einen der folgenden Ansätze verwenden:

Option 1: Sie nehmen die proxy-Einstellung nicht in die Cluster-Spezifikation auf:

...
settings:
  network:
    cni:
      name: antrea
    services:
      cidrBlocks: ["198.51.100.0/12"]
    pods:
      cidrBlocks: ["192.0.2.0/16"]
    serviceDomain: "tanzukubernetescluster.local"

Option 2: Sie nehmen die proxy-Einstellung in die Spezifikation auf, legen ihren Wert aber explizit auf null fest:

settings:
  network:
    proxy: null

Um einen Tanzu Kubernetes-Cluster bereitzustellen, der den Standardwert aus der TkgServiceConfiguration nicht übernimmt, konfigurieren Sie die Clusterspezifikation mit allen aufgenommenen Elementen, außer leeren Werten.

Beispiel: Wenn in der TkgServiceConfiguration ein globaler proxy konfiguriert ist und Sie einen Cluster bereitstellen möchten, der die globalen proxy-Einstellungen nicht übernimmt, schließen Sie die folgende Syntax in Ihre Cluster-Spezifikation ein:

...
settings:
  network:
    proxy:
      httpProxy: ""
      httpsProxy: ""
      noProxy: null

Cluster mit Verwendung einer lokalen Inhaltsbibliothek?

Um einen Tanzu Kubernetes-Cluster in einer Air-Gapped-Umgebung bereitzustellen, erstellen Sie einen Cluster mit dem VM-Image, das aus einer lokalen Inhaltsbibliothek synchronisiert ist.

Um einen Cluster mit einem lokalen Inhaltsbibliotheks-Image bereitzustellen, müssen Sie dieses Image in der Clusterspezifikation angeben. Für den Wert distribution.version können Sie entweder den vollständigen Image-Namen eingeben oder, wenn Sie das Namensformat aus dem Image-Verzeichnis beibehalten haben, ihn auf die Kubernetes-Version verkürzen. Wenn Sie eine vollqualifizierte Versionsnummer verwenden möchten, ersetzen Sie ----- durch +. Wenn Sie beispielsweise über ein OVA-Image mit dem Namen photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a verfügen, sind die folgenden Formate akzeptabel.

spec:
  distribution:
    version: v1.20

spec:
  distribution:
    version: v1.20.2

spec:
  distribution:
    version: v1.20.2+vmware.1-tkg.1

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
    name: tgks-cluster-9
    namespace: tkgs-cluster-ns
spec:
   topology:
       controlPlane:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
       workers:
           count: 3
           class: best-effort-medium
           storageClass: vwt-storage-policy
   distribution:
        version: v1.20.2         
   settings:
        network:
          cni:
              name: antrea 
          services:
             cidrBlocks: ["198.51.100.0/12"]
          pods:
             cidrBlocks: ["192.0.2.0/16"]