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.
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:
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:
eseguire kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels
.
Nell'output, individuare il valore di tanzuKubernetesRelease
. Ad esempio, tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1
.
Eseguire kubectl get tkr TKR-VERSION
, in cui TKR-VERSION
è il valore recuperato in precedenza. Ad esempio:
kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml
Nell'output, individuare il tag della versione in packages/core/antrea
.
In alternativa, è possibile individuare il tag della versione esaminando il TKr in ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE
.
Scaricare i file di configurazione del pacchetto. Ad esempio:
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea
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.4.0. Per ulteriori informazioni sull'integrazione di un cluster di container Antrea con VMware NSX, vedere Integrazione di cluster di container Antrea.
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.
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:
|
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. |
Pinniped | dex.config.ldap.host * |
Indirizzo IP o DNS del server LDAP. Se si desidera impostare la porta predefinita 636 su una porta diversa, specificare “host:port” . |
Pinniped | dex.config.ldap.bindDN * e dex.config.ldap.BIND_PW_ENV_VAR * |
DN e password per l'account di servizio di un'applicazione. |
Pinniped | dex.config.ldap.userSearch * |
Cercare gli attributi per gli utenti. Per lo schema, vedere la documentazione di Dex. |
Pinniped | dex.config.ldap.groupSearch * |
Cercare gli attributi per i gruppi. Per lo schema, vedere la documentazione di Dex. |
vSphere CSI | vsphereCSI.provisionTimeout |
Il valore predefinito è 300s . |
vSphere CSI | vsphereCSI.attachTimeout |
Il valore predefinito è 300s . |
vSphere CSI | vsphereCSI.netPermissions |
Il valore predefinito è null . |
* Se si desidera aggiornare un'impostazione Pinniped che inizia con dex.
, vedere Aggiornamento delle impostazioni Dex dopo la distribuzione del cluster di gestione.
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 0.13.3+vmware.1-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
NotaAssicurarsi 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.
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.
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.
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.ips:
rappresenta gli intervalli di indirizzi per i volumi di file per cui la sezione imposta le autorizzazioni.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.
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.
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.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).Package
: per ogni componente aggiuntivo in PackageRepository
, kapp-controller
crea una risorsa personalizzata (CR) Package
nel cluster di destinazione.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.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.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. |
ImportanteI 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.