Esempi di provisioning dei cluster Tanzu Kubernetes mediante l'API v1alpha1 del Servizio Tanzu Kubernetes Grid

L'API del Servizio Tanzu Kubernetes Grid offre valori predefiniti intelligenti e un array di opzioni per la personalizzazione dei cluster Tanzu Kubernetes. Fare riferimento agli esempi per eseguire il provisioning di cluster di vari tipi con configurazioni e personalizzazioni diverse in base alle proprie esigenze.

Codice YAML minimo per il provisioning di un cluster Tanzu Kubernetes

Il seguente esempio di codice YAML è la configurazione minima necessaria per richiamare il Servizio Tanzu Kubernetes Grid ed eseguire il provisioning di un cluster Tanzu Kubernetes che utilizza tutte le impostazioni predefinite.

Le caratteristiche del codice YAML minimo di esempio includono:

La versione Release di Tanzu Kubernetes, elencata come v1.19, è stata risolta nella distribuzione più recente corrispondente a quella versione secondaria, ad esempio v1.19.7+vmware.1-tkg.1.xxxxxx. Vedere Elenco di Release di Tanzu Kubernetes.
La classe di macchine virtuali best-effort-<size> non ha prenotazioni. Per ulteriori informazioni, vedere Classi di macchine virtuali per i cluster di Tanzu Kubernetes.
Il cluster non include lo storage persistente per i contenitori. Se necessario, questa opzione è impostata in spec.settings.storage. Vedere l'esempio di storage seguente.
Alcuni carichi di lavoro, come Helm, potrebbero richiedere spec.settings.storage.defaultClass. Vedere l'esempio di storage seguente.
La sezione spec.settings.network non è specificata. Questo significa che il cluster utilizza le seguenti impostazioni di rete predefinite:
- CNI predefinita: antrea
- CIDR pod predefinito: 192.168.0.0/16
- CIDR servizi predefinito: 10.96.0.0/12
- Dominio del servizio predefinito: cluster.local
Nota: L'intervallo di IP predefinito per i pod è 192.168.0.0/16. Se questa subnet è già in uso, è necessario specificare un intervallo CIDR diverso. Di seguito sono riportati gli esempi della rete personalizzata.

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 con dischi separati e parametri di storage

Il seguente esempio di codice YAML illustra come eseguire il provisioning di un cluster con dischi e parametri di storage separati per il piano di controllo del cluster e i nodi di lavoro.

L'uso della separazione dei dischi e dei parametri di storage per un utilizzo elevato dei dati consente di ridurre al minimo l'overhead di lettura-scrittura relativo all'uso di cloni collegati, tra gli altri vantaggi. Esistono due casi d'uso principali:

Personalizzazione delle prestazioni di storage nei nodi del piano di controllo per il database etcd
Personalizzazione della dimensione del disco per le immagini del contenitore nei nodi di lavoro

L'esempio ha le seguenti caratteristiche:

Le impostazioni di spec.topology.controlPlane.volumes specificano il volume separato per il database etcd.
Le impostazioni del spec.topology.workers.volumes specificano il volume separato per le immagini del contenitore.
Il mountPath: /var/lib/containerd per le immagini del contenitore è supportato per le versioni 1.17 e successive di Tanzu Kubernetes.

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 con una rete Antrea personalizzata

Il seguente codice YAML illustra come eseguire il provisioning di un cluster Tanzu Kubernetes con intervalli di rete personalizzati per l'interfaccia CNI di Antrea.

Poiché vengono applicate impostazioni di rete personalizzate, il parametro di cni.name è obbligatorio anche se viene utilizzata l'interfaccia CNI di Antrea predefinita.
- Nome CNI: antrea
- CIDR pod personalizzati: 193.0.2.0/16
- CIDR servizi personalizzati: 195.51.100.0/12
- Dominio del servizio personalizzato: managedcluster.local
I blocchi CIDR personalizzati non possono sovrapporsi con il Cluster supervisore. Per ulteriori informazioni, vedere Parametri di configurazione per i cluster di Tanzu Kubernetes che utilizzano l'API v1alpha1 di Servizio Tanzu Kubernetes Grid.

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 con una rete Calico personalizzata

Il seguente codice YAML illustra come eseguire il provisioning di un cluster Tanzu Kubernetes con una rete Calico personalizzata.

Calico non è l'interfaccia CNI predefinita, quindi viene esplicitamente denominata nel manifesto. Per modificare l'interfaccia CNI predefinita a livello di servizio, vedere Esempi di configurazione dell'API v1alpha1 del Servizio Tanzu Kubernetes Grid.
- Nome CNI: calico
- CIDR pod personalizzati: 198.51.100.0/12
- CIDR servizi personalizzati: 192.0.2.0/16
- Dominio del servizio personalizzato: managedcluster.local
La rete utilizza intervalli CIDR personalizzati, non i valori predefiniti. Questi intervalli non devono sovrapporsi al Cluster supervisore. Vedere Parametri di configurazione per i cluster di Tanzu Kubernetes che utilizzano l'API v1alpha1 di Servizio Tanzu Kubernetes Grid.

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 con classi di storage e classe predefinita per volumi persistenti

