In diesem Thema wird erläutert, wie Sie geheime Schlüssel konfigurieren und verwalten, die von Arbeitslastclustern in Tanzu Kubernetes Grid verwendet werden, einschließlich:
Wenn sich die Anmeldedaten, die Sie für den Zugriff auf vSphere oder Azure verwenden, ändern, können Sie Ihre Cluster aktualisieren, um die neuen Anmeldedaten zu verwenden. AWS verarbeitet Anmeldedaten unterschiedlich, sodass dieser Abschnitt nur für vSphere und Azure gilt.
Verwenden Sie den Befehl tanzu mc credentials update --cascading
, um die Anmeldedaten von vSphere zu aktualisieren, die vom aktuellen eigenständigen Verwaltungscluster und all seinen Arbeitslastclustern verwendet werden:
Führen Sie tanzu login
aus, um sich beim Verwaltungscluster, den Sie gerade aktualisieren, anzumelden.
Führen Sie tanzu mc credentials update
aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:
--vsphere-user
: Name für das vSphere-Konto.--vsphere-password
: Kennwort für das vSphere-Konto.Exklusives Aktualisieren von Anmeldedaten für eigenständigen Verwaltungscluster
Um die vSphere-Anmeldedaten eines eigenständigen Verwaltungsclusters zu aktualisieren, ohne sie auch für seine Arbeitslastcluster zu aktualisieren, verwenden Sie wie oben beschrieben den Befehl tanzu mc credentials update
, jedoch ohne die Option --cascading
.
Aktualisieren von Anmeldedaten für Arbeitslastcluster
Verwenden Sie den Befehl tanzu cluster credentials update
, um die Anmeldedaten zu aktualisieren, die ein einzelner Arbeitslastcluster für den Zugriff auf vSphere verwendet:
Führen Sie tanzu login
aus, um sich bei dem Verwaltungscluster anzumelden, der den Arbeitslastcluster erstellt hat, den Sie gerade aktualisieren. Der Verwaltungscluster kann der Supervisor-Cluster oder der eigenständige Verwaltungscluster sein.
Führen Sie tanzu cluster credentials update CLUSTER-NAME
aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:
--namespace
: Der Namespace des Clusters, für den Sie die Anmeldedaten aktualisieren, z B. default
.--vsphere-user
: Name für das vSphere-Konto.--vsphere-password
: Kennwort für das vSphere-Konto.Sie können auch tanzu mc credentials update --cascading
verwenden, um vSphere-Anmeldedaten für einen Verwaltungscluster und alle von ihm verwalteten Arbeitslastcluster zu aktualisieren.
WichtigBevor Sie beginnen, rufen Sie die neuen Azure-Anmeldedaten vom Azure-Portal oder von Ihrem Azure-Administrator ab.
Um die Azure-Anmeldedaten zu aktualisieren, die vom aktuellen eigenständigen Verwaltungscluster und allen seinen Arbeitslastclustern verwendet werden, verwenden Sie den Befehl tanzu mc credentials update --cascading
:
Führen Sie tanzu login
aus, um sich beim Verwaltungscluster, das Sie gerade aktualisieren, anzumelden.
Führen Sie tanzu mc credentials update
aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:
--azure-client-id
: Die Client-ID der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben--azure-client-secret
: Der geheime Clientschlüssel der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben--azure-tenant-id
: Die Mandanten-ID für Azure Active Directory, in dem sich die App für Tanzu Kubernetes Grid befindet.Exklusives Aktualisieren von Anmeldedaten für eigenständigen Verwaltungscluster
Um die Azure-Anmeldedaten eines eigenständigen Verwaltungsclusters zu aktualisieren, ohne sie auch für seine Arbeitslastcluster zu aktualisieren, verwenden Sie wie oben beschrieben den Befehl tanzu mc credentials update
, jedoch ohne die Option --cascading
.
Aktualisieren von Anmeldedaten für Arbeitslastcluster
Verwenden Sie den Befehl tanzu cluster credentials update
, um die Anmeldedaten zu aktualisieren, die ein einzelner Arbeitslastcluster für den Zugriff auf Azure verwendet:
Führen Sie tanzu login
aus, um sich bei dem Verwaltungscluster anzumelden, der den Arbeitslastcluster erstellt hat, den Sie gerade aktualisieren.
Führen Sie tanzu cluster credentials update CLUSTER-NAME
aus. Sie können Werte an die folgenden Befehlsoptionen übergeben oder sich durch die CLI zur Eingabe der Werte auffordern lassen:
--namespace
: Der Namespace des Clusters, für den Sie die Anmeldedaten aktualisieren, z B. default
.--azure-client-id
: Die Client-ID der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben--azure-client-secret
: Der geheime Clientschlüssel der App für Tanzu Kubernetes Grid, die Sie bei Azure registriert haben--azure-tenant-id
: Die Mandanten-ID für Azure Active Directory, in dem sich die App für Tanzu Kubernetes Grid befindet.Sie können auch tanzu mc credentials update --cascading
verwenden, um Azure-Anmeldedaten für einen Verwaltungscluster und alle von ihm verwalteten Arbeitslastcluster zu aktualisieren.
Konfigurieren Sie TKG-Cluster so, dass ihre VM-Zertifikate des Steuerungsebenen-Knotens je nach Konfigurationsmethode und Clustertyp wie folgt automatisch erneuert werden:
Objektspezifikation im Kubernetes-Stil (klassenbasierte Cluster):
Schließen Sie in Ihre Cluster
-Objektspezifikation den folgenden Block unter spec.topology.variables
ein:
- name: controlPlaneCertificateRotation.activate
value: true
- name: controlPlaneCertificateRotation.daysBefore
value: EXPIRY-DAYS
Flache Clusterkonfigurationsdatei (klassenbasierte oder Legacy-Cluster):
Nehmen Sie die folgenden Einstellungen in Ihre Clusterkonfigurationsdatei auf:
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
Dabei ist EXPIRY-DAYS
eine optionale Einstellung für die Anzahl der Tage vor dem Ablaufdatum des Zertifikats, um Clusterknotenzertifikate automatisch zu verlängern. Standard: 90; minimum: 7.
Die eigenständige Verwaltung und ihre Arbeitslastcluster verwenden Clientzertifikate zur Authentifizierung von Anforderungen. Diese Zertifikate sind ein Jahr lang gültig. Um sie zu verlängern, können Sie entweder ein Upgrade Ihrer Cluster oder das folgende Verfahren durchführen. Dieses Verfahren ist für Clusterzertifikate vorgesehen, die noch nicht abgelaufen und noch gültig sind.
Identifizieren Sie den Cluster, für den Sie seine Zertifikate verlängern möchten. Beispiel:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
workload-slot35rp10 default running 3/3 3/3 v1.25.7+vmware.1 <none> prod v1.25.7---vmware.1-tkg.1
Führen Sie folgenden Befehl aus, um die Clusterknoten aufzulisten:
kubectl get nodes -o wide
Überprüfen Sie das Ablaufdatum für die Zertifikate:
kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes
for i in `cat nodes`; do
printf "\n######\n"
ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
done;
kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes
for i in `cat nodes`; do
printf "\n######\n"
ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i hostname
ssh -i aws-cluster-key.pem -o "StrictHostKeyChecking=no" -q ubuntu@$i sudo kubeadm certs check-expiration
done;
kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes
for i in `cat nodes`; do
printf "\n######\n"
ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i hostname
ssh -i azure-cluster-key.pem -o "StrictHostKeyChecking=no" -q capi@$i sudo kubeadm certs check-expiration
done;
Beispielausgabe:
######
workload-slot35rp10-control-plane-ggsmj
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0923 17:51:03.686273 4172778 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Sep 21, 2023 23:13 UTC 363d ca no
apiserver Sep 21, 2023 23:13 UTC 363d ca no
apiserver-etcd-client Sep 21, 2023 23:13 UTC 363d etcd-ca no
apiserver-kubelet-client Sep 21, 2023 23:13 UTC 363d ca no
controller-manager.conf Sep 21, 2023 23:13 UTC 363d ca no
etcd-healthcheck-client Sep 21, 2023 23:13 UTC 363d etcd-ca no
etcd-peer Sep 21, 2023 23:13 UTC 363d etcd-ca no
etcd-server Sep 21, 2023 23:13 UTC 363d etcd-ca no
front-proxy-client Sep 21, 2023 23:13 UTC 363d front-proxy-ca no
scheduler.conf Sep 21, 2023 23:13 UTC 363d ca no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Sep 18, 2032 23:09 UTC 9y no
etcd-ca Sep 18, 2032 23:09 UTC 9y no
front-proxy-ca Sep 18, 2032 23:09 UTC 9y no
Setzen Sie den kubectl
-Kontext auf den Verwaltungscluster. Beispiel:
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
Rufen Sie den Namen des KCP-Objekts für Ihren Zielcluster ab. Beispiel:
kubectl get kcp
NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION
workload-slot35rp10-control-plane workload-slot35rp10 true true 3 3 3 0 42h v1.25.7+vmware.1
Verlängern Sie die Zertifikate, indem Sie ein Rollout der Steuerungsebene auslösen:
kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
Nachdem Sie diesen Befehl ausgeführt haben, beginnt Tanzu Kubernetes Grid mit der erneuten Bereitstellung Ihrer Clustermaschinen:
kubectl get machines
workload-slot35rp10-control-plane-7z95k workload-slot35rp10 Provisioning 20s v1.25.7+vmware.1
workload-slot35rp10-control-plane-ggsmj workload-slot35rp10 workload-slot35rp10-control-plane-ggsmj vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f Running 42h v1.25.7+vmware.1
workload-slot35rp10-control-plane-hxbxb workload-slot35rp10 workload-slot35rp10-control-plane-hxbxb vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd Running 42h v1.25.7+vmware.1
workload-slot35rp10-control-plane-sm4nw workload-slot35rp10 workload-slot35rp10-control-plane-sm4nw vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce Running 42h v1.25.7+vmware.1
workload-slot35rp10-md-0-667bcd6b57-79br9 workload-slot35rp10 workload-slot35rp10-md-0-667bcd6b57-79br9 vsphere://420142a2-d141-7d6b-b322-9c2afcc47da5 Running 42h v1.25.7+vmware.1
...
Wenn alle Maschinen den Zustand Running
aufweisen, stellen Sie sicher, dass die Zertifikatsverlängerung erfolgreich abgeschlossen wurde:
Setzen Sie den kubectl
-Kontext auf den Arbeitslastcluster:
kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
Überprüfen Sie das Ablaufdatum für die Zertifikate erneut:
kubectl get nodes \
-o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}' \
-l node-role.kubernetes.io/master= > nodes
for i in `cat nodes`; do
printf "\n######\n"
ssh -o "StrictHostKeyChecking=no" -q capv@$i hostname
ssh -o "StrictHostKeyChecking=no" -q capv@$i sudo kubeadm certs check-expiration
done;
Beispielausgabe:
######
workload-slot35rp10-control-plane-4xgw8
[check-expiration] Reading configuration from the cluster...
[check-expiration] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0923 18:10:02.660438 13427 utils.go:69] The recommended value for "resolvConf" in "KubeletConfiguration" is: /run/systemd/resolve/resolv.conf; the provided value is: /run/systemd/resolve/resolv.conf
CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED
admin.conf Sep 23, 2023 18:05 UTC 364d ca no
apiserver Sep 23, 2023 18:05 UTC 364d ca no
apiserver-etcd-client Sep 23, 2023 18:05 UTC 364d etcd-ca no
apiserver-kubelet-client Sep 23, 2023 18:05 UTC 364d ca no
controller-manager.conf Sep 23, 2023 18:05 UTC 364d ca no
etcd-healthcheck-client Sep 23, 2023 18:05 UTC 364d etcd-ca no
etcd-peer Sep 23, 2023 18:05 UTC 364d etcd-ca no
etcd-server Sep 23, 2023 18:05 UTC 364d etcd-ca no
front-proxy-client Sep 23, 2023 18:05 UTC 364d front-proxy-ca no
scheduler.conf Sep 23, 2023 18:05 UTC 364d ca no
CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED
ca Sep 18, 2032 23:09 UTC 9y no
etcd-ca Sep 18, 2032 23:09 UTC 9y no
front-proxy-ca Sep 18, 2032 23:09 UTC 9y no
Wenn die Zertifikatsverlängerung erfolgreich abgeschlossen wurde, wird in der Spalte Residual Time
364d
angezeigt. Zertifikate auf Worker-Knoten werden automatisch erneuert.
Informationen zum Konfigurieren eines von Supervisor bereitgestellten TKG-Clusters für die Verwendung einer privaten Containerregistrierung außerhalb von TKG (d. h., einer Registrierung mit einem selbstsignierten Zertifikat, das nicht in einem TKG-Cluster ausgeführt wird) finden Sie in den folgenden Themen in der vSphere-Dokumentation:
In einer Umgebungen mit Internetbeschränkungen und einem eigenständigen Verwaltungscluster können Sie TKG_CUSTOM_IMAGE_REPOSITORY_*
-Variablen konfigurieren, um TKG-Clustern Zugriff auf eine private Registrierung zu gewähren, die TKG-System-Images enthält, über die gestartet werden kann, wie z. B. eine Harbor-VM (siehe Beschreibung unter Bereitstellen einer Offline-Harbor-Registrierung auf vSphere).
Mithilfe der ADDITIONAL_IMAGE_REGISTRY_*
-Variablen wird ein neuer Cluster für eine vertrauenswürdige Kommunikation mit zusätzlichen Registrierungen konfiguriert, die selbstsignierte Zertifikate der Zertifizierungsstelle (CA) verwenden, wie z. B.:
containerd
(siehe Beschreibung unter Konfigurieren der Image-Registrierung im containerd
-Repository).Die Konfiguration von Clustern zum Herstellen einer Vertrauensstellung für diese privaten Registrierungen richtet sich danach, ob der Cluster plan- oder klassenbasiert ist (siehe folgende Beschreibung).
Zum Konfigurieren eines klassenbasierten Arbeitslastclusters oder eines eigenständigen Verwaltungsclusters mit Vertrauensstellung für zusätzliche benutzerdefinierte Image-Registrierungen legen Sie die Variablen für bis zu drei zusätzliche Image-Registrierungen wie folgt fest:
Für die Konfiguration von mehr als drei Registrierungen konfigurieren Sie die ersten drei wie folgt in Schritt 1 eines zweistufigen Prozesses, der unter Erstellen eines klassenbasierten Clusters beschrieben wird. Führen Sie dann die Anweisungen unter Herstellen einer Vertrauensstellung zwischen einem klassenbasierten Cluster und einer benutzerdefinierten Registrierung durch, um dem erzeugten Manifest weitere Registrierungen hinzuzufügen, bevor Sie den Cluster in Schritt 2 erstellen.
ADDITIONAL_IMAGE_REGISTRY_1: "OTHER-REGISTRY-1"
ADDITIONAL_IMAGE_REGISTRY_1_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_1_CA_CERTIFICATE: "CA-BASE64-1"
ADDITIONAL_IMAGE_REGISTRY_2: "OTHER-REGISTRY-2"
ADDITIONAL_IMAGE_REGISTRY_2_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_2_CA_CERTIFICATE: "CA-BASE64-2"
ADDITIONAL_IMAGE_REGISTRY_3: "OTHER-REGISTRY-3"
ADDITIONAL_IMAGE_REGISTRY_3_SKIP_TLS_VERIFY: false
ADDITIONAL_IMAGE_REGISTRY_3_CA_CERTIFICATE: "CA-BASE64-3"
Wobei OTHER-REGISTRY-<n>
die IP-Adresse oder der FQDN einer zusätzlichen privaten Registrierung und CA-BASE64-<n>
das zugehörige CA-Zertifikat im Base64-codierten Format ohne das Präfix http://
darstellt. Dies ist notwendig, da diese Datei auf die Festplatte geschrieben wird. Folglich muss es sich um einen normalen Unix-Dateinamen handeln.
Damit ein neuer TKC- oder planbasierter Cluster Images aus Container-Registrierungen abrufen kann, die selbstsignierte Zertifikate verwenden, fügen Sie den Arbeitslastclusterknoten die benutzerdefinierten Zertifikate mithilfe einer Overlay-Datei vom Typ ytt
hinzu.
Der folgende Overlay-Code fügt benutzerdefinierte CA-Zertifikate zu allen Knoten in einem neuen Cluster hinzu. Der Code funktioniert bei allen Cloud-Zielplattformen für Cluster, die auf Photon- oder Ubuntu-VM-Image-Vorlagen basieren.
Informationen zu Overlays, die Cluster anpassen und einen neuen Cluster-Plan erstellen, finden Sie unter ytt
-Overlays.
Wählen Sie aus, auf welche Cluster die benutzerdefinierte Zertifizierungsstelle angewendet werden soll: auf alle Cluster, nur auf die in einer Cloud-Infrastruktur erstellten Cluster oder auf Cluster, die mit einer bestimmten Version des Cluster-API-Anbieters erstellt wurden, wie z. B. Cluster-API-Anbieter vSphere v1.5.1.
Suchen Sie im lokalen ~/.config/tanzu/tkg/providers/
-Verzeichnis das ytt
-Verzeichnis, das den von Ihnen gewählten Geltungsbereich abdeckt. Beispiel: /ytt/03_customizations/
gilt für alle Cluster, und /infrastructure-vsphere/ytt/
gilt für alle vSphere-Cluster.
Erstellen Sie im ausgewählten ytt
-Verzeichnis eine neue .yaml
-Datei oder erweitern Sie eine vorhandene Overlay-Datei um den folgenden Code:
#@ load("@ytt:overlay", "overlay")
#@ load("@ytt:data", "data")
#! This ytt overlay adds additional custom CA certificates on TKG cluster nodes, so containerd and other tools trust these CA certificates.
#! It works when using Photon or Ubuntu as the TKG node template on all TKG target platforms.
#! Trust your custom CA certificates on all Control Plane nodes.
#@overlay/match by=overlay.subset({"kind":"KubeadmControlPlane"})
---
spec:
kubeadmConfigSpec:
#@overlay/match missing_ok=True
files:
#@overlay/append
- content: #@ data.read("tkg-custom-ca.pem")
owner: root:root
permissions: "0644"
path: /etc/ssl/certs/tkg-custom-ca.pem
#@overlay/match missing_ok=True
preKubeadmCommands:
#! For Photon OS
#@overlay/append
- '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
#! For Ubuntu
#@overlay/append
- '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
#! Trust your custom CA certificates on all worker nodes.
#@overlay/match by=overlay.subset({"kind":"KubeadmConfigTemplate"}), expects="1+"
---
spec:
template:
spec:
#@overlay/match missing_ok=True
files:
#@overlay/append
- content: #@ data.read("tkg-custom-ca.pem")
owner: root:root
permissions: "0644"
path: /etc/ssl/certs/tkg-custom-ca.pem
#@overlay/match missing_ok=True
preKubeadmCommands:
#! For Photon OS
#@overlay/append
- '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
#! For Ubuntu
#@overlay/append
- '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem /usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
Fügen Sie im selben ytt
-Verzeichnis die Zertifizierungsstelle zu einer neuen oder vorhandenen tkg-custom-ca.pem
-Datei hinzu.
Legen Sie vor dem Erstellen des Clusters die Funktion allow-legacy-cluster
auf true
fest, wie unter (Legacy) Erstellen eines planbasierten oder TKC-Clusters beschrieben.
Sie können vertrauenswürdige Kommunikation zwischen einem vorhandenen Cluster und zusätzlichen benutzerdefinierten Harbor-Registrierungen mit selbstsignierten Zertifizierungsstellen, die über die von den TKG_CUSTOM_IMAGE_REPOSITORY_*
-Konfigurationsvariablen festgelegten hinausgehen, für containerd
-TLS und zu anderen Zwecken aktivieren. Die entsprechende Vorgehensweise richtet sich danach, ob der Cluster plan- oder klassenbasiert ist (siehe folgende Beschreibung).
Zum Hinzufügen einer vertrauenswürdigen benutzerdefinierten Registrierung zu einem vorhandenen klassenbasierten Cluster bearbeiten Sie das Cluster
-Objekt und fügen additionalImageRegistries
-Einstellungen unter topology.variables
in der Objektspezifikation hinzu:
topology:
variables:
- name: additionalImageRegistries
value:
- caCert: "CA-BASE64"
host: OTHER-REGISTRY
skipTlsVerify: false
Dabei gilt:
OTHER-REGISTRY
ist der zusätzliche Speicherort für die private Registrierung im Format
10.92.127.192:8443
.
CA-BASE64
ist das zugehörige CA-Zertifikat im Base64-codierten Format, wie z. B. LS0tLS1CRU[...]
.Zum Hinzufügen einer Vertrauensstellung für mehrere Registrierungen schließen Sie mehrere additionalImageRegistries
-Wertblöcke ein.
Beachten Sie, dass die topology.variables
-Blöcke für imageRepository
und trust
Werte aus den Konfigurationsvariablen TKG_CUSTOM_IMAGE_REPOSITORY_*
und TKG_PROXY_CA_CERT
festlegen.
So aktivieren Sie die Vertrauensstellung zwischen einem planbasierten Cluster und einer Harbor-Registrierung mit einer selbstsignierten Zertifizierungsstelle:
Rufen Sie das Harbor-CA-Zertifikat ab:
Wechseln Sie den Kontext zu dem Cluster, auf dem Harbor ausgeführt wird, z. B. zu einem Cluster mit gemeinsam genutzten Diensten:
kubectl config use-context SERVICES-CLUSTER-CONTEXT
Dabei ist SERVICES-CLUSTER-CONTEXT
der Kontext des Clusters. Beispiel: tkg-wld-admin@tkg-wld
.
Rufen Sie das Zertifikat ab:
kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----
Fügen Sie die benutzerdefinierte Zertifizierungsstelle zur kubeadmconfigtemplate
des eigenständigen Verwaltungsclusters hinzu:
Wechseln Sie den Kontext zum Verwaltungscluster.
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
Dabei ist MANAGEMENT-CLUSTER-CONTEXT
der Kontext Ihres Verwaltungsclusters. Beispiel: tkg-mgmt-admin@tkg-mgmt
.
Öffnen Sie in einem Editor die Vorlagendatei kubeadmconfigtemplate
des Clusters:
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
Dabei ist CLUSTER-NAME
der Name des Clusters, der geändert werden muss.
Ändern Sie den Abschnitt spec.template.spec.files
, um das Zertifikat einzuschließen, wie im folgenden Beispiel dargestellt:
spec:
template:
spec:
files:
- content: |
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----
owner: root:root
path: /etc/ssl/certs/tkg-custom-ca.pem
permissions: "0644"
Fügen Sie unten in der Datei einen Block preKubeadmCommands
wie im folgenden Beispiel dargestellt hinzu:
preKubeadmCommands:
- '! which rehash_ca_certificates.sh 2>/dev/null || rehash_ca_certificates.sh'
- '! which update-ca-certificates 2>/dev/null || (mv /etc/ssl/certs/tkg-custom-ca.pem
/usr/local/share/ca-certificates/tkg-custom-ca.crt && update-ca-certificates)'
Speichern Sie die Vorlagendatei kubeadmconfigtemplate
mit Ihren Änderungen.
Patchen Sie den eigenständigen Verwaltungscluster mit den Änderungen:
kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
Wenn Sie diesen Befehl ausführen, wird ein paralleles Update der Clusterknoten ausgelöst und deren Zeitstempel aktualisiert.
Sie können geheime Authentifizierungsschlüssel hinzufügen, um einem Cluster den Zugriff auf eine private Containerregistrierung zu ermöglichen, für die eine Benutzerauthentifizierung zum Abrufen von Images erforderlich ist. Sie können auch die geheimen Authentifizierungsschlüssel anzeigen, aktualisieren oder löschen, die Sie für die privaten Registrierungen konfiguriert haben, auf die ein Cluster zugreift.
Mithilfe der Tanzu CLI können Sie geheime Authentifizierungsschlüssel hinzufügen, um von einem Cluster aus auf eine private Containerregistrierung zuzugreifen. Nachdem der geheime Registrierungsschlüssel zu den Namespaces in Ihrem Cluster hinzugefügt wurde, können Sie alle Paketrepositorys, Pakete und Container-Images abrufen, die in der privaten Registrierung gehostet werden. Anschließend können Sie das Paketrepository und die Paketressourcen zu Ihrem Cluster hinzufügen.
Bevor Sie diesen Vorgang durchführen, müssen Sie den Benutzernamen und das Kennwort für die private Containerregistrierung abrufen.
Führen Sie den folgenden Befehl aus, um einen geheimen Authentifizierungsschlüssel zu einer privaten Registrierung hinzuzufügen:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD
Dabei gilt:
SECRET-NAME
ist der Name des geheimen Authentifizierungsschlüssels für die Registrierung, den Sie hinzufügen möchten.NAMESPACE
ist der Tanzu Kubernetes Grid-Namespace, zu dem die Registrierung gehört.USERNAME
ist der Benutzername für den Zugriff auf die Registrierung. Setzen Sie den Benutzernamen in einfache Anführungszeichen, wenn er Sonderzeichen enthält.PASSWORD
ist das Kennwort für den Zugriff auf die Registrierung. Setzen Sie das Kennwort in einfache Anführungszeichen, wenn es Sonderzeichen enthält. Sie können das Kennwort auch in den folgenden Formaten angeben:
Ersetzen Sie die Zeichenfolge --password PASSWORD
im Befehl durch --password-env-var ENV-VAR
, um das Kennwort über die Umgebungsvariable anzugeben, die Sie bereits konfiguriert haben. Das Format des Befehls lautet wie folgt:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR
Ersetzen Sie die Zeichenfolge --password PASSWORD
im Befehl durch die Zeichenfolge --password-stdin
, um das Kennwort über die Standardeingabe anzugeben, und geben Sie das Kennwort ein, wenn Sie dazu aufgefordert werden. Das Format des Befehls lautet wie folgt:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin
Ersetzen Sie die Zeichenfolge --password PASSWORD
im Befehl durch die Zeichenfolge --password-file PASSWORD-FILE
, um das Kennwort über eine Kennwortdatei anzugeben. Das Format des Befehls lautet wie folgt:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE
Um optional den geheimen Registrierungsschlüssel für alle Namespaces in einem Cluster verfügbar zu machen, verwenden Sie die Option --export-to-all-namespaces
in dem folgenden Format:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces
Nachfolgend sehen Sie eine Beispielausgabe dieses Befehls:
tanzu secret registry add tanzu-net -n test-ns --server registry.pivotal.io --username test-user --password-file pass-file --export-to-all-namespaces
Warning: By choosing --export-to-all-namespaces, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
/ Adding registry secret 'test-secret'...
Added registry secret 'test-secret' into namespace 'test-ns'
Sie können die geheimen Authentifizierungsschlüssel für die Registrierung im Standard-Namespace oder in allen Namespaces in einem Cluster anzeigen. Sie können die geheimen Schlüssel in Form einer Tabelle, einer JSON- oder YAML-Datei anzeigen.
Um die geheimen Authentifizierungsschlüssel für die Registrierung in einem bestimmten Namespace in einem Cluster anzuzeigen, führen Sie den folgenden Befehl aus:
tanzu secret registry list -n NAMESPACE
Dabei ist NAMESPACE
der Tanzu Kubernetes Grid-Namespace, zu dem die Registrierung gehört.
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE
pkg-dev-reg registry.pivotal.io to all namespaces 15d
Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung in allen Namespaces in einem Cluster anzuzeigen, führen Sie den folgenden Befehl aus:
tanzu secret registry list -A
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry list -A
\ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE NAMESPACE
pkg-dev-reg registry.pivotal.io to all namespaces 15d test-ns
tanzu-standard-fetch-0 registry.pivotal.io not exported 15d tanzu-package-repo-global
private-repo-fetch-0 registry.pivotal.io not exported 15d test-ns
antrea-fetch-0 registry.pivotal.io not exported 15d tkg-system
metrics-server-fetch-0 registry.pivotal.io not exported 15d tkg-system
tanzu-addons-manager-fetch-0 registry.pivotal.io not exported 15d tkg-system
tanzu-core-fetch-0 registry.pivotal.io not exported 15d tkg-system
Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im JSON-Dateiformat anzuzeigen, führen Sie den folgenden Befehl aus:
tanzu secret registry list -n kapp-controller-packaging-global -o json
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry list -n kapp-controller-packaging-global -o json
[
{
"age": "15d",
"exported": "to all namespaces",
"name": "pkg-dev-reg",
"registry": "us-east4-docker.pkg.dev"
}
]
Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im YAML-Dateiformat anzuzeigen, führen Sie den folgenden Befehl aus:
tanzu secret registry list -n kapp-controller-packaging-global -o yaml
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry list -n kapp-controller-packaging-global -o yaml
- age: 15d
exported: to all namespaces
name: pkg-dev-reg
registry: us-east4-docker.pkg.dev
Um die Liste der geheimen Authentifizierungsschlüssel für die Registrierung im Tabellenformat anzuzeigen, führen Sie den folgenden Befehl aus:
tanzu secret registry list -n kapp-controller-packaging-global -o table
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry list -n kapp-controller-packaging-global -o table
/ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE
pkg-dev-reg us-east4-docker.pkg.dev to all namespaces 15d
Sie können die Anmeldedaten in einem geheimen Schlüssel aktualisieren, einen geheimen Schlüssel für alle Namespaces verfügbar machen oder ihn nur in einem Namespace im Cluster verfügbar machen.
Um den geheimen Schlüssel in dem Namespace zu aktualisieren, in dem er erstellt wurde, führen Sie den folgenden Befehl aus:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD
Dabei gilt:
SECRET-NAME
ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.NAMESPACE
ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.USERNAME
ist der neue Benutzername für den Zugriff auf die Registrierung (wenn Sie den Benutzernamen aktualisieren möchten).PASSWORD
ist das neue Kennwort für die Registrierung (wenn Sie das Kennwort aktualisieren möchten).HinweisSie können entweder den Benutzernamen oder das Kennwort oder beides aktualisieren.
Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV
\ Updating registry secret 'test-secret'...
Updated registry secret 'test-secret' in namespace 'test-ns'
Um den geheimen Authentifizierungsschlüssel für die Registrierung zu aktualisieren und ihn in anderen Namespaces im Cluster verfügbar zu machen, führen Sie den folgenden Befehl aus:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true
Dabei gilt:
SECRET-NAME
ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.NAMESPACE
ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.USERNAME
ist der Benutzername für den Zugriff auf die Registrierung. Geben Sie zum Aktualisieren des Benutzernamens einen neuen Benutzernamen ein.PASSWORD
ist das Kennwort für die Registrierung. Geben Sie zum Aktualisieren des Kennworts ein neues Kennwort ein.Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry update test-secret--username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=true
Warning: By specifying --export-to-all-namespaces as true, given secret contents will be available to ALL users in ALL namespaces. Please ensure that included registry credentials allow only read-only access to the registry with minimal necessary scope.
Are you sure you want to proceed? [y/N]: y
\ Updating registry secret 'test-secret'...
Updated registry secret 'test-secret' in namespace 'test-ns'
Exported registry secret 'test-secret' to all namespaces
Um die Verfügbarkeit eines geheimen Authentifizierungsschlüssels für die Registrierung in anderen Namespaces im Cluster aufzuheben, führen Sie den folgenden Befehl aus:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false
Dabei gilt:
SECRET-NAME
ist der Name des geheimen Registrierungsschlüssels, den Sie aktualisieren möchten.NAMESPACE
ist der Tanzu Kubernetes Grid-Namespace, in dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung aktualisieren.USERNAME
ist der Benutzername für den Zugriff auf die Registrierung.PASSWORD
ist das Kennwort für die Registrierung.Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry update test-secret --username test-user -n test-ns --password-env-var PASSENV --export-to-all-namespaces=false
Warning: By specifying --export-to-all-namespaces as false, the secret contents will get unexported from ALL namespaces in which it was previously available to.
Are you sure you want to proceed? [y/N]: y
\ Updating registry secret 'test-secret'...
Updated registry secret 'test-secret' in namespace 'test-ns'
Unexported registry secret 'test-secret' from all namespaces
Mithilfe der Tanzu CLI können Sie einen geheimen Authentifizierungsschlüssel für die Registrierung in einem Cluster löschen. Um einen geheimen Authentifizierungsschlüssel für die Registrierung in einem bestimmten Namespace zu löschen, führen Sie den folgenden Befehl aus:
tanzu secret registry delete SECRET-NAME -n NAMESPACE
Dabei gilt:
SECRET-NAME
ist der Name des geheimen Registrierungsschlüssels, den Sie löschen möchten.NAMESPACE
ist der Tanzu Kubernetes Grid-Namespace, aus dem Sie den geheimen Authentifizierungsschlüssel für die Registrierung löschen möchten. Wenn Sie keinen Namespace angeben, wird der Authentifizierungsschlüssel aus dem Standard-Namespace gelöscht. Wenn der geheime Schlüssel in andere Namespaces im Cluster exportiert wurde, wird er ebenfalls gelöscht.Es folgt ein Beispiel für diesen Befehl:
tanzu secret registry delete test-secret -n test-ns
Deleting registry secret 'test-secret' from namespace 'test-ns'. Are you sure? [y/N]: y
\ Deleting registry secret 'test-secret'...
Deleted registry secret 'test-secret' from namespace 'test-ns'