API de cluster v1beta1

L'API Cluster v1beta1 vous permet de provisionner un cluster en fonction d'une définition ClusterClass par défaut.

API ClusterClass v1beta1

L'API de cluster Kubernetes est une suite d'outils qui fournit le provisionnement, la mise à niveau et l'exploitation déclaratifs des clusters Kubernetes. ClusterClass est une évolution de l'API du cluster qui vous permet de définir des modèles pour la gestion du cycle de vie des ensembles de clusters. Service TKG prend en charge ClusterClass à l'aide de l'API v1beta1.

Service TKG est fourni avec une définition ClusterClass par défaut nommée tanzukubernetescluster. La ClusterClass tanzukubernetescluster fournit le modèle de création de cluster à l'aide de l'API v1beta. La ClusterClass tanzukubernetescluster par défaut est disponible dans tous les espaces de noms d'utilisateur. Pour créer un cluster basé sur cette classe ClusterClass, référencez-le dans la spécification du cluster. Reportez-vous aux exemples v1beta pour obtenir des instructions.

ClusterClass tanzubernerescluster par défaut

La classe ClusterClass de cluster tanzukubernetescluster par défaut est immuable. Elle peut être mise à jour avec chaque version du service TKG.

Pour afficher la ClusterClass tanzukubernetescluster par défaut qui est fourni avec votre instance de service TKG, procédez comme suit :

1. Connectez-vous à Superviseur.

   kubectl vsphere login --server=IP-or-FQDN --vsphere-username [email protected]

2. Faites basculer le contexte vers l'Espace de noms vSphere où un cluster TKGS est provisionné.

   kubeclt config use-context VSPEHRE-NS

3. Obtenez la ClusterClass tanzukubernetescluster par défaut.

   kubectl get clusterclass tanzukubernetescluster -o yaml

4. Vous pouvez également écrire la sortie de la ClusterClass par défaut dans un fichier nommé tkc-dcc.yaml.

   kubectl get clusterclass tanzukubernetescluster -o yaml > tkc-dcc.yaml

Variables ClusterClass pour personnaliser un cluster

Vous personnalisez un cluster en fonction de la classe de cluster ClusterClass tanzukubernetescluster à l'aide de variables. Les variables sont définies à l'aide de paires nom-valeurs. La syntaxe doit être conforme au openAPIV3Schema.

Deux variables sont requises pour provisionner un cluster à l'aide de l'API v1beta1 :

• Classe de VM
• Classe de stockage

Des variables supplémentaires sont disponibles pour personnaliser un cluster, telles que :

• Proxy
• Certificats TLS
• Clés SSH

Le tableau suivant répertorie toutes les variables disponibles avec la ClusterClass tanzukubernetescluster par défaut.

Important : Un nom de clé valide doit être composé uniquement de caractères alphanumériques, d'un tiret (tel que key-name), d'un trait de soulignement (tel que KEY_NAME) ou d'un point (tel que key.name). Vous ne pouvez pas utiliser un espace dans un nom de clé.

clusterEncryptionConfigYaml

Utilisez la variable clusterEncryptionConfigYaml pour configurer le chiffrement du cluster.

clusterEncryptionConfigYaml

Chaîne qui est un fichier YAML fournissant des détails de configuration de chiffrement.

Vous pouvez configurer le chiffrement des données dans la base de données etcd à l'aide du module kube-apiserver Encryption Configuration. Reportez-vous à la section Encrypting Secret Data at Rest dans la documentation Kubernetes.

...
    variables:
    #clusterEncryptionConfigYaml specifies the base64 encoded 
    #EncryptionConfiguration YAML
    #the YAML contains a base64 encryption configuration for the cluster identity
    #the key is generated randomly
    - name: clusterEncryptionConfigYaml
      value: string which is name of the EncryptionConfiguration YAML 

controlPlaneCertificateRotation

Utilisez la variable controlPlaneCertificateRotation pour configurer le système afin qu'il effectue une rotation des certificats TLS pour les nœuds de plan de contrôle en déclenchant un déploiement de ces certificats avant leur expiration. La rotation des certificats du plan de contrôle est disponible pour tous les nœuds de plan de contrôle nouveaux et existants.

controlPlaneCertificateRotation

Booléen pour activer la fonctionnalité et le nombre de jours avant l'expiration pour effectuer la rotation des certificats. Pour plus d'informations, reportez-vous à la section Rotation automatique des certificats à l'aide du fournisseur du plan de contrôle Kubeadm.

...
    variables:
    - name: controlPlaneCertificateRotation
      value: 
        activate: true
        daysBefore: 90

Où :

