Exemplos para provisionamento de clusters Tanzu Kubernetes usando a API Tanzu Kubernetes Grid Service v1alpha1

A API do Tanzu Kubernetes Grid Service fornece padrões inteligentes e uma matriz de opções para personalizar Tanzu Kubernetes clusters. Consulte os exemplos para provisionar clusters de vários tipos com diferentes configurações e personalizações para atender às suas necessidades.

YAML mínimo para provisionamento de um Tanzu Kubernetes cluster

O exemplo de YAML a seguir é a configuração mínima necessária para invocar o Tanzu Kubernetes Grid Service e provisionar um cluster de Tanzu Kubernetes que usa todas as configurações padrão.

As características do YAML de exemplo mínimo incluem:

A versão Tanzu Kubernetes release, listada como v1.19, é resolvida para a distribuição mais recente correspondente a essa versão secundária, por exemplo, v1.19.7+vmware.1-tkg.1.xxxxxx. Consulte o Lista de Tanzu Kubernetes releases.
A classe de VM best-effort-<size> não tem reservas. Para obter mais informações, consulte Classes de máquina virtual para Tanzu Kubernetes clusters.
O cluster não inclui armazenamento persistente para contêineres. Se necessário, isso é definido em spec.settings.storage. Veja o exemplo de armazenamento abaixo.
Algumas cargas de trabalho, como Helm, podem exigir um spec.settings.storage.defaultClass. Veja o exemplo de armazenamento abaixo.
A seção spec.settings.network não está especificada. Isso significa que o cluster usa as seguintes configurações de rede padrão:
- CNI padrão: antrea
- CIDR do Pod padrão: 192.168.0.0/16
- CIDR de serviços padrão: 10.96.0.0/12
- Domínio de serviço padrão: cluster.local
Observação: O intervalo de IPs padrão para pods é 192.168.0.0/16. Se essa sub-rede já estiver em uso, você deverá especificar um intervalo de CIDR diferente. Veja os exemplos de rede personalizados abaixo.

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 com discos e parâmetros de armazenamento separados

O exemplo de YAML a seguir mostra como provisionar um cluster com discos e parâmetros de armazenamento separados para o plano de controle do cluster e os nós de trabalho.

O uso de discos de separação e parâmetros de armazenamento para dados de alta rotatividade ajuda a minimizar a sobrecarga de leitura / gravação relacionada ao uso de clones vinculados, entre outros benefícios. Existem dois casos de uso principais:

Personalize o desempenho do armazenamento em nós do plano de controle para o banco de dados etcd
Personalize o tamanho do disco para imagens de contêiner nos nós de trabalho

O exemplo tem as seguintes características:

As configurações de spec.topology.controlPlane.volumes especificam o volume separado para o banco de dados etcd.
As configurações de spec.topology.workers.volumes especificam o volume separado para as imagens do contêiner.
O mountPath: /var/lib/containerd para imagens de contêiner é compatível com as versões 1.17 e posteriores do 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 com uma rede Antrea personalizada

O YAML a seguir demonstra como provisionar um cluster Tanzu Kubernetes com intervalos de rede personalizados para o CNI do Antrea.

Como as configurações de rede personalizadas são aplicadas, o parâmetro cni.name é necessário, mesmo que o CNI Antrea padrão seja usado.
- Nome CNI: antrea
- CIDR de Pods Personalizados: 193.0.2.0/16
- CIDR de serviços personalizados: 195.51.100.0/12
- Domínio de serviço personalizado: managedcluster.local
Os blocos CIDR personalizados não podem se sobrepor ao Supervisor Cluster. Para obter mais informações, consulte Parâmetros de configuração para Tanzu Kubernetes clusters usando a API Tanzu Kubernetes Grid Service v1alpha1.

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 com uma rede Calico personalizada

O YAML a seguir demonstra como provisionar um cluster Tanzu Kubernetes com uma rede Calico personalizada.

Calico não é o CNI padrão, portanto, é explicitamente nomeado no manifesto. Para alterar o CNI padrão no nível de serviço, consulte Exemplos de configuração da API do Tanzu Kubernetes Grid Service v1alpha1.
- Nome CNI: calico
- CIDR de Pods Personalizados: 198.51.100.0/12
- CIDR de serviços personalizados: 192.0.2.0/16
- Domínio de serviço personalizado: managedcluster.local
A rede usa intervalos de CIDR personalizados, não os padrões. Esses intervalos não devem se sobrepor ao Supervisor Cluster. Consulte o Parâmetros de configuração para Tanzu Kubernetes clusters usando a API Tanzu Kubernetes Grid Service v1alpha1.

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 com classes de armazenamento e uma classe padrão para volumes persistentes

