Visualizzazione e aggiornamento della configurazione del pacchetto gestito automaticamente

Questo argomento illustra come visualizzare, personalizzare e risolvere i problemi relativi alla configurazione dei pacchetti gestiti automaticamente installati dal repository tanzu-core. Sono inoltre elencate le impostazioni di configurazione di Antrea, Pinniped, Calico, vSphere CPI e vSphere CSI che è possibile personalizzare.

Alcune delle procedure descritte in questo argomento utilizzano imgpkg. Per informazioni su come scaricare e installare imgpkg, vedere Installazione degli strumenti Carvel.

Visualizzazione della configurazione del pacchetto

I pacchetti gestiti automaticamente, che si trovano nel repository tanzu-core, contengono componenti che supportano le funzionalità del cluster di base, come l'interfaccia di rete del container Antrea o Calico e il componente di autenticazione Pinniped. In alcuni casi, le risorse di Tanzu Kubernetes Grid e Kubernetes interne fanno riferimento a questi componenti come addons.

Per visualizzare la configurazione di un pacchetto gestito automaticamente e del componente aggiuntivo che contiene, è possibile:

Recuperare il segreto di Kubernetes per il componente aggiuntivo installato eseguendo il comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE per il cluster di gestione. In cui:
- CLUSTER-NAME è il nome del cluster di destinazione. Se si desidera recuperare il segreto per il componente aggiuntivo installato in un cluster del carico di lavoro, CLUSTER-NAME è il nome del cluster del carico di lavoro.
- PACKAGE-NAME è il nome del pacchetto.
- CLUSTER-NAMESPACE è lo spazio dei nomi del cluster di destinazione.
Scaricare i file di configurazione del pacchetto da projects.registry.vmware.com/tkg/packages/core.

Ad esempio, per visualizzare la configurazione di Antrea:

Recuperare il segreto di Antrea eseguendo il comando seguente per il cluster di gestione:
```
kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE
```
Scaricare i file di configurazione del pacchetto Antrea:
1. Individuare il tag della versione per antrea nella versione di Tanzu Kubernetes (TKr) utilizzata per creare il cluster. È possibile recuperare il TKr eseguendo il comando kubectl get tkr per il cluster di gestione:
  1. eseguire kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels.
  2. Nell'output, individuare il valore di tanzuKubernetesRelease. Ad esempio, tanzuKubernetesRelease=v1.26.8---vmware.2-tkg.1.
  3. Eseguire kubectl get tkr TKR-VERSION, in cui TKR-VERSION è il valore recuperato in precedenza. Ad esempio:
```
kubectl get tkr v1.26.8---vmware.2-tkg.1 -o yaml
```
  4. Nell'output, individuare il tag della versione in packages/core/antrea.
2. Scaricare i file di configurazione del pacchetto. Ad esempio:
```
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.11.2_vmware.1-tkg.1-advanced -o antrea
```
3. Passare a antrea ed esaminare i file.

Per ulteriori informazioni sulle funzionalità di rete dei container Antrea, vedere le Note di rilascio di VMware Container Networking con Antrea 1.7.0.

Per ulteriori informazioni sull'integrazione di un cluster di container Antrea con VMware NSX, vedere Integrazione di cluster Kubernetes con CNI di Antrea.

Personalizzazione della configurazione del pacchetto

Poiché i pacchetti gestiti automaticamente vengono gestiti da Tanzu Kubernetes Grid, in genere non è necessario personalizzare la configurazione dei pacchetti gestiti automaticamente nei cluster del carico di lavoro.

Ma è possibile personalizzare queste impostazioni, se necessario. La modalità di personalizzazione delle impostazioni dei pacchetti gestiti automaticamente dipende dal tipo di cluster.

Per i cluster basati sul piano o su TKC, è possibile modificare la sezione values.yaml del segreto del componente o applicarvi patch per personalizzare singolarmente un cluster esistente, come descritto in Personalizzazione delle impostazioni di values.yaml.

In alcuni casi con i cluster basati sul piano o su TKC, è possibile aggiungere un overlay al segreto di configurazione del pacchetto nel cluster di gestione per personalizzare i cluster prima di crearli, come descritto in Personalizzazione con un overlay.

Per i cluster basati sulla classe, è possibile personalizzare il cluster prima di crearlo creando un manifesto del cluster come nel passaggio 1 del processo in due passaggi descritto in Creazione di un cluster basato sulla classe e quindi aggiungendo una definizione di oggetto personalizzato al manifesto prima di creare il cluster nel passaggio 2. Per un esempio, vedere Personalizzazione di un manifesto basato sulla classe.