• activate est un booléen permettant d'activer la fonctionnalité. La valeur par défaut est true
• daysBefore correspond à la durée du nombre de jours avant l'expiration. La valeur par défaut est 90 jours et la valeur minimale est 7 jours avant l'expiration.

Note : Cette variable a été mise à jour pour vSphere 8 Update 3 ( Service TKG 3.0).

controlPlaneVolumes

Utilisez la variable controlPlaneVolumes pour configurer des volumes persistants pour les nœuds de plan de contrôle.

controlPlaneVolumes

Groupe facultatif d'objets, chacun d'eux incluant name, storageClass et mountPath, chacun d'eux étant des chaînes, ainsi qu'un objet capacity facultatif qui inclut une chaîne storage.

...
    variables:
      #controlPlaneVolumes is an optional set of PVCs to create and
      #attach to each node
      - name: controlPlaneVolumes
        value:
          #name of the PVC to be used as the suffix (node.name)
          - name: NAME
            #mountPath is the directory where the volume device is mounted
            #takes the form /dir/path
            mountPath: /dir/path
            #storageClass is the storage class to use for the PVC
            storageClass: tkgs-storage-profile
            #capacity is the PVC storage capacity
            capacity:
              #storage sets the capacity for the disk volume
              #if not specified defaults to storageClass capacity
              storage: 4Gi           

defaultRegistrySecret

La variable defaultRegistrySecret configure le registre de conteneur par défaut pour le cluster.

Note : Cette variable est réservée pour être utilisée avec le registre Harbor intégré.

defaultRegistrySecret

Objet qui inclut une clé publique, un nom de certificat et un espace de noms pour le registre de conteneur par défaut.

Si vous activez le registre Harbor intégré sur le Superviseur, la variable defaultRegistrySecret spécifie le certificat du service de registre que le cluster approuve. Le secret du certificat est étiqueté avec managed-by: vmware-vRegistry. Lors de la création du cluster, un certificat de registre par défaut est injecté dans la variable defaultRegistrySecret. Après la création du cluster, vous gérez la rotation des certificats ou toute mise à jour en mettant à jour manuellement la variable.

...
    variables:
    - name: defaultRegistrySecret
      value:
        #data holds the base64 encoded data.ca\.crt content
        #data.ca\.crt is already encoded, so raw cert data is encoded twice
        data: LS0tLS1CRUdJTiBDRVJU...S0tRU5EIENFUlRJRklDQVRFL
        #name specifies the name of the registry cert secret 
        name: harbor-ca-key-pair
        #namespace specifies the ns of the registry cert secret
        namespace: svc-harbor-domain-c9

defaultStorageClass

Utilisez la variable defaultStorageClass pour configurer une classe de stockage par défaut pour le cluster.

defaultStorageClass

Chaîne qui identifie la classe de stockage à utiliser comme classe de stockage par défaut, souvent requise par certaines applications telles que les graphiques Helm et les modules Tanzu.

...
    variables:
    - name: defaultStorageClass
      value: tkg2-storage-profile

extensionCert

Utilisez la variable extensionCert pour configurer un certificat TLS.

extensionCert

Objet contenant un objet contentSecret contenant des chaînes name et key. contentSecret fait référence à un objet secret Kubernetes créé pour un certificat TLS.

...
    variables:
    #extensionCert specifies the cert and key for Extensions Controller
    #self-signed issuer and certificates must be created in advance
    - name: extensionCert
      value: 
        contentSecret:
          #name specifies the name of secret
          name: string
          #key specifies the content of tls\.crt in the secret's data map
          key: string

kubeAPIServerFQDNs

Utilisez la variable kubeAPIServerFQDNs pour configurer un cluster avec un nom de domaine complet.

kubeAPIServerFQDNs

Groupe d'un ou de plusieurs noms de domaine complet (FQDN).

Le certificat d'API Kubernetes généré inclut chacun des noms de domaine complets que vous avez spécifiés dans la variable kubeAPIServerFQDNs. Le système renseigne kubeconfig avec le premier nom de domaine complet de la liste et suppose qu'il peut être résolu. Si vous souhaitez utiliser un nom de domaine complet différent de la liste, vous pouvez modifier manuellement le fichier kubeconfig généré avec le nom de domaine complet souhaité dans la liste de variables.

Reportez-vous à Exemple v1beta1 : cluster avec FQDN pour plus de détails.

nodePoolLabels

Utilisez la variable nodePoolLabels pour configurer des étiquettes pour les nœuds worker.

nodePoolLabels

Groupe d'un ou de plusieurs objets, chaque objet contenant une paire clé/valeur, ces deux éléments étant des chaînes.

