In diesem Thema wird erläutert, wie Sie die Konfiguration automatisch verwalteter Pakete, die über das tanzu-core
-Repository installiert werden, anzeigen, anpassen und darin enthaltene Fehler beheben. Außerdem werden die Antrea-, Pinniped-, Calico-, vSphere CPI- und vSphere CSI-Konfigurationseinstellungen aufgelistet, die angepasst werden können.
Automatisch verwaltete Pakete im tanzu-core
-Repository enthalten Komponenten, die grundlegende Clusterfunktionen unterstützen, wie z. B. die Antrea- oder Calico-CNI (Container Network Interface, Containernetzwerkschnittstelle) und die Pinniped-Authentifizierungskomponente. In bestimmten Fällen verweisen interne Tanzu Kubernetes Grid- und Kubernetes-Ressourcen auf diese Komponenten als addons
.
So zeigen Sie die Konfiguration eines automatisch verwalteten Pakets und die darin enthaltene Add-On-Komponente an:
Rufen Sie den geheimen Kubernetes-Schlüssel für die installierte Add-On-Komponente ab, indem Sie den Befehl kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
für den Verwaltungscluster ausführen. Dabei gilt:
CLUSTER-NAME
ist der Name des Zielclusters. Wenn Sie den geheimen Schlüssel für die in einem Arbeitslastcluster installierte Add-On-Komponente abrufen möchten, ist CLUSTER-NAME
der Name Ihres Arbeitslastclusters.PACKAGE-NAME
ist der Name des Pakets.CLUSTER-NAMESPACE
ist der Namespace des Zielclusters.Laden Sie die Konfigurationsdateien des Pakets aus projects.registry.vmware.com/tkg/packages/core
herunter.
So zeigen Sie beispielsweise die Antrea-Konfiguration an:
Rufen Sie den geheimen Antrea-Schlüssel ab, indem Sie den folgenden Befehl für den Verwaltungscluster ausführen:
kubectl get secret CLUSTER-NAME-antrea-addon -n CLUSTER-NAMESPACE
Laden Sie die Konfigurationsdateien des Antrea-Pakets herunter:
Suchen Sie nach dem Versions-Tag für antrea
im Tanzu Kubernetes-Release (TKr), die Sie zum Erstellen des Clusters verwendet haben. Sie können das TKr auch abrufen, indem Sie den Befehl kubectl get tkr
für den Verwaltungscluster ausführen:
Führen Sie kubectl get clusters CLUSTER-NAME -n CLUSTER-NAMESPACE --show-labels
aus.
Suchen Sie in der Ausgabe nach dem Wert von tanzuKubernetesRelease
. Beispiel: tanzuKubernetesRelease=v1.23.10---vmware.1-tkg.1
.
Führen Sie kubectl get tkr TKR-VERSION
aus, wobei es sich bei TKR-VERSION
um den oben abgerufenen Wert handelt. Beispiel:
kubectl get tkr v1.23.10---vmware.1-tkg.1 -o yaml
Suchen Sie in der Ausgabe nach dem Versions-Tag unter packages/core/antrea
.
Alternativ können Sie nach dem Versions-Tag suchen, indem Sie das TKr in ~/.config/tanzu/tkg/bom/YOUR-TKR-BOM-FILE
überprüfen.
Laden Sie die Konfigurationsdateien des Pakets herunter. Beispiel:
imgpkg pull -b projects.registry.vmware.com/tkg/packages/core/antrea:v1.2.3_vmware.4-tkg.1-advanced -o antrea
Navigieren Sie zu antrea
und überprüfen Sie die Dateien.
Weitere Informationen zu den Funktionen des Antrea-Container-Netzwerks finden Sie in den Versionshinweisen zu VMware Container Networking mit Antrea 1.4.0. Weitere Informationen zur Integration eines Antrea-Container-Clusters in VMware NSX finden Sie unter Integrieren von Antrea-Container-Clustern.
Da automatisch verwaltete Pakete von Tanzu Kubernetes Grid verwaltet werden, müssen Sie die Konfiguration automatisch verwalteter Pakete in Arbeitslastclustern in der Regel nicht anpassen.
Sie können diese Einstellungen jedoch bei Bedarf anpassen. Die Anpassung automatisch verwalteter Paketeinstellungen richtet sich nach dem Clustertyp.
Für plan- oder TKC-basierte Cluster können Sie den Abschnitt values.yaml
des geheimen Komponentenschlüssels ändern und patchen, um einen vorhandenen Cluster gemäß der Beschreibung unter Anpassen der values.yaml-Einstellungen individuell anzupassen.
In bestimmten Fällen können Sie bei plan- oder TKC-basierten Clustern dem geheimen Schlüssel der Paketkonfiguration im Verwaltungscluster ein Overlay hinzufügen, um Cluster vor deren Erstellung gemäß der Beschreibung unter Anpassen mit einem Overlay anzupassen.
Bei klassenbasierten Clustern können Sie den Cluster vor dessen Erstellung anpassen, indem Sie ein Clustermanifest wie in Schritt 1 eines zweistufigen Prozesses erstellen, der unter Erstellen eines klassenbasierten Clusters beschrieben wird. Fügen Sie dem Manifest dann eine benutzerdefinierte Objektdefinition hinzu, bevor Sie den Cluster in Schritt 2 erstellen. Ein Beispiel finden Sie unter Anpassen eines klassenbasierten Manifests.
Sie können die folgenden Konfigurationseinstellungen in automatisch verwalteten Paketen anpassen. Diese Werte werden im Abschnitt values.yaml
des geheimen Schlüssels der Paketkomponente festgelegt:
Paket | Einstellung | Beschreibung |
---|---|---|
Antrea | antrea.config.defaultMTU |
null ist die Standardeinstellung. |
Antrea | antrea.config.tlsCipherSuites |
Beziehen Sie FIPS-fähige Verschlüsselungs-Suites standardmäßig ein. Für den Wechsel zu anderen Verschlüsselungs-Suites aktualisieren Sie die Werte im Feld tlsCipherSuites . |
Calico | calico.config.vethMTU |
Standardwert ist “0” , wodurch Calico die zugehörige MTU-Einstellung (Maximum Transmission Size, Maximale Übertragungseinheit) automatisch erkennt. Legen Sie diesen Parameter fest, um eine maximale Paketgröße in Byte als Zeichenfolge anzugeben. |
Calico | calico.config.skipCNIBinaries |
Standardwert ist true . Hiermit wird verhindert, dass Calico die Einstellungen vorhandener CNI-Plug-Ins während der Clustererstellung überschreibt. Wenn Sie ein Upgrade eines Clusters durchführen, legen Sie calico.config.skipCNIBinaries=true fest, um ein Überschreiben zu vermeiden. |
Pinniped | pinniped.supervisor_svc_external_dns |
Ein FQDN, der einem Pinniped-Supervisor zugeordnet ist und als Callback-URL im OIDC-IDP-Client verwendet wird. Je nach dem Diensttyp von Pinniped müssen Sie möglicherweise auch die Portnummer angeben:
|
Pinniped | pinniped.upstream_oidc_client_id |
Die Client-ID des OIDC-Anbieters. |
Pinniped | pinniped.upstream_oidc_client_secret |
Der geheime Clientschlüssel des OIDC-Anbieters. |
Pinniped | pinniped.upstream_oidc_issuer_url |
Die URL des OIDC-Anbieters. |
Pinniped | pinniped.upstream_oidc_tls_ca_data |
Die Base64-codierten CA-Paketdaten, die zum Überprüfen der TLS-Verbindungen zum OIDC-Anbieter verwendet werden. |
Pinniped | pinniped.upstream_oidc_additional_scopes |
Eine Liste mit zusätzlichen Geltungsbereichen, die in der Token-Antwort angefordert werden sollen. |
Pinniped | pinniped.upstream_oidc_claims |
OIDC-Beanspruchungszuordnung. |
Pinniped | dex.config.ldap.host * |
Die IP- oder DNS-Adresse Ihres LDAP-Servers. Wenn Sie den Standardport 636 in einen anderen Port ändern möchten, geben Sie “host:port” an. |
Pinniped | dex.config.ldap.bindDN * und dex.config.ldap.BIND_PW_ENV_VAR * |
Der DN und das Kennwort für ein Anwendungsdienstkonto. |
Pinniped | dex.config.ldap.userSearch * |
Suchen Sie nach Attributen für Benutzer. Informationen zum Schema finden Sie in der Dex-Dokumentation. |
Pinniped | dex.config.ldap.groupSearch * |
Suchen Sie nach Attributen für Gruppen. Informationen zum Schema finden Sie in der Dex-Dokumentation. |
vSphere CSI | vsphereCSI.provisionTimeout |
300s ist die Standardeinstellung. |
vSphere CSI | vsphereCSI.attachTimeout |
300s ist die Standardeinstellung. |
vSphere CSI | vsphereCSI.netPermissions |
null ist die Standardeinstellung. |
* Wenn Sie eine Pinniped-Einstellung aktualisieren möchten, die mit dex.
beginnt, finden Sie weitere Informationen unter Aktualisieren der Dex-Einstellungen nach der Bereitstellung des Verwaltungsclusters.
So passen Sie den Abschnitt values.yaml
des geheimen Komponentenschlüssels eines Add-Ons in einem bereits ausgeführten plan- oder TKC-basierten Cluster an:
Rufen Sie den geheimen Schlüssel ab, indem Sie den Befehl kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
für den Verwaltungscluster ausführen. Beispiel:
kubectl get secret example-workload-cluster-antrea-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Aktualisieren Sie den Abschnitt values.yaml
. Sie können alle in der obigen Tabelle aufgeführten Werte aktualisieren.
Wenden Sie Ihr Update an, indem Sie die bearbeitete Datei values.yaml
mit Base64 verschlüsseln und im geheimen Schlüssel des Arbeitslastclusters ersetzen. Dieser Befehl unterscheidet sich je nach dem in Ihrer Umgebung eingesetzten Betriebssystem. Beispiel:
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
Überprüfen Sie nach dem Aktualisieren des geheimen Schlüssels den Status des Pakets, indem Sie den Befehl kubectl get packageinstall
ausführen. Beispiel:
$ 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
Wenn der zurückgegebene Status Reconcile failed
lautet, führen Sie den folgenden Befehl aus, um Details zu dem Fehler abzurufen:
kubectl get packageinstall antrea -n tkg-system -o yaml
Führen Sie den Befehl kubectl get app
aus. Beispiel:
$ kubectl get app antrea -n tkg-system
NAME DESCRIPTION SINCE-DEPLOY AGE
antrea Reconcile succeeded 3m23s 7h50m
Wenn der zurückgegebene Status Reconcile failed
lautet, führen Sie den folgenden Befehl aus, um Details zu dem Fehler abzurufen:
kubectl get app antrea -n tkg-system -o yaml
In folgendem Beispiel wird die Standard-MTU (Maximum Transmission Unit, Maximale Übertragungseinheit) für Antrea aktualisiert.
stringData:
values.yaml: |
#@data/values
#@overlay/match-child-defaults missing_ok=True
---
infraProvider: vsphere
antrea:
config:
defaultMTU: 8900
HinweisStellen Sie sicher, dass Sie dieselben MTU-Einstellungen für alle Knoten in einem Cluster konfigurieren. Die Firewall-Einstellungen müssen Pakete der konfigurierten MTU-Größe zulassen. Informationen zum Beheben von Problemen, die durch unterschiedliche MTU-Einstellungen auf den Knoten in einem Cluster verursacht werden, finden Sie unter Cluster-Worker-Knoten im Status NotReady aufgrund nicht übereinstimmender MTUs.
In bestimmten Fällen können Sie dem geheimen Komponentenschlüssel des Add-Ons ein Overlay hinzufügen, um die automatisch verwaltete Paketkonfiguration plan- oder TKC-basierter Cluster anzupassen, bevor sie erstellt werden.
Im folgenden Beispiel wird Pinniped angewiesen, den Diensttyp LoadBalancer
anstelle von NodePort
zu verwenden. Hierbei handelt es sich um die Standardeinstellung in vSphere, wenn NSX Advanced Load Balancer (ALB) nicht als Steuerungsebenen-Endpoint fungiert:
...
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
So fügen Sie ein Overlay hinzu:
Rufen Sie den geheimen Schlüssel ab, indem Sie den Befehl kubectl get secret CLUSTER-NAME-PACKAGE-NAME-addon -n CLUSTER-NAMESPACE
für den Verwaltungscluster ausführen. Beispiel:
kubectl get secret example-workload-cluster-pinniped-addon -n example-workload-cluster-namespace -o jsonpath="{.data.values\.yaml}" | base64 -d > values.yaml
Fügen Sie den Abschnitt overlays.yaml
unter stringData
hinzu.
Wenden Sie Ihr Update an, indem Sie die bearbeitete Datei values.yaml
mit Base64 verschlüsseln und im geheimen Schlüssel des Arbeitslastclusters ersetzen. Dieser Befehl unterscheidet sich je nach dem in Ihrer Umgebung eingesetzten Betriebssystem. Beispiel:
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
Überprüfen Sie nach dem Aktualisieren des geheimen Schlüssels den Status des Pakets, indem Sie die Befehle kubectl get packageinstall
und kubectl get app
gemäß der Beschreibung unter values.yaml-Einstellungen des automatisch verwalteten Pakets ausführen.
Bei klassenbasierten Clustern können Sie den Cluster vor dessen Erstellung anpassen, indem Sie ein Clustermanifest wie in Schritt 1 eines zweistufigen Prozesses erstellen, der unter Erstellen eines klassenbasierten Clusters beschrieben wird. Fügen Sie dem Manifest dann eine benutzerdefinierte Objektdefinition hinzu, bevor Sie den Cluster in Schritt 2 erstellen.
Um beispielsweise den Wert netPermissions
für vSphere CSI anzupassen, ändern Sie das mit tanzu cluster create --dry-run
erzeugte Manifest, indem Sie einen netPermissions
-Block wie den folgenden zum VSphereCSIConfig
-Objekt im spec.vsphereCSI
-Definitionsblock hinzufügen:
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
Dabei gilt:
PERM-*
ist ein Name, den Sie diesem Abschnitt der Berechtigungseinstellungen zuweisen und der im geheimen vSphere-Konfigurationsschlüssel in [NetPermissions "PERM-1"]
usw. übersetzt wird.ips:
-Wert ist der Adressbereich für die Datei-Volumes, für die im Abschnitt Berechtigungen festgelegt werden.permissions:
-Wert stellt den Berechtigungssatz für diesen Abschnitt dar.Nachdem Sie das Manifest geändert haben, können Sie den Cluster mithilfe von Schritt 2 unter Erstellen eines klassenbasierten Clusters erstellen.
Zur Fehlerbehebung bei der Konfiguration automatisch verwalteter Pakete in einem Cluster überprüfen und ändern Sie die PackageInstall
-CR (Custom Resource, Benutzerdefinierte Ressource) und die Secret
-Komponente des Pakets.
Zum Anwenden temporärer Änderungen auf die Paketkonfiguration müssen Sie möglicherweise den Abgleich der Objekte PackageInstall
und Secret
gemäß der folgenden Beschreibung unter Anhalten der Lebenszyklusverwaltung für ein automatisch verwaltetes Paket anhalten. Da durch dieses Verfahren die Lebenszyklusverwaltung für das Paket deaktiviert wird, sollte es mit Vorsicht eingesetzt werden.
Tanzu Kubernetes Grid verwendet die folgenden Ressourcen, um den Lebenszyklus automatisch verwalteter Pakete zu verwalten.
Im Verwaltungscluster installierte Komponenten:
kapp-controller
, ein lokaler Paketmanager: Wenn Sie einen Verwaltungscluster bereitstellen, wird kapp-controller
von der Tanzu CLI im Cluster installiert. kapp-controller
installiert tanzu-addons-manager
und andere automatisch verwaltete Pakete. Darüber hinaus wird kapp-controller
in jedem Arbeitslastcluster installiert und verwaltet, den Sie über diesen Verwaltungscluster bereitstellen.tanzu-addons-manager
: Verwaltet die Add-On-Komponenten, die als automatisch verwaltete Pakete im Verwaltungscluster und in den Arbeitslastclustern installiert werden, die Sie über Ihren Verwaltungscluster bereitstellen.tkr-controller
: Erstellt TKrs und BoM-ConfigMaps im Verwaltungscluster.In Arbeitslastclustern installierte Komponente:
kapp-controller
installiert automatisch verwaltete Pakete in dem Arbeitslastcluster, in dem er ausgeführt wird.
Objekte:
Secret
: Die Tanzu CLI erstellt einen Secret
für jede Add-On-Komponente pro Cluster. Diese geheimen Schlüssel definieren die Konfiguration der Add-On-Komponenten. tanzu-addons-manager
liest die geheimen Schlüssel und verwendet die darin enthaltenen Konfigurationsinformationen, um die Add-On-Komponenten zu konfigurieren. Alle geheimen Schlüssel werden im Verwaltungscluster erstellt.PackageRepository
-CR: Der tanzu-addons-manager
erstellt eine PackageRepository
-CR, die auf alle Package
-CRs der Add-On-Komponente verweist (siehe unten).Package
-CR: Für jede Add-On-Komponente im PackageRepository
erstellt kapp-controller
eine Package
-CR im Zielcluster.PackageInstall
-CR: Für jede Package
-Add-On-Komponente erstellt tanzu-addons-manager
eine PackageInstall
-CR im Zielcluster, um kapp-controller
darüber zu informieren, welche automatisch verwalteten Pakete installiert werden müssen.App
-CR: Für jede PackageInstall
erstellt kapp-controller
eine App
-CR im Zielcluster. Anschließend gleicht kapp-controller
die CR ab und installiert das Paket.tanzu-addons-manager
Metadateninformationen zu den Add-On-Komponenten bereit, wie z. B. Image-Speicherort.Sie können die folgenden Befehle verwenden, um den Status dieser Ressourcen zu überwachen:
Befehl | Beschreibung |
---|---|
kubectl get packageinstall PACKAGE-NAME -n tkg-system -o yaml |
Überprüfen Sie die PackageInstall -CR in Ihrem Zielcluster. Beispiel: kubectl get packageinstall antrea -n tkg-system -o yaml . |
kubectl get app PACKAGE-NAME -n tkg-system -o yaml |
Überprüfen Sie die App -CR in Ihrem Zielcluster. Beispiel: kubectl get app antrea -n tkg-system -o yaml . |
kubectl get cluster CLUSTER-NAME -n CLUSTER-NAMESPACE -o jsonpath={.metadata.labels.tanzuKubernetesRelease} |
Überprüfen Sie im Verwaltungscluster, ob die TKr-Bezeichnung Ihres Zielclusters auf das richtige TKr verweist. |
kubectl get tanzukubernetesrelease TKR-NAME |
Überprüfen Sie, ob das TKr im Verwaltungscluster vorhanden ist. |
kubectl get configmaps -n tkr-system -l ‘tanzuKubernetesRelease=TKR-NAME’ |
Überprüfen Sie, ob die Ihrem TKr entsprechende BoM-ConfigMap im Verwaltungscluster vorhanden ist. |
kubectl get app CLUSTER-NAME-kapp-controller -n CLUSTER-NAMESPACE |
Überprüfen Sie bei Arbeitslastclustern, ob die kapp-controller -App -CR im Verwaltungscluster vorhanden ist. |
kubectl logs deployment/tanzu-addons-controller-manager -n tkg-system |
Überprüfen Sie die tanzu-addons-manager -Protokolle im Verwaltungscluster. |
kubectl get configmap -n tkg-system | grep ADD-ON-NAME-ctrl |
Überprüfen Sie, ob Ihre Updates auf den geheimen Schlüssel des Add-Ons angewendet wurden. Der Synchronisierungszeitraum beträgt 5 Minuten. |
WichtigMit den Befehlen in diesem Abschnitt wird die Lebenszyklusverwaltung des Pakets deaktiviert. Verwenden Sie nach Möglichkeit die im Folgenden unter Aktualisieren der Paketkonfiguration beschriebenen Verfahren.
Wenn Sie die Lebenszyklusverwaltung für ein automatisch verwaltetes Paket vorübergehend anhalten müssen, können Sie die folgenden Befehle verwenden:
Führen Sie den folgenden Befehl für den Verwaltungscluster aus, wenn der Abgleich des geheimen Schlüssels angehalten werden soll:
kubectl patch secret/CLUSTER-NAME-ADD-ON-NAME-addon -n CLUSTER-NAMESPACE -p '{"metadata":{"annotations":{"tkg.tanzu.vmware.com/addon-paused": ""}}}' --type=merge
Nach Ausführung dieses Befehls beendet tanzu-addons-manager
die Abstimmung des geheimen Schlüssels.
Führen Sie den folgenden Befehl für den Zielcluster aus, wenn der Abgleich der PackageInstall
-CR angehalten werden soll:
kubectl patch packageinstall/PACKAGE-NAME -n tkg-system -p '{"spec":{"paused":true}}' --type=merge
Nach Ausführung dieses Befehls beendet kapp-controller
den Abgleich der PackageInstall
- sowie der entsprechenden App
-CR.
Wenn Sie die Ressourcen einer Add-On-Komponente vorübergehend ändern möchten, halten Sie zuerst den Abgleich des geheimen Schlüssels und dann den Abgleich der PackageInstall
-CR an. Nach der Wiederaufnahme der Lebenszyklusverwaltung setzen tanzu-addons-manager
und kapp-controller
den Abgleich des geheimen Schlüssels und der PackageInstall
-CR fort:
Entfernen Sie tkg.tanzu.vmware.com/addon-paused
zum Fortsetzen des Abgleichs des geheimen Schlüssels aus den Anmerkungen des geheimen Schlüssels.
Zum Fortsetzen des Abgleichs der PackageInstall
-CR aktualisieren Sie die PackageInstall
-CR mit {"spec":{"paused":false}}
oder entfernen Sie die Variable.