Impostazioni di values.yaml dei pacchetti gestiti automaticamente

Nei pacchetti gestiti automaticamente è possibile personalizzare le impostazioni di configurazione seguenti. Questi valori vengono impostati nella sezione values.yaml del segreto del componente del pacchetto:

Pacchetto	Impostazione	Descrizione
Antrea	`antrea.config.defaultMTU`	Il valore predefinito è `null`.
Antrea	`antrea.config.tlsCipherSuites`	Per impostazione predefinita, include pacchetti di crittografia abilitati per FIPS. Per passare agli altri pacchetti di crittografia, aggiornare i valori nel campo `tlsCipherSuites`.
Calico	`calico.config.vethMTU`	L'impostazione predefinita è `“0”`, che fa in modo che Calico rilevi automaticamente le dimensioni di trasmissione massime (MTU). Impostare questo parametro per specificare le dimensioni massime dei pacchetti, in byte, come stringa.
Calico	`calico.config.skipCNIBinaries`	L'impostazione predefinita è `true`, che impedisce a Calico di sovrascrivere le impostazioni dei plug-in CNI esistenti durante la creazione del cluster. Quando si aggiorna un cluster, per evitare la sovrascrittura, impostare `calico.config.skipCNIBinaries=true`.
Pinniped	`pinniped.supervisor_svc_external_dns`	Nome di dominio completo associato a un supervisore Pinniped, utilizzato come URL di callback nel client del provider di identità OIDC. In base al tipo di servizio di Pinniped, potrebbe essere necessario includere anche il numero di porta: Per `LoadBalancer`, in vSphere con NSX ALB, AWS o Azure, non includere il numero di porta: `https://hr.tkg.example.com`. Per `NodePort`, come in vSphere senza NSX ALB, includere il numero di porta: `https://hr.tkg.example.com:31234`.
Pinniped	`pinniped.upstream_oidc_client_id`	ID client del provider OIDC.
Pinniped	`pinniped.upstream_oidc_client_secret`	Segreto client del provider OIDC.
Pinniped	`pinniped.upstream_oidc_issuer_url`	URL del provider OIDC.
Pinniped	`pinniped.upstream_oidc_tls_ca_data`	Dati del bundle CA con codifica base64 utilizzati per verificare le connessioni TLS al provider OIDC.
Pinniped	`pinniped.upstream_oidc_additional_scopes`	Elenco di ambiti aggiuntivi da richiedere nella risposta del token.
Pinniped	`pinniped.upstream_oidc_claims`	Mappatura della richiesta OIDC.
vSphere CSI	`vsphereCSI.provisionTimeout`	Il valore predefinito è `300s`.
vSphere CSI	`vsphereCSI.attachTimeout`	Il valore predefinito è `300s`.
vSphere CSI	`vsphereCSI.netPermissions`	Il valore predefinito è `null`.

Personalizzazione delle impostazioni di values.yaml

Per personalizzare la sezione values.yaml del segreto di un componente aggiuntivo in un cluster basato su piano o su TKC già in esecuzione:

Recuperare il segreto eseguendo il comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE per il cluster di gestione. Ad esempio:

kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

Aggiornare la sezione values.yaml. È possibile aggiornare qualsiasi valore elencati nella tabella precedente.

Applicare l'aggiornamento codificando in base64 il file values.yaml e sostituendolo nel segreto del cluster. Questo comando varia in base al sistema operativo del proprio ambiente. Ad esempio:

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

Dopo aver aggiornato il segreto, controllare lo stato del pacchetto eseguendo il comando kubectl get packageinstall. Ad esempio:

$ 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

Se lo stato restituito è Reconcile failed, eseguire il comando seguente per visualizzare i dettagli dell'errore:

kubectl get packageinstall antrea -n tkg-system -o yaml

Eseguire il comando kubectl get app. Ad esempio:

$ kubectl get app antrea -n tkg-system
NAME           DESCRIPTION             SINCE-DEPLOY    AGE
antrea         Reconcile succeeded     3m23s           7h50m

Se lo stato restituito è Reconcile failed, eseguire il comando seguente per visualizzare i dettagli dell'errore:

kubectl get app antrea -n tkg-system -o yaml

L'esempio seguente aggiorna l'unità massima di trasmissione (MTU) predefinita per Antrea.