Les étiquettes vous permettent d'organiser les objets système en fonction de vos besoins pour faciliter les requêtes et les rapports. Pour plus d'informations sur l'utilisation, reportez-vous à la documentation sur les étiquettes de Kubernetes.

nodePoolTaints

Utilisez la variable nodePoolTaints pour appliquer des rejets aux nœuds worker.

nodePoolTaints

Groupe d'objets, chaque objet contient un taint qui s'applique aux nœuds worker.

Chaque objet taint inclut une key (chaîne), une value (chaîne) et un effect (chaîne). Le système remplit le champ timeAdded lors de la création ou de la mise à jour.

nodePoolVolumes

Utilisez la variable nodePoolVolumes pour spécifier des volumes persistants pour les nœuds de cluster.

nodePoolVolumes

Groupe facultatif d'objets, chacun d'eux incluant name, storageClass et mountPath, chacun d'eux étant des chaînes, ainsi qu'un objet capacity facultatif qui inclut une chaîne storage.

...
    variables:
      #nodePoolVolumes is an optional set of PVCs to create and
      #attach to each node; use for high-churn components like containerd
      - name: nodePoolVolumes
        value: |
          #name of the PVC to be used as the suffix (node.name)
          - name: etcd
            #mountPath is the directory where the volume device is mounted
            #takes the form /dir/path
            mountPath: /var/lib/containerd
            #storageClass is the storage class to use for the PVC
            storageClass: tkgs-storage-profile
            #capacity is the PVC storage capacity
            capacity:
              #storage sets the capacity for the disk volume
              #if not specified defaults to storageClass capacity
              storage: 4Gi           

ntp

Utilisez la variable ntp pour configurer un serveur NTP pour le cluster.

ntp

Chaîne qui est le nom de domaine complet ou l'adresse IP d'un serveur NTP.

La variable NTP spécifie le nom de domaine du serveur NTP, comme indiqué dans l'exemple. Le serveur NTP est injecté dans la variable de cluster lors de la création du cluster. Après la création du cluster, vous gérez la rotation des noms de serveur ou toute mise à jour en mettant à jour manuellement la variable du cluster.

...
    variables:
    - name: ntp
      value: time1.vmware.com

podSecurityStandard

Utilisez la variable podSecurityStandard pour configurer une sécurité de l'espace à l'échelle du cluster.

Note : Il s'agit d'une nouvelle variable pour vSphere 8 Update 3 ( Service TKG 3.0).

podSecurityStandard

Avec TKr v1.26 et versions ultérieures, les restrictions de sécurité de l'espace (PSA) par défaut sont appliquées au niveau de l'espace de noms à l'aide d'étiquettes d'annotation. Reportez-vous à la section Configurer PSA pour TKR 1.25 et versions ultérieures.

Vous pouvez également utiliser la variable podSecurityStandard pour configurer PSA à l'échelle du cluster lorsque vous provisionnez ou mettez à jour un cluster v1beta1.

La variable podSecurityStandard peut être implémentée comme suit :

...
variables:
- name: podSecurityStandard
  value: 
    deactivated: DEACTIVATED
    audit: AUDIT-PROFILE
    enforce: ENFORCE-PROFILE
    warn: WARN-PROFILE
    auditVersion: AUDIT-VERSION
    enforceVersion: ENFORCE-VERSION
    warnVersion: WARN-VERSION
    exemptions: 
      namespaces: [EXEMPT-NS]

Où :

• La valeur de DEACTIVATED est false (par défaut) pour appliquer PSA à l'échelle du cluster et true dans le cas contraire.
• La valeur de *-PROFILE est le profil PSA de chaque mode, qui peut être "privileged", "baseline" ou "restricted" (par défaut).
• La valeur de *-VERSION correspond à la version de Kubernetes pour chaque mode, tel que "v1.26". La valeur de "latest" est la valeur pas défaut.
• La valeur de EXEMPT-NS est une liste d'espaces de noms séparés par des virgules à exclure du contrôle PSA.

Note : Les espaces de noms système sont exclus de la sécurité de l'espace, notamment kube-system, tkg-system et vmware-system-cloud-provider.

Si vous n'implémentez pas la variable podSecurityStandard, le comportement de PSA par défaut est conservé. Si vous incluez la variable podSecurityStandard dans la spécification du cluster, les paramètres de la variable sont appliqués, y compris les valeurs par défaut, sauf si vous les remplacez.

L'exemple suivant indique les valeurs par défaut.

...
    variables:
      - name: podSecurityStandard
        value:
          enforce: "restricted"
          enforce-version: "latest"

