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

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.

Certaines procédures de cette rubrique utilisent imgpkg. Pour plus d'informations sur le téléchargement et l'installation de imgpkg, reportez-vous à la section Installer les outils Carvel.

Afficher 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.27.5---vmware.2-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.27.5---vmware.2-tkg.1 -o yaml
```
  4. Dans la sortie, localisez la balise de la version sous packages/core/antrea.
2. Téléchargez les fichiers de configuration du module. Par exemple :
```
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.11.2_vmware.1-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.6.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 Kubernetes à la CNI Antrea.

Personnaliser la configuration du module

É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.

Paramètres values.yaml des modules autogérés

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 : 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.
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.

Personnaliser les paramètres values.yaml

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           1.11.1+vmware.4-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.

Personnaliser avec une superposition

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.

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.

Personnaliser un manifeste basé sur une classe

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.
La valeur ips: correspond aux plages d'adresses des volumes de fichiers pour lesquels la section définit des autorisations.
La valeur 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.

Dépanner la configuration du module

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.

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.