O exemplo de YAML a seguir demonstra como provisionar um cluster com classes de armazenamento para provisionamento de PVC dinâmico e uma classe de armazenamento padrão.

A configuração spec.settings.storage.classes especifica duas classes de armazenamento para armazenamento persistente para contêineres no cluster.
O spec.settings.storage.defaultClass é especificado. Alguns aplicativos exigem uma classe padrão. Por exemplo, se você quiser usar Helm ou Kubeapps como o defaultClass, que é referenciado por muitos gráficos.

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 com um servidor proxy

Você pode usar um servidor proxy com um cluster Tanzu Kubernetes individual aplicando a configuração do servidor proxy ao manifesto do cluster.

Observe as seguintes características:

A seção spec.settings.network.proxy especifica a configuração do proxy HTTP (s) para este cluster Tanzu Kubernetes.
A sintaxe para ambos os valores de servidor proxy é http://<user>:<pwd>@<ip>:<port>.
Endpoints específicos não são automaticamente colocados em proxy, incluindo localhost e 127.0.0.1, e os CIDRs de Pod e Serviço para clusters Tanzu Kubernetes. Você não precisa incluí-los no campo noProxy.
O campo noProxy aceita uma matriz de CIDRs para não proxy. Obtenha os valores necessários da rede de carga de trabalho no Supervisor Cluster. Consulte a imagem em Parâmetros de configuração para Tanzu Kubernetes clusters usando a API Tanzu Kubernetes Grid Service v1alpha1.
Se um proxy global estiver configurado no TkgServiceConfiguration, essas informações de proxy serão propagadas para o manifesto do cluster após a implantação inicial do cluster. A configuração de proxy global será adicionada ao manifesto do cluster somente se não houver campos de configuração de proxy presentes ao criar o cluster. Em outras palavras, a configuração por cluster tem precedência e substituirá uma configuração de proxy global.

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 com certificados personalizados para TLS

Semelhante a como você pode especificar um trust.additionalTrustedCAs em TkgServiceConfiguration (consulte Parâmetros de configuração para a API do Tanzu Kubernetes Grid Service v1alpha1), você pode incluir trust.additionalTrustedCAs em spec.settings.network na especificação de TanzuKubernetesCluster. Por exemplo:

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 que herda ou não configurações globais da especificação TkgServiceConfiguration

Observação: As configurações de cluster de exemplo a seguir exigem a vCenter Server versão 7.0U2a ou posterior e pelo menos a Supervisor Cluster versão 1.18.10.

Para provisionar um cluster Tanzu Kubernetes que herda uma configuração global do TkgServiceConfiguration, configure o cluster com a configuração global não especificada ou anulada.

Por exemplo, se você quiser configurar um cluster que herde a configuração proxy, poderá usar qualquer uma das seguintes abordagens:

Opção 1: não inclua a configuração proxy na especificação do cluster:

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

Opção 2: incluir a configuração proxy na especificação, mas definir explicitamente seu valor como null:

settings:
  network:
    proxy: null

Para provisionar um cluster de Tanzu Kubernetes que não herda o valor padrão de TkgServiceConfiguration, configure a especificação do cluster com todos os elementos incluídos, mas com valores vazios.

Por exemplo, se o TkgServiceConfiguration tiver um proxy global configurado e você quiser provisionar um cluster que não herde as configurações de proxy globais, inclua a seguinte sintaxe na especificação do cluster:

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

Cluster usando uma biblioteca de conteúdo local

Para provisionar um cluster do Tanzu Kubernetes em um ambiente isolado, crie um cluster usando a imagem da máquina virtual sincronizada de uma biblioteca de conteúdo local.

Para provisionar um cluster usando uma imagem de biblioteca de conteúdo local, você deve especificar essa imagem na especificação do cluster. Para o valor distribution.version, você pode inserir o nome completo da imagem ou, se você mantiver o formato do nome do diretório da imagem, poderá reduzi-lo para a versão do Kubernetes. Se você quiser usar um número de versão totalmente qualificado, substitua ----- por +. Por exemplo, se você tiver uma imagem OVA chamada photon-3-k8s-v1.20.2---vmware.1-tkg.1.1d4f79a, os seguintes formatos serão aceitáveis.

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