L'exemple suivant fournit des journaux d'audit et des avertissements pour identifier les charges de travail qui ne suivent pas les meilleures pratiques actuelles de sécurisation renforcée de l'espace, mais qui appliquent uniquement une stratégie minimalement restrictive (« ligne de base ») qui empêche les escalades de privilèges connus.

...
    variables:
      - name: podSecurityStandard
        value:
          audit: "restricted"
          warn: "restricted"
          enforce: "baseline"

L'exemple suivant applique une stratégie restreinte, sauf sur un espace de noms spécifique.

...
    variables:
      - name: podSecurityStandard
        value:
          audit: "restricted"
          warn: "restricted"
          enforce: "restricted"
          exemptions:
            namesaces: ["privileged-workload-ns"]

L'exemple suivant limite l'application à une version de TKr particulière.

...
variables:
  - name: podSecurityStandard
    value: 
      audit-version: "v1.26"
      warn-version: "v1.26"
      enforce-version: "v1.26"

Pour plus d'informations, reportez-vous à la section Pod Security Standards de la documentation Kubernetes.

proxy

Utilisez la variable proxy pour configurer un serveur proxy pour le cluster.

proxy

Objet avec des paramètres faisant référence à un serveur proxy pour les connexions de cluster sortantes.

Les paramètres proxy requis sont httpProxy, httpsProxy et noProxy. Les trois champs sont requis si vous incluez la variable proxy dans la définition du cluster.

Les champs httpProxy et httpsProxy prennent des valeurs de chaînes faisant référence à l'URI d'un serveur proxy configuré pour gérer les connexions HTTP et HTTPS sortantes à partir du cluster TKG. Vous pouvez vous connecter au serveur proxy à l'aide de HTTP. Les connexions HTTPS ne sont pas prises en charge.

Le champ noProxy est un groupe de chaînes. Procurez-vous les valeurs de noProxy dans le réseau de charge de travail du Superviseur. Vous devez inclure dans le champ noProxy les sous-réseaux Réseau d'espace de noms, Entrée et Sortie.

Vous n'avez pas besoin d'inclure le sous-réseau Services dans le champ noProxy. Le cluster TKG n'interagit pas avec ce sous-réseau.

Vous n'avez pas besoin d'inclure les éléments clusterNetwork.services.cidrBlocks et clusterNetwork.pods.cidrBlocks dans le champ noProxy. Ces points de terminaison ne sont automatiquement mis en proxy pour vous.

Vous n'avez pas besoin d'inclure les éléments localhost et 127.0.0.1 dans le champ noProxy. Ces points de terminaison ne sont automatiquement mis en proxy pour vous.

...
    variables:
    #proxy specifies a proxy server to be used for the cluster
    #if omitted no proxy is configured
    - name: proxy
      value:
        #httpProxy is the proxy URI for HTTP connections
        #to endpoints outside the cluster
        httpProxy: http://<user>:<pwd>@<ip>:<port>
        #httpsProxy is the proxy URL for HTTPS connections 
        #to endpoints outside the cluster
        httpsProxy: http://<user>:<pwd>@<ip>:<port>
        #noProxy is the list of destination domain names, domains, 
        #IP addresses, and other network CIDRs to exclude from proxying
        #must include Supervisor Pod, Egress, Ingress CIDRs
        noProxy: [array of strings, comma-separated]

storageClass

Utilisez la variable storageClass pour configurer une classe de stockage pour le cluster.

storageClass

Chaîne qui est le nom d'un profil de stockage vSphere attribué à l' Espace de noms vSphere dans lequel le cluster TKG est provisionné.

...
    variables:
    - name: storageClass
      value: tkgs-storage-profile 

Utilisez la commande suivante pour répertorier les classes de stockage disponibles :

kubectl describe namespace VSPHERE-NAMESPACE-NAME

Ou, si vous disposez de privilèges d'administrateur vSphere :

kubectl describe storageclasses

storageClasses

Utilisez la variable storageClasses pour configurer un tableau de classes de stockage pour le cluster.

storageClasses

Groupe d'une ou de plusieurs chaînes, chaque chaîne étant le nom d'un profil de stockage vSphere attribué à l' Espace de noms vSphere dans lequel le cluster TKG est provisionné.

...
    variables:
    - name: storageClasses
      value: [tkg2-storage-profile, tkg2-storage-profile-latebinding] 

Utilisez la commande suivante pour répertorier les classes de stockage disponibles :

kubectl describe namespace VSPHERE-NAMESPACE-NAME

Ou, si vous disposez de privilèges d'administrateur vSphere :

kubectl describe storageclasses

TKR_DATA