stringData:
  values.yaml: |
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    infraProvider: vsphere
    antrea:
      config:
        defaultMTU: 8900

Nota
Assicurarsi di configurare le stesse impostazioni MTU per tutti i nodi di un cluster. Le impostazioni del firewall devono consentire i pacchetti delle dimensioni di MTU configurate. Per risolvere eventuali problemi causati da impostazioni MTU diverse nei nodi di un cluster, vedere Nodi worker del cluster in stato NotReady a causa di MTU non corrispondenti.

Personalizzazione con un overlay

In alcuni casi, è possibile aggiungere un overlay al segreto del componente aggiuntivo per personalizzare la configurazione del pacchetto gestito automaticamente dei cluster basati sul piano o su TKC prima che vengano creati.

L'esempio seguente indica a Pinniped di utilizzare il tipo di servizio LoadBalancer anziché NodePort, che è il valore predefinito in vSphere quando NSX Advanced Load Balancer (ALB) non funge da endpoint del piano di controllo:

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

Per aggiungere un overlay:

Recuperare il segreto eseguendo il comando kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE per il cluster di gestione. Ad esempio:

kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml

Aggiungere la sezione overlays.yaml in stringData.

Applicare l'aggiornamento codificando in base64 il file values.yaml e sostituendolo nel segreto del cluster. Questo comando varia in base al sistema operativo del proprio ambiente. Ad esempio:

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

Dopo aver aggiornato il segreto, controllare lo stato del pacchetto eseguendo i comandi kubectl get packageinstall e kubectl get app come descritto in Impostazioni di values.yaml dei pacchetti gestiti automaticamente.

Personalizzazione di un manifesto basato sulla classe

Ad esempio, per personalizzare il valore netPermissions per vSphere CSI, modificare il manifesto generato con tanzu cluster create --dry-run aggiungendo un blocco netPermissions come il seguente nel blocco della definizione spec.vsphereCSI dell'oggetto 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

In cui:

PERM-* è un nome che si assegna alla sezione delle impostazioni delle autorizzazioni, che viene convertito in [NetPermissions "PERM-1"] e così via nel segreto della configurazione di vSphere.
Il valore ips: rappresenta gli intervalli di indirizzi per i volumi di file per cui la sezione imposta le autorizzazioni.
Il valore permissions: rappresenta le autorizzazioni impostate per tale sezione.

Dopo aver modificato il manifesto, è possibile creare il cluster eseguendo il passaggio 2 in Creazione di un cluster basato sulla classe.

Risoluzione dei problemi della configurazione del pacchetto

Per risolvere i problemi relativi alle configurazioni dei pacchetti gestiti automaticamente in un cluster, rivedere e modificare la risorsa personalizzata (CR) PackageInstall e il componente Secret del pacchetto.

Per applicare modifiche temporanee alla configurazione del pacchetto, potrebbe essere necessario sospendere la riconciliazione degli oggetti PackageInstall e Secret come descritto in Sospensione della gestione del ciclo di vita per un pacchetto gestito automaticamente di seguito. Questa procedura disattiva la gestione del ciclo di vita per il pacchetto e deve essere utilizzata con cautela.

Termini chiave

Tanzu Kubernetes Grid utilizza le risorse seguenti per gestire il ciclo di vita dei pacchetti gestiti automaticamente.

Componenti installati nel cluster di gestione:

kapp-controller un gestore di pacchetti locale: Quando si distribuisce un cluster di gestione, la CLI di Tanzu installa kapp-controller nel cluster. kapp-controller installa tanzu-addons-manager e altri pacchetti gestiti automaticamente. Inoltre, installa e gestisce kapp-controller in ogni cluster del carico di lavoro distribuito da tale cluster di gestione.
tanzu-addons-manager: Gestisce i componenti aggiuntivi installati, come pacchetti gestiti automaticamente, nel cluster di gestione e nei cluster del carico di lavoro distribuiti dal cluster di gestione.
tkr-controller: Crea ConfigMap di TKr e BoM nel cluster di gestione.

Componente installato nei cluster del carico di lavoro:

kapp-controller installa pacchetti gestiti automaticamente nel cluster del carico di lavoro in cui viene eseguito.

Oggetti:

