Cette rubrique explique comment afficher, personnaliser et dépanner la configuration des modules autogérés installés à partir du référentiel tanzu-core
. Elle répertorie également les paramètres de configuration Antrea, Pinniped, Calico, vSphere CPI et vSphere CSI que vous pouvez personnaliser.
Les modules autogérés, qui se trouvent dans le référentiel tanzu-core
contiennent des composants qui prennent en charge les fonctionnalités de base du cluster, telles que l'interface réseau de conteneur Antrea ou Calico et le composant d'authentification Pinniped. Dans certains cas, les ressources Tanzu Kubernetes Grid et Kubernetes internes font référence à ces composants par addons
.
Pour afficher la configuration d'un module autogéré et du composant complémentaire qu'il contient, vous pouvez effectuer l'opération suivante :
Récupérez le secret Kubernetes pour le composant complémentaire installé en exécutant la commande kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
sur le cluster de gestion. Où :
CLUSTER-NAME
est le nom de votre cluster cible. Si vous souhaitez récupérer le secret du composant complémentaire installé dans un cluster de charge de travail, CLUSTER-NAME
est le nom de votre cluster de charge de travail.PACKAGE-NAME
est le nom du package.CLUSTER-NAMESPACE
est l'espace de noms de votre cluster cible.Téléchargez les fichiers de configuration du module à partir de projects.registry.vmware.com/tkg/packages/core
.
Par exemple, pour afficher la configuration d'Antrea :
Récupérez le secret Antrea en exécutant la commande suivante sur le cluster de gestion :
kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE
Téléchargez les fichiers de configuration du module Antrea :
Localisez la balise de la version pour antrea
dans la version Tanzu Kubernetes (TKr) que vous avez utilisée pour créer le cluster. Vous pouvez récupérer la TKr en exécutant la commande kubectl get tkr
sur le cluster de gestion :
Exécutez kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels
.
Dans la sortie, recherchez la valeur de tanzuKubernetesRelease
. Par exemple, tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1
.
Exécutez kubectl get tkr TKR-VERSION
, où TKR-VERSION
est la valeur que vous avez récupérée ci-dessus. Par exemple :
kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml
Dans la sortie, localisez la balise de la version sous packages/core/antrea
.
Vous pouvez également localiser la balise de la version en examinant la TKr dans ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE
.
Téléchargez les fichiers de configuration du module. Par exemple :
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea
Accédez à antrea
et examinez les fichiers.
Pour en savoir plus sur les fonctionnalités de mise en réseau de conteneurs Antrea, reportez-vous aux Notes de mise à jour de VMware Container Networking avec Antrea 1.4.0. Pour en savoir plus sur l'intégration d'un cluster de conteneurs Antrea à VMware NSX, reportez-vous à la section Intégration des clusters de conteneurs Antrea.
Étant donné que les modules autogérés sont gérés par Tanzu Kubernetes Grid, vous n'avez généralement pas besoin de personnaliser la configuration des modules autogérés dans les clusters de charge de travail.
Mais vous pouvez personnaliser ces paramètres si nécessaire. Le mode de personnalisation des paramètres de modules autogérés dépend du type de cluster.
Pour les clusters basés sur plan ou TKC, vous pouvez modifier et corriger la section values.yaml
du secret du composant pour personnaliser individuellement un cluster existant, comme décrit dans la section Personnaliser les paramètres values.yaml.
Dans certains cas, avec des clusters basés sur un plan ou TKC, vous pouvez ajouter une superposition au secret de la configuration du module dans le cluster de gestion afin de personnaliser les clusters avant de les créer, comme décrit dans la section Personnaliser avec une superposition.
Pour les clusters basés sur une classe, vous pouvez personnaliser le cluster avant de le créer en générant un manifeste de cluster comme à l'étape 1 d'un processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, puis en ajoutant une définition d'objet personnalisée au manifeste avant de créer le cluster à l'étape 2. Pour obtenir un exemple, reportez-vous à la section Personnaliser un manifeste basé sur une classe.
Vous pouvez personnaliser les paramètres de configuration suivants dans les modules gérés automatiquement. Ces valeurs sont définies dans la section values.yaml
du secret du composant de module :
Module | Paramètre | Description |
---|---|---|
Antrea | antrea.config.defaultMTU |
Défini sur null par défaut. |
Antrea | antrea.config.tlsCipherSuites |
Incluez par défaut les suites de chiffrement compatibles FIPS. Pour passer à d'autres suites de chiffrement, mettez à jour les valeurs sous le champ tlsCipherSuites . |
Calico | calico.config.vethMTU |
La valeur par défaut est “0” , ce qui permet à Calico de détecter automatiquement son paramètre de taille de transmission maximale (MTU). Définissez ce paramètre pour spécifier une taille de paquet maximale, en octets, sous forme de chaîne. |
Calico | calico.config.skipCNIBinaries |
La valeur par défaut est true , ce qui empêche Calico de remplacer les paramètres des plug-ins CNI existants lors de la création de clusters. Lorsque vous mettez à niveau un cluster, définissez calico.config.skipCNIBinaries=true pour éviter tout remplacement. |
Pinniped | pinniped.supervisor_svc_external_dns |
Nom de domaine complet associé à un superviseur Pinniped, utilisé comme URL de rappel dans le client IDP OIDC. Selon le type de service de Pinniped, vous devrez peut-être également inclure le numéro de port :
|
Pinniped | pinniped.upstream_oidc_client_id |
ID client de votre fournisseur OIDC. |
Pinniped | pinniped.upstream_oidc_client_secret |
Clé secrète du client de votre fournisseur OIDC. |
Pinniped | pinniped.upstream_oidc_issuer_url |
URL de votre fournisseur OIDC. |
Pinniped | pinniped.upstream_oidc_tls_ca_data |
Données de bundle d'autorité de certification codées en base64 utilisées pour vérifier les connexions TLS à votre fournisseur OIDC. |
Pinniped | pinniped.upstream_oidc_additional_scopes |
Liste de portées supplémentaires à demander dans la réponse du jeton. |
Pinniped | pinniped.upstream_oidc_claims |
Mappage de réclamation OIDC. |
Pinniped | dex.config.ldap.host * |
Adresse IP ou DNS de votre serveur LDAP. Si vous souhaitez remplacer le port 636 par défaut par un port différent, spécifiez “host:port” . |
Pinniped | dex.config.ldap.bindDN * et dex.config.ldap.BIND_PW_ENV_VAR * |
Nom unique et mot de passe d'un compte de service d'application. |
Pinniped | dex.config.ldap.userSearch * |
Recherchez des attributs pour les utilisateurs. Pour le schéma, reportez-vous à la documentation de Dex. |
Pinniped | dex.config.ldap.groupSearch * |
Recherchez des attributs pour les groupes. Pour le schéma, reportez-vous à la documentation de Dex. |
vSphere CSI | vsphereCSI.provisionTimeout |
Défini sur 300s par défaut. |
vSphere CSI | vsphereCSI.attachTimeout |
Défini sur 300s par défaut. |
vSphere CSI | vsphereCSI.netPermissions |
Défini sur null par défaut. |
* Si vous souhaitez mettre à jour un paramètre Pinniped qui commence par dex.
, reportez-vous à la section Mettre à jour les paramètres de Dex après le déploiement du cluster de gestion.
Pour personnaliser la section values.yaml
d'un secret de composant complémentaire dans un cluster basé sur un plan ou TKC déjà en cours d'exécution :
Récupérez le secret en exécutant la commande kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
sur le cluster de gestion. Par exemple :
kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Mettez à jour la section values.yaml
. Vous pouvez mettre à jour n'importe quelle valeur répertoriée dans le tableau ci-dessus.
Appliquez votre mise à jour en codant en base64 le fichier values.yaml
modifié et en le remplaçant dans le secret du cluster. Cette commande diffère selon le système d'exploitation de votre environnement. Par exemple :
Linux :
kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
macOS :
kubectl patch secret/example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
Après avoir mis à jour le secret, vérifiez l'état du module en exécutant la commande kubectl get packageinstall
. Par exemple :
$ kubectl get packageinstall antrea -n tkg-system
NAMESPACE NAME PACKAGE NAME PACKAGE VERSION DESCRIPTION AGE
tkg-system antrea antrea.tanzu.vmware.com 0.13.3+vmware.1-tkg.1 Reconcile succeeded 7d14h
Si l'état renvoyé est Reconcile failed
, exécutez la commande suivante pour obtenir des détails sur l'échec :
kubectl get packageinstall antrea -n tkg-system -o yaml
Exécutez la commande kubectl get app
. Par exemple :
$ kubectl get app antrea -n tkg-system
NAME DESCRIPTION SINCE-DEPLOY AGE
antrea Reconcile succeeded 3m23s 7h50m
Si l'état renvoyé est Reconcile failed
, exécutez la commande suivante pour obtenir des détails sur l'échec :
kubectl get app antrea -n tkg-system -o yaml
L'exemple ci-dessous met à jour l'unité de transmission maximale (MTU) par défaut pour Antrea.
stringData:
values.yaml: |
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
infraProvider: vsphere
antrea:
config:
defaultMTU: 8900
RemarqueAssurez-vous de configurer les mêmes paramètres MTU pour tous les nœuds d'un cluster. Les paramètres de pare-feu doivent autoriser l'utilisation de paquets de la taille de MTU configurée. Pour résoudre les problèmes causés par des paramètres MTU différents sur les nœuds d'un cluster, reportez-vous à la section Nœuds worker du cluster dans l'état NotReady en raison de paramètres MTU discordants.
Dans certains cas, vous pouvez ajouter une superposition au secret du composant complémentaire pour personnaliser la configuration du module autogéré des clusters basés sur un plan ou TKC avant leur création.
L'exemple ci-dessous demande à Pinniped d'utiliser le type de service LoadBalancer
plutôt que NodePort
, qui est la valeur par défaut sur vSphere lorsque NSX Advanced Load Balancer (ALB) ne sert pas de point de terminaison de plan de contrôle :
...
stringData:
overlays.yaml: |
#@ load("@ytt:overlay", "overlay")
#@overlay/match by=overlay.subset({"kind": "Service", "metadata": {"name": "pinniped-supervisor", "namespace": "pinniped-supervisor"}})
---
#@overlay/replace
spec:
type: LoadBalancer
selector:
app: pinniped-supervisor
ports:
- name: https
protocol: TCP
port: 443
targetPort: 8443
values.yaml: |
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
infrastructure_provider: vsphere
tkg_cluster_role: management
Pour ajouter une superposition :
Récupérez le secret en exécutant la commande kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
sur le cluster de gestion. Par exemple :
kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Ajoutez votre section overlays.yaml
sous stringData
.
Appliquez votre mise à jour en codant en base64 le fichier values.yaml
modifié et en le remplaçant dans le secret du cluster. Cette commande diffère selon le système d'exploitation de votre environnement. Par exemple :
Linux :
kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 -w 0 < values.yaml)\"}}" --type=merge
macOS :
kubectl patch secret/example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -p "{\"data\":{\"values.yaml\":\"$(base64 < values.yaml)\"}}" --type=merge
Une fois le secret mis à jour, vérifiez l'état du module en exécutant les commandes kubectl get packageinstall
et kubectl get app
, comme décrit dans la section Paramètres values.yaml des modules autogérés.
Pour les clusters basés sur une classe, vous pouvez personnaliser le cluster avant de le créer en générant un manifeste de cluster comme à l'étape 1 d'un processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, puis en ajoutant une définition d'objet personnalisée au manifeste avant de créer le cluster à l'étape 2.
Par exemple, pour personnaliser la valeur netPermissions
de vSphere CSI, modifiez le manifeste généré avec tanzu cluster create --dry-run
en ajoutant un bloc netPermissions
, tel que le suivant dans le bloc de définition spec.vsphereCSI
de l'objet VSphereCSIConfig
:
apiVersion: csi.tanzu.vmware.com/v1alpha1
kind: VSphereCSIConfig
[...]
spec:
vsphereCSI:
mode: vsphereCSI
config:
[...]
provisionTimeout: 33s
attachTimeout: 77s
resizerTimeout: 99s
netPermissions:
PERM-1:
ips: "*"
permissions: READ_WRITE
rootsquash: false
PERM-2:
ips: "10.20.20.0/24"
permissions: READ_ONLY
rootsquash: true
PERM-3:
ips: "10.30.30.0/24"
permissions: NO_ACCESS
Où :
PERM-*
est un nom que vous attribuez à cette section des paramètres d'autorisation, qui se traduit par [NetPermissions "PERM-1"]
etc. dans le secret de configuration vSphere.ips:
correspond aux plages d'adresses des volumes de fichiers pour lesquels la section définit des autorisations.permissions:
correspond aux autorisations définies pour cette section.Après avoir modifié le manifeste, vous pouvez créer le cluster en suivant l'étape 2 dans la section Créer un cluster basé sur une classe.
Pour dépanner les configurations de modules autogérés dans un cluster, examinez et modifiez la ressource personnalisée (CR) PackageInstall
du module et la valeur Secret
du composant.
Pour appliquer des modifications temporaires à votre configuration de module, vous devrez peut-être suspendre le rapprochement des objets PackageInstall
et Secret
, comme décrit dans la section Suspendre la gestion du cycle de vie d'un module autogéré ci-dessous. Cette procédure désactive la gestion du cycle de vie du module et doit être utilisée avec précaution.
Tanzu Kubernetes Grid utilise les ressources suivantes pour gérer le cycle de vie des modules gérés automatiquement.
Composants installés dans le cluster de gestion :
kapp-controller
, un gestionnaire de modules local : Lorsque vous déployez un cluster de gestion, la CLI Tanzu installe kapp-controller
dans le cluster. kapp-controller
installe tanzu-addons-manager
et d'autres modules autogérés. Il installe et gère également kapp-controller
dans chaque cluster de charge de travail que vous déployez à partir de ce cluster de gestion.tanzu-addons-manager
: Gère les composants complémentaires installés en tant que modules autogérés, dans le cluster de gestion et les clusters de charge de travail que vous déployez à partir de votre cluster de gestion.tkr-controller
: Crée des TKr et des ConfigMaps de nomenclature dans le cluster de gestion.Composant installé dans les clusters de charge de travail :
kapp-controller
installe des modules autogérés dans le cluster de charge de travail dans lequel il s'exécute.
Objets :
Secret
: La CLI Tanzu crée une valeur Secret
pour chaque composant complémentaire, par cluster. Ces secrets définissent la configuration des composants complémentaires. tanzu-addons-manager
lit les secrets et utilise les informations de configuration qu'ils contiennent pour configurer les composants complémentaires. Tous les secrets sont créés dans le cluster de gestion.PackageRepository
: La valeur tanzu-addons-manager
crée une ressource personnalisée PackageRepository
qui fait référence à toutes les ressources personnalisées Package
du composant (voir ci-dessous).Package
: Pour chaque composant complémentaire de la valeur PackageRepository
, kapp-controller
crée une ressource personnalisée Package
dans le cluster cible.PackageInstall
: Pour chaque composant complémentaire Package
, tanzu-addons-manager
crée une ressource personnalisée PackageInstall
dans le cluster cible pour informer kapp-controller
des modules autogérés qu'il doit installer.App
: Pour chaque PackageInstall
, kapp-controller
crée une ressource personnalisée App
dans le cluster cible. Ensuite, kapp-controller
rapproche la ressource personnalisée et installe le module.tanzu-addons-manager
.Vous pouvez utiliser les commandes suivantes pour surveiller l'état de ces ressources :
Commande | Description |
---|---|
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml |
Vérifiez la ressource personnalisée PackageInstall dans votre cluster cible. Par exemple, kubectl get packageinstall antrea -n tkg-system -o yaml . |
kubectl get app PACKAGE-NAME -n tkg-system -o yaml |
Vérifiez la ressource personnalisée App dans votre cluster cible. Par exemple, kubectl get app antrea -n tkg-system -o yaml . |
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} |
Dans le cluster de gestion, vérifiez si l'étiquette TKr de votre cluster cible pointe vers la TKr appropriée. |
kubectl get tanzukubernetesrelease TKR-NAME |
Vérifiez si la TKr est présente dans le cluster de gestion. |
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ |
Vérifiez si la ConfigMap de nomenclature correspondant à votre TKr est présente dans le cluster de gestion. |
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE |
Pour les clusters de charge de travail, vérifiez si la ressource personnalisée kapp-controller App est présente dans le cluster de gestion. |
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system |
Consultez les journaux tanzu-addons-manager dans le cluster de gestion. |
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl |
Vérifiez si vos mises à jour du secret du module complémentaire ont été appliquées. La période de synchronisation est de 5 minutes. |
ImportantLes commandes de cette section désactivent la gestion du cycle de vie des modules. Dans la mesure du possible, utilisez plutôt les procédures décrites dans la section Mise à jour de la configuration des modules ci-dessus.
Si vous devez suspendre temporairement la gestion du cycle de vie d'un module autogéré, vous pouvez utiliser les commandes ci-dessous :
Pour suspendre le rapprochement du secret, exécutez la commande suivante sur le cluster de gestion :
kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge
Lorsque vous exécutez cette commande, tanzu-addons-manager
cesse de rapprocher le secret.
Pour suspendre le rapprochement de la ressource personnalisée PackageInstall
, exécutez la commande suivante sur votre cluster cible :
kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge
Lorsque vous exécutez cette commande, kapp-controller
cesse de rapprocher PackageInstall
et la ressource personnalisée App
correspondante.
Si vous souhaitez modifier temporairement les ressources d'un composant de module complémentaire, suspendez d'abord le rapprochement du secret, puis suspendez le rapprochement de la ressource personnalisée PackageInstall
. Lorsque vous réactivez la gestion du cycle de vie, tanzu-addons-manager
et kapp-controller
reprennent le rapprochement du secret et de la ressource personnalisée PackageInstall
:
Pour reprendre le rapprochement du secret, supprimez tkg.tanzu.vmware.com/addon-paused
des annotations du secret.
Pour reprendre le rapprochement de la ressource personnalisée PackageInstall
, mettez à jour la ressource personnalisée PackageInstall
avec {"spec":{"paused":false}}
ou supprimez la variable.