Utilisez la variable TKR_DATA pour spécifier les informations TKR.

TKR_DATA

Objet que vous utilisez pour spécifier la version de TKR et d'autres informations.

version est une chaîne au format du nom de TKR qui doit être utilisée par les nœuds de cluster.

Seuls les TKR qui ne disposent pas de l'étiquette legacy-tkr sont compatibles avec le superviseur TKG sur vSphere 9. Reportez-vous à la section Utilisation des versions de Kubernetes avec des clusters Service TKG.

Le système d'exploitation par défaut est PhotonOS. Utilisez des annotations pour spécifier la TKR Ubuntu.

trust

Utilisez la variable trust pour spécifier un ou plusieurs certificats d'autorité de certification approuvés pour le cluster.

trust

Objet permettant d'ajouter des certificats TLS au cluster : autorités de certification supplémentaires ou certificats de fin.

La valeur est additionalTrustedCAs, qui est un groupe de chaînes. Par exemple :

#trust-example
    variables:
      - name: trust
        value:
          additionalTrustedCAs:
          - name: additional-ca-1
          - name: additional-ca-2
          - name: additional-ca-N

La valeur de chaque chaîne est le nom défini par l'utilisateur pour le champ de carte de données dans le secret Kubernetes qui contient le certificat d'autorité de certification au format PEM codé en base64 double. Par exemple :

#secret-example
apiVersion: v1
data:
  additional-ca-1: TFMwdExTMUNSGlSzZ3Jaa...VVNVWkpRMEMwdExTMHRDZz09
kind: Secret
metadata:
  name: cluster01-user-trusted-ca-secret
  namespace: tkgs-cluster-ns
type: Opaque

Un cas d'utilisation courant pour la variable d'approbation consiste à intégrer un cluster v1beta1 à un registre de conteneur privé. Reportez-vous à la section Intégrer des clusters de Service TKG avec un registre de conteneur privé.

utilisateur

Utilisez la variable user pour spécifier les informations d'identification de l'utilisateur du cluster.

utilisateur

Objet qui inclut un objet passwordSecret avec des chaînes de nom et de clé et une chaîne sshAuthorizedKey. Vous pouvez utiliser cette variable pour ajouter la clé SSH d'un utilisateur aux nœuds de cluster pour l'accès SSH distant.

La variable Utilisateur spécifie les informations d'identification de connexion SSH, notamment le mot de passe et les clés autorisées. Le nom d'utilisateur par défaut est vmware-system-user. Le mot de passe doit être haché et stocké dans un secret dans le même espace de noms que celui dans lequel le cluster est provisionné. L'objet passwordSecret fait référence à ce secret. Par exemple, sous Linux, vous pouvez générer un hachage sécurisé à l'aide de mkpasswd --method=SHA-512 --rounds=4096. Pour plus d'informations, reportez-vous à la section Including users and groups.

...
    variables:
    #user specifies an authorized user and credentials
    - name: user
      value:
        #passwordSecret is an object that contains a Kubernetes secret and key
        passwordSecret:
          #name specifies the secret name
          name: string
          #key specifies the key value pair in the secret's data map
          key: string
        sshAuthorizedKey: string that is the base64-encoded public key

vmClass

Utilisez la variable vmClass pour configurer la classe de machine virtuelle pour les nœuds du cluster.

vmClass

Chaîne requise qui se mappe au nom d'une classe de machine virtuelle liée à l' Espace de noms vSphere dans lequel le cluster TKG est provisionné.

vmClass est le nom de la classe VirtualMachineClass qui décrit les paramètres de matériel virtuel à utiliser pour les nœuds de cluster. VirtualMachineClass contrôle le CPU et la mémoire disponibles pour le nœud, ainsi que les demandes et limites sur ces ressources. Reportez-vous à la section Utilisation de classes de machines virtuelles avec des clusters de Service TKG.

Vous pouvez uniquement utiliser des classes de machine virtuelle qui sont associées à l' Espace de noms vSphere dans lequel le cluster de services TKG est en cours de provisionnement. Utilisez la commande kubectl get virtualmachineclass pour répertorier les classes liées.

Vous pouvez définir la variable vmClass à différentes portées afin de pouvoir utiliser différentes classes de machine virtuelle pour les nœuds de plan de contrôle et les nœuds worker de pool de nœuds.

Par exemple, ici, une variable vmClass en ligne overrides la variable vmClass principale pour cette topologie de déploiement de machines spécifique.

...
    workers:
      machineDeployments:
      - class: tkg-worker
        name: compute
        replicas: 3
        variables:
          overrides:
          - name: vmClass
            value: guaranteed-large