Il seguente esempio di codice YAML mostra come eseguire il provisioning di un cluster con classi di storage per il provisioning dinamico del PVC e una classe di storage predefinita.

L'impostazione spec.settings.storage.classes specifica due classi di storage per lo storage persistente per i contenitori nel cluster.
Viene specificata spec.settings.storage.defaultClass. Alcune applicazioni richiedono una classe predefinita. Ad esempio, se si desidera utilizzare Helm o Kubeapps come defaultClass, a cui fanno riferimento molti grafici.

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 con server proxy

È possibile utilizzare un server proxy con un cluster Tanzu Kubernetes individuale applicando la configurazione del server proxy al manifesto del cluster.

Si tenga presente quanto segue:

La sezione spec.settings.network.proxy specifica la configurazione del proxy HTTP(s) per questo cluster Tanzu Kubernetes.
La sintassi per entrambi i valori del server proxy è http://<user>:<pwd>@<ip>:<port>.
Gli endpoint specifici non vengono elaborati automaticamente mediante il proxy, inclusi localhost e 127.0.0.1, nonché i CIDR pod e servizio per i cluster Tanzu Kubernetes. Non è necessario includerle nel campo noProxy.
Il campo del noProxy accetta un array di CIDR non come proxy. Recuperare i valori richiesti dalla rete del carico di lavoro nel Cluster supervisore. Fare riferimento all'immagine in Parametri di configurazione per i cluster di Tanzu Kubernetes che utilizzano l'API v1alpha1 di Servizio Tanzu Kubernetes Grid.
Se in TkgServiceConfiguration è configurato un proxy globale, le informazioni di tale proxy vengono propagate al manifesto del cluster dopo la distribuzione iniziale del cluster. La configurazione del proxy globale viene aggiunta al manifesto del cluster solo se non sono presenti campi di configurazione del proxy durante la creazione del cluster. In altre parole, la configurazione per cluster ha la precedenza e sovrascriverà la configurazione di un proxy globale.

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 con certificati personalizzati per TLS

Analogamente alla procedura per specificare un trust.additionalTrustedCAs in TkgServiceConfiguration (vedere Parametri di configurazione per l'API v1alpha1 di Servizio Tanzu Kubernetes Grid), è possibile includere trust.additionalTrustedCAs in spec.settings.network nella specifica TanzuKubernetesCluster. Ad esempio:

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 che eredita o meno le impostazioni globali dalla specifica TkgServiceConfiguration

Nota: Le configurazioni dei cluster di esempio seguenti richiedono vCenter Server versione 7.0U2a o successiva e almeno Cluster supervisore versione 1.18.10.

Per eseguire il provisioning di un cluster Tanzu Kubernetes che erediti un'impostazione globale da TkgServiceConfiguration, configurare il cluster con l'impostazione globale non specificata o nulled out.

Ad esempio, se si desidera configurare un cluster che erediti l'impostazione proxy, è possibile utilizzare uno degli approcci seguenti:

Opzione 1: non includere l'impostazione proxy nella specifica del cluster:

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

Opzione 2: includere l'impostazione proxy nella specifica, ma impostare esplicitamente il suo valore su null:

settings:
  network:
    proxy: null

Per eseguire il provisioning di un cluster Tanzu Kubernetes che non erediti il valore predefinito da TkgServiceConfiguration, configurare la specifica del cluster con tutti gli elementi inclusi ma valori vuoti.

Ad esempio, se TkgServiceConfiguration ha un proxy globale configurato e si desidera eseguire il provisioning di un cluster che non eredita le impostazioni del proxy globali, includere la seguente sintassi nella specifica del cluster:

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

Cluster mediante una libreria di contenuti locale

Per eseguire il provisioning di un cluster Tanzu Kubernetes in un ambiente air gap, creare un cluster utilizzando l'immagine della macchina virtuale sincronizzata da una libreria di contenuti locale.

Per eseguire il provisioning di un cluster utilizzando un'immagine della libreria di contenuti locale, è necessario specificare tale immagine nella specifica del cluster. Per il valore distribution.version, è possibile immettere il nome completo dell'immagine o, se è stato mantenuto il formato del nome dalla directory di immagine, è possibile abbreviarlo alla versione di Kubernetes. Se si desidera utilizzare un numero di versione completo, sostituire ----- con +. Ad esempio, se si dispone di un'immagine OVA denominata photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a, i seguenti formati sono accettabili.

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"]