L'API déclarative du Service Tanzu Kubernetes Grid expose plusieurs paramètres pour la configuration des clusters Tanzu Kubernetes. Reportez-vous à la liste et à la description de tous les paramètres et directives d'utilisation pour provisionner et personnaliser vos clusters.
YAML annoté pour le provisionnement d'un cluster Tanzu Kubernetes
Le YAML annoté répertorie tous les paramètres disponibles pour le provisionnement d'un cluster
Tanzu Kubernetes avec des commentaires résumés pour chaque champ.
Note : Le YAML annoté n'est pas validé pour le provisionnement d'un cluster. Reportez-vous aux exemples suivants :
Exemples de provisionnement de clusters Tanzu Kubernetes à l'aide de l'API v1alpha1 du Service Tanzu Kubernetes Grid.
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>
Paramètres de provisionnement de clusters Tanzu Kubernetes
Le tableau répertorie et décrit tous les paramètres et valeurs acceptables pour le provisionnement d'un cluster Tanzu Kubernetes. Pour consulter des exemples, reportez-vous à la section Exemples de configuration de l'API v1alpha1 du Service Tanzu Kubernetes Grid.
| Nom | Valeur | Description |
|---|---|---|
apiVersion |
run.tanzu.vmware.com/v1alpha1 |
Spécifie la version de l'API du service Tanzu Kubernetes Grid. |
kind |
TanzuKubernetesCluster |
Spécifie le type de ressource Kubernetes à créer. La seule valeur autorisée est TanzuKubernetesCluster (sensible à la casse). |
metadata |
Section pour les métadonnées de cluster | Inclus des métadonnées de cluster, telles que name et namespace. Il s'agit de métadonnées Kubernetes standard. vous pouvez donc utiliser generateName au lieu de name, ajouter des étiquettes et des annotations, etc. |
name |
Chaîne définie par l'utilisateur qui accepte des caractères alphanumériques et des tirets (par exemple : my-tkg-cluster-1) |
Spécifie le nom du cluster à créer. Contraintes actuelles de dénomination des clusters :
|
namespace |
Chaîne définie par l'utilisateur qui accepte des caractères alphanumériques et des tirets (par exemple : my-sns-1) |
Identifie le nom de l'espace de noms de superviseur dans lequel le cluster sera déployé. Il s'agit d'une référence à un espace de noms de superviseur qui existe sur le cluster superviseur. |
spec |
Section pour les spécifications techniques du cluster | Inclut la spécification, exprimée de manière déclarative, pour l'état final du cluster, y compris le nœud toplogy et la distribution logicielle Kubernetes. |
distribution |
Section pour spécifier la version de Tanzu Kubernetes | Indique la distribution du cluster : le cluster Tanzu Kubernetes logiciel installé sur le plan de contrôle et les nœuds worker, y compris Kubernetes lui-même. |
version |
Chaîne alphanumérique avec des tirets qui représente la version de Kubernetes (par exemple : v1.20.2 ou v1.20) |
Spécifie la version logicielle de la distribution Kubernetes à installer sur les nœuds de cluster à l'aide de la notation de version sémantique. Peut spécifier la version complète ou utiliser des raccourcis de version, tels que « version: v1.20.2 », qui est résolue en l'image la plus récente correspondant à cette version de correctif, ou « version: v1.20 », qui est résolue en la version de correctif correspondante la plus récente. La version résolue s'affiche sous la forme « fullVersion » dans la description du cluster une fois que vous l'avez créée. |
topology |
Section pour les topologies de nœud de cluster | Inclut des champs qui décrivent le nombre, l'objet et l'organisation des nœuds de cluster, ainsi que les ressources allouées à chacun d'entre eux. Les nœuds de cluster sont regroupés en pools en fonction de leur rôle prévu : control-plane ou worker. Chaque pool est homogène, disposant de la même allocation de ressources et utilisant le même stockage. |
controlPlane |
Section pour les paramètres du plan de contrôle | Spécifie la topologie du plan de contrôle du cluster, y compris le nombre de nœuds (count), le type de machine virtuelle (class) et les ressources de stockage allouées pour chaque nœud (storageClass). |
count |
Un nombre entier, soit 1 ou 3 |
Spécifie le nombre de nœuds du plan de contrôle. Le plan de contrôle doit avoir un nombre impair de nœuds. |
class |
Un élément défini par le système sous la forme d'une chaîne provenant d'un ensemble énuméré (par exemple : guaranteed-small ou best-effort-large) |
Spécifie le nom de la classe VirtualMachineClass qui décrit les paramètres de matériel virtuel à utiliser pour chaque nœud du pool. Cela contrôle le matériel disponible pour le nœud (CPU et mémoire), ainsi que les demandes et les limites de ces ressources. Reportez-vous à la section Classes de machine virtuelle pour des clusters Tanzu Kubernetes. |
storageClass |
node-storage (par exemple) |
Identifie la classe de stockage à utiliser pour le stockage des disques qui stockent les systèmes de fichiers racine des nœuds du plan de contrôle. Exécutez kubectl describe ns sur l'espace de noms pour afficher les classes de stockage disponibles. Les classes de stockage disponibles pour l'espace de noms dépendent du stockage défini par l'administrateur vSphere. Les classes de stockage associées à l'espace de noms de superviseur sont répliquées dans le cluster. En d'autres termes, la classe de stockage doit être disponible dans l'espace de noms de superviseur afin d'être une valeur valide pour ce champ. Reportez-vous à la section Configuration et gestion des espaces de noms vSphere. |
volumes |
Paramètre de stockage facultatif
|
Peut spécifier des paramètres de disque et de stockage séparés pour etcd sur les nœuds de plan de contrôle. Reportez-vous à l'exemple Cluster avec des disques séparés et paramètres de stockage. |
workers |
Section pour les paramètres du nœud worker | Spécifie la topologie des nœuds worker du cluster, y compris le nombre de nœuds (count), le type de machine virtuelle (class) et les ressources de stockage allouées pour chaque nœud (storageClass). |
count |
Un nombre entier compris entre 0 et 150 (par exemple : 1, 2 ou 7) |
Spécifie le nombre de nœuds worker dans le cluster. Un cluster sans nœud worker peut être créé, ce qui permet d'utiliser un cluster avec des nœuds de plan de contrôle uniquement. Il n'y a pas de valeur maximale fixe pour le nombre de nœuds worker, mais 150 est une limite raisonnable.
Note : Aucun service d'équilibrage de charge n'est attribué à un cluster provisionné avec 0 nœud worker.
|
class |
Un élément défini par le système sous la forme d'une chaîne provenant d'un ensemble énuméré (par exemple : guaranteed-small ou best-effort-large) |
Spécifie le nom de la classe VirtualMachineClass qui décrit les paramètres de matériel virtuel à utiliser pour chaque nœud du pool. Cela contrôle le matériel disponible pour le nœud (CPU et mémoire), ainsi que les demandes et les limites de ces ressources. Reportez-vous à la section Classes de machine virtuelle pour des clusters Tanzu Kubernetes. |
storageClass |
node-storage (par exemple) |
Identifie la classe de stockage à utiliser pour le stockage des disques qui stockent les systèmes de fichiers racine des nœuds worker. Exécutez kubectl describe ns sur l'espace de noms pour répertorier les classes de stockage disponibles. Les classes de stockage disponibles pour l'espace de noms dépendent du stockage défini par l'administrateur vSphere. Les classes de stockage associées à l'espace de noms de superviseur sont répliquées dans le cluster. En d'autres termes, la classe de stockage doit être disponible sur l'espace de noms de superviseur pour être valide. Reportez-vous à la section Configuration et gestion des espaces de noms vSphere. |
volumes |
Paramètre de stockage facultatif
|
Peut spécifier des paramètres de disque et de stockage séparés pour les images de conteneur sur les nœuds Worker. Reportez-vous à l'exemple Cluster avec des disques séparés et paramètres de stockage. |
settings |
Section pour les paramètres spécifiques au cluster. Tous les paramètres spec.settings sont facultatifs. |
Identifie les informations de configuration d'exécution facultatives pour le cluster, notamment les détails du nœud network et le storage persistant pour les espaces. |
storage |
Section pour spécifier le stockage | Identifie les entrées de stockage du volume persistant (PV) pour les charges de travail de conteneur. |
classes |
Baie d'une ou de plusieurs chaînes définies par l'utilisateur (par exemple : ["gold", "silver"]) |
Spécifie les classes de stockage du volume persistant (PV) nommé pour les charges de travail de conteneur. Les classes de stockage associées à l'espace de noms de superviseur sont répliquées dans le cluster. En d'autres termes, la classe de stockage doit être disponible dans l'espace de noms de superviseur pour être une valeur valide. Reportez-vous à l'exemple Cluster avec classes de stockage et classe par défaut pour les volumes persistants. |
defaultClass |
silver (par exemple) |
Spécifie une classe de stockage nommée à annoter comme valeur par défaut dans le cluster. Si vous ne la spécifiez pas, aucune valeur par défaut n'est définie. Vous n'avez pas à spécifier une ou plusieurs classes pour spécifier une defaultClass. Certaines charges de travail peuvent nécessiter une classe par défaut, telle que Helm. Reportez-vous à l'exemple Cluster avec classes de stockage et classe par défaut pour les volumes persistants. |
network |
Marqueur de section pour les paramètres de mise en réseau | Spécifie les paramètres liés au réseau pour le cluster. |
cni |
Marqueur de section pour spécifier le CNI | Identifie le plug-in Container Networking Interface (CNI) pour le cluster. La valeur par défaut est Antrea, ce qui n'a pas besoin d'être spécifié pour les nouveaux clusters. |
name |
Chaîne antrea ou calico |
Spécifie le plug-in CNI à utiliser. Antrea et Calico sont pris en charge. La configuration système définit Antrea comme CNI par défaut. Le CNI par défaut peut être modifié. Si vous utilisez la valeur par défaut, ce champ n'a pas à être spécifié. |
services |
Marqueur de section pour spécifier des sous-réseaux de services Kubernetes | Identifie les paramètres réseau des services Kubernetes. La valeur par défaut est 10.96.0.0/12. |
cidrBlocks |
Groupe ["198.51.100.0/12"] (par exemple) |
Spécifie une plage d'adresses IP à utiliser pour les services Kubernetes. La valeur par défaut est 10.96.0.0/12. Celle-ci ne doit pas se chevaucher avec les paramètres choisis pour le cluster superviseur. Bien que ce champ soit un groupe, ce qui permet d'utiliser plusieurs plages, une seule plage d'adresses IP est actuellement autorisée. Reportez-vous aux exemples de mise en réseau dans la section Exemples de provisionnement de clusters Tanzu Kubernetes à l'aide de l'API v1alpha1 du Service Tanzu Kubernetes Grid. |
pods |
Marqueur de section pour spécifier les sous-réseaux des groupes Kubernetes | Spécifie les paramètres réseau pour les espaces. La valeur par défaut est 192.168.0.0/16. La taille de bloc minimale est de /24. |
cidrBlocks |
Groupe ["192.0.2.0/16"] (par exemple) |
Spécifie une plage d'adresses IP à utiliser pour les espaces Kubernetes. La valeur par défaut est 192.168.0.0/16. Celle-ci ne doit pas se chevaucher avec les paramètres choisis pour le cluster superviseur. La taille du sous-réseau d'espaces doit être supérieure ou égale à /24. Bien que ce champ soit un groupe, ce qui permet d'utiliser plusieurs plages, une seule plage d'adresses IP est actuellement autorisée. Reportez-vous aux exemples de mise en réseau dans la section Exemples de provisionnement de clusters Tanzu Kubernetes à l'aide de l'API v1alpha1 du Service Tanzu Kubernetes Grid. |
serviceDomain |
"cluster.local" |
Spécifie le domaine de service pour le cluster. La valeur par défaut est cluster.local. |
proxy |
Section qui spécifie la configuration du proxy HTTP(S) pour le cluster. Si implémenté, tous les champs sont requis. | Fournit des champs pour les paramètres de proxy spécifiés. Ils seront remplis automatiquement si un proxy global est configuré et qu'aucun proxy de cluster individuel n'est configuré. Reportez-vous à l'exemple Cluster avec un serveur proxy. |
httpProxy |
http://<user>:<pwd>@<ip>:<port> |
Spécifie une URL proxy à utiliser pour établir des connexions HTTP en dehors du cluster. |
httpsProxy |
http://<user>:<pwd>@<ip>:<port> |
Spécifie une URL proxy à utiliser pour établir des connexions HTTPS en dehors du cluster. |
noProxy |
Groupe de blocs CIDR à ne pas mettre en proxy. Par exemple : Obtenez les valeurs requises à partir du réseau de charge de travail sur le cluster superviseur : Reportez-vous à l'image ci-dessous pour savoir quelles valeurs inclure dans le champ de groupe |
Vous ne devez pas proxyer les sous-réseaux utilisés par le réseau de charge de travail sur le cluster superviseur pour les groupes, l'entrée et la sortie. Vous n'avez pas besoin d'inclure les CIDR de services du cluster superviseur dans le champ Les points de terminaison Les CIDR d'espace et de service pour les clusters Tanzu Kubernetes sont automatiquement mis hors proxy. Vous n'avez pas besoin de les ajouter au champ Reportez-vous à l'exemple Cluster avec un serveur proxy. |
trust |
Marqueur de section pour les paramètres trust. |
N'accepte aucune donnée. |
additionalTrustedCAs |
Accepte un groupe de certificats avec name et data pour chacun d'eux. |
N'accepte aucune donnée. |
name |
String | Nom du certificat TLS. |
data |
String | Chaîne codée en base64 d'un certificat public codé en PEM. |
Obtenez les valeurs noProxy requises dans Réseau de charge de travail sur le Cluster superviseur comme indiqué dans l'image.