Secret: la CLI di Tanzu crea un Secret per ogni componente aggiuntivo, per ogni cluster. Questi segreti definiscono la configurazione dei componenti aggiuntivi. tanzu-addons-manager legge i segreti e utilizza le informazioni di configurazione che contengono per configurare i componenti aggiuntivi. Tutti i segreti vengono creati nel cluster di gestione.
Risorsa personalizzata (CR) PackageRepository: tanzu-addons-manager crea una risorsa personalizzata (CR) PackageRepository che fa riferimento a tutte le risorse personalizzate (CR) Package dei componenti aggiuntivi (vedere di seguito).
Risorsa personalizzata (CR) Package: per ogni componente aggiuntivo in PackageRepository, kapp-controller crea una risorsa personalizzata (CR) Package nel cluster di destinazione.
Risorsa personalizzata (CR) PackageInstall: per ogni componente aggiuntivo Package, tanzu-addons-manager crea una risorsa personalizzata (CR) PackageInstall nel cluster di destinazione per informare kapp-controller sui pacchetti gestiti automaticamente che deve installare.
Risorsa personalizzata (CR) App: per ogni PackageInstall, kapp-controller crea una risorsa personalizzata (CR) App nel cluster di destinazione. Quindi, kapp-controller riconcilia la risorsa personalizzata (CR) e installa il pacchetto.
ConfigMap BoM: fornisce informazioni sui metadati dei componenti aggiuntivi, ad esempio la posizione dell'immagine, a tanzu-addons-manager.

È possibile utilizzare i comandi seguenti per monitorare lo stato di queste risorse:

Comando	Descrizione
`kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml`	Controlla la risorsa personalizzata (CR) `PackageInstall` nel cluster di destinazione. Ad esempio, `kubectl get packageinstall antrea -n tkg-system -o yaml`.
`kubectl get app PACKAGE-NAME -n tkg-system -o yaml`	Controlla la risorsa personalizzata (CR) `App` nel cluster di destinazione. Ad esempio, `kubectl get app antrea -n tkg-system -o yaml`.
`kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease}`	Nel cluster di gestione, verifica che l'etichetta TKr del cluster di destinazione punti al TKr corretto.
`kubectl get tanzukubernetesrelease TKR-NAME`	Verifica che il TKr sia presente nel cluster di gestione.
`kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’`	Verifica che la ConfigMap BoM corrispondente al TKr sia presente nel cluster di gestione.
`kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE`	Per i cluster del carico di lavoro, verifica che la risorsa personalizzata (CR) `App` di `kapp-controller` sia presente nel cluster di gestione.
`kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system`	Controlla i registri `tanzu-addons-manager` nel cluster di gestione.
`kubectl get configmap -n tkg-system \| grep ADD-ON-NAME-ctrl`	Verifica che gli aggiornamenti del segreto del componente aggiuntivo siano stati applicati. Il periodo di sincronizzazione è 5 minuti.

Sospensione della gestione del ciclo di vita per un pacchetto gestito automaticamente

Importante
I comandi di questa sezione disattivano la gestione del ciclo di vita del pacchetto. Se possibile, utilizzare invece le procedure descritte nell'argomento precedente Aggiornamento della configurazione del pacchetto.

Se è necessario sospendere temporaneamente la gestione del ciclo di vita per un pacchetto gestito automaticamente, è possibile utilizzare i comandi seguenti:

Per sospendere la riconciliazione del segreto, eseguire il comando seguente nel cluster di gestione:
```
kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge
```
Dopo aver eseguito questo comando, tanzu-addons-manager interrompe la riconciliazione del segreto.
Per sospendere la riconciliazione della risorsa personalizzata (CR) PackageInstall, eseguire il comando seguente nel cluster di destinazione:
```
kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge
```
Dopo aver eseguito questo comando, kapp-controller interrompe la riconciliazione tra PackageInstall e la risorsa personalizzata (CR) App corrispondente.

Se si desidera modificare temporaneamente le risorse di un componente aggiuntivo, sospendere innanzitutto la riconciliazione del segreto e quindi sospendere la riconciliazione della risorsa personalizzata (CR) PackageInstall. Dopo aver ripreso la gestione del ciclo di vita, tanzu-addons-manager e kapp-controller riprendono la riconciliazione del segreto e della risorsa personalizzata (CR) PackageInstall:

Per riprendere la riconciliazione del segreto, rimuovere tkg.tanzu.vmware.com/addon-paused dalle annotazioni del segreto.
Per riprendere la riconciliazione della risorsa personalizzata (CR) PackageInstall, aggiornare la risorsa personalizzata (CR) PackageInstall con {"spec":{"paused":false}} oppure rimuovere la variabile.