Afficher et mettre à jour la configuration des modules autogérés

Cette rubrique explique comment afficher la configuration d'un module autogéré installé à 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 mettre à jour après la création d'un cluster. Pour plus d'informations sur le dépannage, reportez-vous à la section Mise à jour et dépannage de la configuration du module ci-dessous.

Affichage de la configuration du module

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 :
1. 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 :
  1. Exécutez kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels.
  2. Dans la sortie, recherchez la valeur de tanzuKubernetesRelease. Par exemple, tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1.
  3. 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
```
  4. 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.
2. 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
```
3. 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.

Mise à jour et dépannage de la configuration du module

Vous pouvez mettre à jour et dépanner la configuration d'un module autogéré en examinant et modifiant les ressources ci-dessous. É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 mettre à jour leur configuration.

Type Ressources Description

Mises à jour de la configuration

Type	Ressources	Description
Mises à jour de la configuration	Valeur `Secret` du composant complémentaire	Pour mettre à jour la configuration par défaut du composant complémentaire installé par un module autogéré, vous pouvez procéder comme suit : Modifiez la section `values.yaml` du secret du composant complémentaire. Pour plus d'informations, reportez-vous à la section Mettre à jour la section values.yaml ci-dessous. Ajoutez une superposition au secret du composant complémentaire. Pour plus d'informations, reportez-vous à la section Ajouter une superposition ci-dessous.
Dépannage	Ressources personnalisée (CR) `PackageInstall` et `Secret` de composant complémentaire	Même chose que ci-dessus. En outre, si vous devez appliquer des modifications temporaires à la configuration de votre module, vous pouvez procéder comme suit : Suspendez le rapprochement `Secret`. Suspendez le rapprochement de la ressource personnalisée `PackageInstall`. Cela désactive la gestion du cycle de vie du module. Soyez prudent lorsque vous l'utilisez. Pour plus d'informations, reportez-vous à la section Suspendre la gestion du cycle de vie d'un module autogéré ci-dessous.

Valeur Secret du composant complémentaire

Pour mettre à jour la configuration par défaut du composant complémentaire installé par un module autogéré, vous pouvez procéder comme suit :

Modifiez la section values.yaml du secret du composant complémentaire. Pour plus d'informations, reportez-vous à la section Mettre à jour la section values.yaml ci-dessous.
Ajoutez une superposition au secret du composant complémentaire. Pour plus d'informations, reportez-vous à la section Ajouter une superposition ci-dessous.

Dépannage

Ressources personnalisée (CR) PackageInstall et Secret de composant complémentaire

Même chose que ci-dessus. En outre, si vous devez appliquer des modifications temporaires à la configuration de votre module, vous pouvez procéder comme suit :

Suspendez le rapprochement Secret.
Suspendez le rapprochement de la ressource personnalisée PackageInstall.

Cela désactive la gestion du cycle de vie du module. Soyez prudent lorsque vous l'utilisez. Pour plus d'informations, reportez-vous à la section Suspendre la gestion du cycle de vie d'un module autogéré ci-dessous.

Pour plus d'informations sur les secrets des composants complémentaires et les ressources personnalisées PackageInstall, reportez-vous à la section Mots-clés.

Mise à jour de la configuration du module

Vous pouvez mettre à jour la configuration par défaut du composant complémentaire installé à partir d'un module autogéré en modifiant la section values.yaml du secret du composant complémentaire ou en ajoutant une superposition au secret. Ces modifications sont permanentes.

Mettre à jour la section values.yaml

Dans la section values.yaml, vous pouvez mettre à jour les paramètres de configuration suivants :

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 : Pour `LoadBalancer`, sur vSphere avec NSX ALB, AWS ou Azure, n'incluez pas le numéro de port : `https://hr.tkg.example.com`. Pour `NodePort`, comme sur vSphere sans NSX ALB, incluez le numéro de port : `https://hr.tkg.example.com:31234`.
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.

^* 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 modifier la section values.yaml d'un secret de composant complémentaire :

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

Remarque
Assurez-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.

Ajouter une superposition

Dans certains cas, vous pouvez ajouter une superposition au secret du composant complémentaire. Cela vous permet de personnaliser la configuration par défaut définie dans les fichiers de configuration du module. 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.

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 Mettre à jour la section values.yaml.

Dépannage de la configuration du module

Avant de dépanner les modules autogérés, consultez les sections suivantes :

Mots-clés ci-dessous.
Mise à jour de la configuration du module ci-dessus.
Suspendre la gestion du cycle de vie d'un module autogéré ci-dessous.

Mots-clés

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.
Ressource personnalisée 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).
Ressource personnalisée Package : Pour chaque composant complémentaire de la valeur PackageRepository, kapp-controller crée une ressource personnalisée Package dans le cluster cible.
Ressource personnalisée 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.
Ressource personnalisée 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.
ConfigMap de nomenclature : Fournit des informations de métadonnées sur les composants complémentaires, telles que l'emplacement de l'image, à 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.

Suspendre la gestion du cycle de vie d'un module autogéré

Important
Les 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.