Cette rubrique explique comment configurer et gérer les secrets utilisés par les clusters de charge de travail dans Tanzu Kubernetes Grid, notamment :
Si les informations d'identification que vous utilisez pour accéder à vSphere ou Azure sont modifiées, vous pouvez mettre à jour vos clusters afin d'utiliser les nouvelles informations d'identification. AWS gère les informations d'identification différemment. Cette section ne s'applique donc qu'à vSphere et Azure.
Pour mettre à jour les informations d'identification vSphere utilisées par le cluster de gestion autonome actuel et par tous ses clusters de charge de travail, utilisez la commande tanzu mc credentials update --cascading
:
Exécutez tanzu login
pour vous connecter au cluster de gestion que vous mettez à jour.
Exécutez tanzu mc credentials update
. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :
--vsphere-user
: nom du compte vSphere.--vsphere-password
: mot de passe du compte vSphere.Mettre à jour les informations d'identification du cluster de gestion autonome uniquement
Pour mettre à jour les informations d'identification vSphere d'un cluster de gestion autonome sans les mettre également à jour pour ses clusters de charge de travail, utilisez la commande tanzu mc credentials update
comme décrit ci-dessus, mais sans l'option --cascading
.
Mettre à jour les informations d'identification du cluster de charge de travail
Pour mettre à jour les informations d'identification qu'un cluster de charge de travail unique utilise pour accéder à vSphere, utilisez la commande tanzu cluster credentials update
:
Exécutez tanzu login
pour vous connecter au cluster de gestion qui a créé le cluster de charge de travail que vous mettez à jour. Le cluster de gestion peut être le cluster superviseur ou le cluster de gestion autonome.
Exécutez tanzu cluster credentials update CLUSTER-NAME
. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :
--namespace
: espace de noms du cluster pour lequel vous mettez à jour les informations d'identification telles que default
.--vsphere-user
: nom du compte vSphere.--vsphere-password
: mot de passe du compte vSphere.Vous pouvez également utiliser tanzu mc credentials update --cascading
pour mettre à jour les informations d'identification vSphere d'un cluster de gestion et de tous les clusters de charge de travail qu'il gère.
ImportantAvant de commencer, procurez-vous les nouvelles informations d'identification Azure depuis le portail Azure ou auprès de votre administrateur Azure.
Pour mettre à jour les informations d'identification Azure utilisées par le cluster de gestion autonome actuel et par tous ses clusters de charge de travail, utilisez la commande tanzu mc credentials update --cascading
:
Exécutez tanzu login
pour vous connecter au cluster de gestion que vous mettez à jour.
Exécutez tanzu mc credentials update
. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :
--azure-client-id
: ID client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.--azure-client-secret
: Clé secrète client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.--azure-tenant-id
: ID de locataire Azure pour l'instance d'Active Directory dans laquelle se trouve l'application pour Tanzu Kubernetes Grid.Mettre à jour les informations d'identification du cluster de gestion autonome uniquement
Pour mettre à jour les informations d'identification Azure d'un cluster de gestion autonome sans les mettre également à jour pour ses clusters de charge de travail, utilisez la commande tanzu mc credentials update
comme décrit ci-dessus, mais sans l'option --cascading
.
Mettre à jour les informations d'identification du cluster de charge de travail
Pour mettre à jour les informations d'identification qu'un cluster de charge de travail unique utilise pour accéder à Azure, utilisez la commande tanzu cluster credentials update
:
Exécutez tanzu login
pour vous connecter au cluster de gestion qui a créé le cluster de charge de travail que vous mettez à jour.
Exécutez tanzu cluster credentials update CLUSTER-NAME
. Vous pouvez transmettre des valeurs aux options de commande suivantes ou laisser la CLI vous y inviter :
--namespace
: espace de noms du cluster pour lequel vous mettez à jour les informations d'identification telles que default
.--azure-client-id
: ID client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.--azure-client-secret
: Clé secrète client de l'application pour l'instance de Tanzu Kubernetes Grid que vous avez enregistrée dans Azure.--azure-tenant-id
: ID de locataire Azure pour l'instance d'Active Directory dans laquelle se trouve l'application pour Tanzu Kubernetes Grid.Vous pouvez également utiliser tanzu mc credentials update --cascading
pour mettre à jour les informations d'identification Azure d'un cluster de gestion et de tous les clusters de charge de travail qu'il gère.
Configurez les clusters TKG pour renouveler automatiquement leurs certificats de machine virtuelle de nœud de plan de contrôle comme suit, en fonction de la méthode de configuration et du type de cluster :
Spécification d'objet de style Kubernetes (clusters basés sur une classe) :
Dans la spécification d'objet Cluster
, incluez le bloc suivant sous spec.topology.variables
:
- name: controlPlaneCertificateRotation.activate
value: true
- name: controlPlaneCertificateRotation.daysBefore
value: EXPIRY-DAYS
Fichier de configuration de cluster plat (clusters basés sur une classe ou hérités) :
Dans votre fichier de configuration de cluster, incluez les paramètres suivants :
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
Où EXPIRY-DAYS
est un paramètre facultatif correspondant au nombre de jours avant la date d'expiration du certificat pour renouveler automatiquement les certificats de nœud de cluster. Défaut : 90 ; minimum : 7.
Les clusters de gestion autonomes et leurs clusters de charge de travail utilisent des certificats clients pour authentifier les demandes. Ces certificats sont valides pendant un an. Pour les renouveler, vous pouvez mettre à niveau vos clusters ou suivre la procédure ci-dessous. Cette procédure est destinée aux certificats de cluster qui n'ont pas expiré et qui sont toujours valides.
Identifiez le cluster pour lequel vous souhaitez renouveler ses certificats. Par exemple :
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
Pour répertorier les nœuds de cluster, exécutez :
kubectl get nodes -o wide
Vérifiez la date d'expiration des certificats :
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;
Exemple de résultat :
######
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
Définissez votre contexte kubectl
sur le cluster de gestion. Par exemple :
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
Obtenez le nom de l'objet KCP pour votre cluster cible. Par exemple :
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
Renouvelez les certificats en déclenchant le déploiement d'un plan de contrôle :
kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
Après avoir exécuté cette commande, Tanzu Kubernetes Grid commence à reprovisionner vos machines de cluster :
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
...
Lorsque toutes les machines sont à l'état Running
, vérifiez que le renouvellement du certificat est terminé :
Définissez votre contexte kubectl
sur le cluster de charge de travail :
kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
Vérifiez à nouveau la date d'expiration des certificats :
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;
Exemple de résultat :
######
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
Si le renouvellement du certificat s'est correctement terminé, la colonne Residual Time
indique 364d
. Les certificats sur les nœuds worker sont renouvelés automatiquement.
Pour configurer un cluster TKG déployé par le superviseur afin qu'il utilise un registre de conteneur privé externe à TKG, c'est-à-dire un registre avec un certificat auto-signé qui ne s'exécute pas dans un cluster TKG, reportez-vous aux rubriques suivantes de la documentation de vSphere :
Dans un environnement à accès restreint à Internet avec un cluster de gestion autonome, vous pouvez configurer des variables TKG_CUSTOM_IMAGE_REPOSITORY_*
pour donner aux clusters TKG l'accès à un registre privé contenant des images système TKG à partir desquelles démarrer, par exemple une VM Harbor, comme décrit dans la section Déployer un registre Harbor hors ligne sur vSphere.
Les variables ADDITIONAL_IMAGE_REGISTRY_*
configurent un nouveau cluster pour qu'il dispose de communications approuvées avec des registres supplémentaires qui utilisent des certificats d'autorité de certification (CA) auto-signés, par exemple :
containerd
, comme décrit dans la section Configurer le registre d'images du référentiel containerd
.La configuration des clusters pour approuver ces registres privés supplémentaires varie selon que le cluster est basé sur un plan ou sur une classe, comme décrit ci-dessous.
Pour configurer un cluster de charge de travail basé sur une classe ou un cluster de gestion autonome avec approbation pour des registres d'images personnalisés supplémentaires, définissez les variables comme ci-dessous pour trois registres d'images supplémentaires au maximum :
Pour configurer plus de trois registres, configurez les trois premiers, comme ci-dessous à l'étape 1 d'un processus en deux étapes décrit dans la section Créer un cluster basé sur une classe, puis suivez Définir une approbation de cluster basé sur une classe comme registre personnalisé ci-dessous pour ajouter d'autres registres au manifeste généré avant de créer le cluster à l'étape 2.
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"
Où OTHER-REGISTRY-<n>
est l'adresse IP ou le nom de domaine complet d'un registre privé supplémentaire et CA-BASE64-<n>
est son certificat d'autorité de certification au format codé en base64, sans préfixe http://
. Cela est nécessaire, car ce fichier sera écrit sur le disque. Il doit donc s'agir d'un nom de fichier Unix normal.
Pour permettre à un nouveau cluster TKC ou basé sur un plan d'extraire des images de registres de conteneur qui utilisent des certificats auto-signés, ajoutez les certificats personnalisés aux nœuds du cluster de charge de travail à l'aide d'un fichier de superposition ytt
.
Le code de superposition ci-dessous ajoute des certificats d'autorité de certification personnalisés à tous les nœuds d'un nouveau cluster. Le code fonctionne sur toutes les plates-formes cibles de cloud pour les clusters basés sur des modèles d'image de VM Photon ou Ubuntu.
Pour les superpositions qui personnalisent les clusters et créent un plan de cluster, reportez-vous à la section Superpositions ytt
.
Choisissez d'appliquer l'autorité de certification personnalisée à tous les nouveaux clusters, uniquement ceux créés sur une infrastructure de cloud ou ceux créés avec une version de fournisseur d'API de cluster spécifique, telle que le Fournisseur d'API du cluster vSphere v1.5.1.
Dans votre répertoire local ~/.config/tanzu/tkg/providers/
, recherchez le répertoire ytt
qui couvre la portée que vous avez choisie. Par exemple, /ytt/03_customizations/
s'applique à tous les clusters, et /infrastructure-vsphere/ytt/
s'applique à tous les clusters vSphere.
Dans le répertoire ytt
que vous avez choisi, créez un fichier .yaml
ou augmentez un fichier de superposition existant avec le code suivant :
#@ 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)'
Dans le même répertoire ytt
, ajoutez l'autorité de certification à un fichier tkg-custom-ca.pem
nouveau ou existant.
Avant de créer le cluster, définissez la fonctionnalité allow-legacy-cluster
sur true
, comme décrit dans la section (Hérité) Créer un cluster basé sur un plan ou un cluster TKC.
Vous pouvez activer la communication approuvée entre un cluster existant et des registres Harbor personnalisés supplémentaires avec des autorités de certification auto-signées, hormis celle définie par les variables de configuration TKG_CUSTOM_IMAGE_REPOSITORY_*
, pour TLS containerd
et d'autres utilisations. La procédure à effectuer varie selon que le cluster est basé sur un plan ou sur une classe, comme décrit ci-dessous.
Pour ajouter un registre personnalisé approuvé à un cluster existant basé sur une classe, modifiez son objet Cluster
et ajoutez les paramètres additionalImageRegistries
sous topology.variables
dans la spécification d'objet :
topology:
variables:
- name: additionalImageRegistries
value:
- caCert: "CA-BASE64"
host: OTHER-REGISTRY
skipTlsVerify: false
Où :
OTHER-REGISTRY
est l'emplacement du registre privé supplémentaire, suivant le format
10.92.127.192:8443
.
CA-BASE64
est son certificat d'autorité de certification au format codé en base64, par exemple LS0tLS1CRU[...]
.Pour ajouter une approbation à plusieurs registres, incluez plusieurs blocs de valeurs additionalImageRegistries
.
Notez que les blocs topology.variables
pour imageRepository
et trust
définissent les valeurs des variables de configuration TKG_CUSTOM_IMAGE_REPOSITORY_*
et TKG_PROXY_CA_CERT
.
Pour activer l'approbation entre un cluster existant basé sur un plan et un registre Harbor avec une autorité de certification auto-signée :
Récupérez le certificat d'autorité de certification Harbor :
Changez de contexte vers le cluster exécutant Harbor, tel qu'un cluster de services partagés :
kubectl config use-context SERVICES-CLUSTER-CONTEXT
Où SERVICES-CLUSTER-CONTEXT
est le contexte du cluster. Par exemple, tkg-wld-admin@tkg-wld
.
Récupérez le certificat :
kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----
Ajoutez l'autorité de certification personnalisée au kubeadmconfigtemplate
du cluster de gestion autonome :
Changez de contexte vers le cluster de gestion.
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
Où MANAGEMENT-CLUSTER-CONTEXT
est le contexte de votre cluster de gestion. Par exemple, tkg-mgmt-admin@tkg-mgmt
.
Dans un éditeur, ouvrez le fichier de modèle kubeadmconfigtemplate
du cluster :
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
Où CLUSTER-NAME
est le nom du cluster qui doit être modifié.
Modifiez la section spec.template.spec.files
du fichier pour inclure le certificat, comme indiqué ici :
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"
Au bas du fichier, ajoutez un bloc preKubeadmCommands
comme indiqué ici :
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)'
Enregistrez le fichier de modèle kubeadmconfigtemplate
avec vos modifications.
Corrigez le cluster de gestion autonome avec les modifications suivantes :
kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
L'exécution de cette commande déclenche une mise à jour continue des nœuds de cluster et met à jour leur horodatage.
Vous pouvez ajouter des secrets d'authentification pour permettre à un cluster d'accéder à un registre de conteneur privé. Cela nécessite une authentification utilisateur pour extraire des images. Vous pouvez également afficher, mettre à jour ou supprimer les secrets d'authentification que vous avez configurés pour les registres privés accessibles par un cluster.
L'utilisation de la CLI Tanzu vous permet d'ajouter des secrets d'authentification pour accéder à un registre de conteneur privé à partir d'un cluster. Une fois le secret de registre ajouté aux espaces de noms de votre cluster, vous pouvez extraire tous les référentiels de modules, modules et images de conteneur qui sont hébergés dans le registre privé. Vous pouvez ajouter le référentiel de modules et les ressources de module à votre cluster.
Pour effectuer cette procédure, procurez-vous le nom d'utilisateur et le mot de passe du registre de conteneur privé.
Pour ajouter un secret d'authentification à un registre privé, exécutez la commande suivante :
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD
Où :
SECRET-NAME
est le nom du secret d'authentification de registre que vous souhaitez ajouter.NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid auquel appartient le registre.USERNAME
est le nom d'utilisateur permettant d'accéder au registre. Placez le nom d'utilisateur entre guillemets simples s'il contient des caractères spéciaux.PASSWORD
est le mot de passe permettant d'accéder au registre. Placez le mot de passe entre guillemets simples s'il contient des caractères spéciaux. Vous pouvez également spécifier le mot de passe aux formats suivants :
Remplacez la chaîne --password PASSWORD
dans la commande par --password-env-var ENV-VAR
pour spécifier le mot de passe via la variable d'environnement que vous avez déjà configurée. Le format de cette commande est le suivant :
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR
Remplacez la chaîne --password PASSWORD
dans la commande par la chaîne --password-stdin
pour spécifier le mot de passe via une entrée standard et entrez le mot de passe lorsque vous y êtes invité. Le format de cette commande est le suivant :
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin
Remplacez la chaîne --password PASSWORD
de la commande par la chaîne --password-file PASSWORD-FILE
pour spécifier le mot de passe via un fichier de mot de passe. Le format de cette commande est le suivant :
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE
Pour rendre le secret de registre disponible dans tous les espaces de noms d'un cluster, vous pouvez également utiliser l'option --export-to-all-namespaces
comme indiqué au format suivant :
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces
Voici un exemple de sortie de cette commande :
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'
Vous pouvez afficher les secrets d'authentification de registre dans l'espace de noms par défaut ou dans tous les espaces de noms d'un cluster. Vous pouvez afficher les secrets sous la forme d'un tableau ou d'un fichier JSON ou YAML.
Pour afficher les secrets d'authentification de registre dans un espace de noms spécifique d'un cluster, exécutez les opérations suivantes :
tanzu secret registry list -n NAMESPACE
Où NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid auquel appartient le registre.
Voici un exemple de commande :
tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE
pkg-dev-reg registry.pivotal.io to all namespaces 15d
Pour afficher la liste des secrets d'authentification de registre dans tous les espaces de noms d'un cluster, exécutez les opérations suivantes :
tanzu secret registry list -A
Voici un exemple de commande :
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
Pour afficher la liste des secrets d'authentification de registre au format de fichier JSON, exécutez la commande suivante :
tanzu secret registry list -n kapp-controller-packaging-global -o json
Voici un exemple de commande :
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"
}
]
Pour afficher la liste des secrets d'authentification de registre au format de fichier YAML, exécutez les commandes suivantes :
tanzu secret registry list -n kapp-controller-packaging-global -o yaml
Voici un exemple de commande :
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
Pour afficher la liste des secrets d'authentification de registre dans un format de tableau, exécutez les commandes suivantes :
tanzu secret registry list -n kapp-controller-packaging-global -o table
Voici un exemple de commande :
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
Vous pouvez mettre à jour les informations d'identification dans un secret et rendre un secret disponible dans tous les espaces de noms, ou le rendre disponible dans un seul espace de noms du cluster.
Pour mettre à jour le secret dans l'espace de noms dans lequel il a été créé, exécutez la commande suivante :
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD
Où :
SECRET-NAME
est le nom du secret de registre que vous souhaitez mettre à jour.NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.USERNAME
est le nouveau nom d'utilisateur permettant d'accéder au registre (si vous souhaitez mettre à jour le nom d'utilisateur).PASSWORD
est le nouveau mot de passe du registre (si vous souhaitez mettre à jour le mot de passe).Remarquevous pouvez mettre à jour le nom d'utilisateur ou le mot de passe, ou les deux.
Voici un exemple de commande :
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'
Pour mettre à jour le secret d'authentification du registre et le rendre disponible dans d'autres espaces de noms du cluster, exécutez la commande suivante :
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true
Où :
SECRET-NAME
est le nom du secret de registre que vous souhaitez mettre à jour.NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.USERNAME
est le nom d'utilisateur permettant d'accéder au registre. Entrez un nouveau nom d'utilisateur si vous souhaitez mettre à jour le nom d'utilisateur.PASSWORD
est le mot de passe du registre. Entrez un nouveau mot de passe si vous souhaitez mettre à jour le mot de passe.Voici un exemple de commande :
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
Pour rendre un secret d'authentification de registre indisponible dans les autres espaces de noms du cluster, exécutez la commande suivante :
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false
Où :
SECRET-NAME
est le nom du secret de registre que vous souhaitez mettre à jour.NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid dans lequel vous mettez à jour le secret d'authentification du registre.USERNAME
est le nom d'utilisateur permettant d'accéder au registre.PASSWORD
est le mot de passe du registre.Voici un exemple de commande :
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
À l'aide de la CLI Tanzu, vous pouvez supprimer un secret d'authentification de registre dans un cluster. Pour supprimer un secret d'authentification de registre dans un espace de noms spécifique, exécutez la commande suivante :
tanzu secret registry delete SECRET-NAME -n NAMESPACE
Où :
SECRET-NAME
est le nom du secret de registre que vous souhaitez supprimer.NAMESPACE
est l'espace de noms Tanzu Kubernetes Grid à partir duquel vous souhaitez supprimer le secret d'authentification du registre. Si vous ne spécifiez pas d'espace de noms, le secret d'authentification est supprimé de l'espace de noms par défaut. Si le secret a été exporté vers d'autres espaces de noms dans le cluster, il est également supprimé.Voici un exemple de commande :
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'