En este tema se explica cómo configurar y administrar secretos utilizados por los clústeres de carga de trabajo en Tanzu Kubernetes Grid, entre los que se incluyen:
Si cambian las credenciales que utiliza para acceder a vSphere o Azure, puede actualizar los clústeres para que usen las nuevas credenciales. AWS controla las credenciales de forma diferente, por lo que esta sección solo se aplica a vSphere y Azure.
Para actualizar las credenciales de vSphere utilizadas por el clúster de administración independiente actual y por todos sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update --cascading
:
Ejecute tanzu login
para iniciar sesión en el clúster de administración que va a actualizar.
Ejecute tanzu mc credentials update
. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
--vsphere-user
: Nombre de la cuenta de vSphere.--vsphere-password
: Contraseña de la cuenta de vSphere.Actualizar solo las credenciales del clúster de administración independiente
Para actualizar las credenciales de vSphere de un clúster de administración independiente sin actualizarlas también para sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update
como se indica anteriormente, pero sin la opción --cascading
.
Actualizar credenciales del clúster de carga de trabajo
Para actualizar las credenciales que utiliza un único clúster de carga de trabajo para acceder a vSphere, utilice el comando tanzu cluster credentials update
:
Ejecute tanzu login
para iniciar sesión en el clúster de administración que creó el clúster de carga de trabajo que va a actualizar. El clúster de administración puede ser el clúster supervisor o el clúster de administración independiente.
Ejecute tanzu cluster credentials update CLUSTER-NAME
. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
--namespace
: El espacio de nombres del clúster para el que está actualizando las credenciales como default
.--vsphere-user
: Nombre de la cuenta de vSphere.--vsphere-password
: Contraseña de la cuenta de vSphere.También puede utilizar tanzu mc credentials update --cascading
para actualizar las credenciales de vSphere para un clúster de administración y todos los clústeres de carga de trabajo que administra.
ImportanteAntes de comenzar, obtenga las nuevas credenciales de Azure del portal de Azure o del administrador de Azure.
Para actualizar las credenciales de Azure utilizadas por el clúster de administración independiente actual y por todos sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update --cascading
:
Ejecute tanzu login
para iniciar sesión en el clúster de administración que va a actualizar.
Ejecute tanzu mc credentials update
. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
--azure-client-id
: El identificador de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.--azure-client-secret
: El secreto de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.--azure-tenant-id
: El identificador de tenant para Active Directory de Azure en el que se encuentra la aplicación para Tanzu Kubernetes Grid.Actualizar solo las credenciales del clúster de administración independiente
Para actualizar las credenciales de Azure de un clúster de administración independiente sin actualizarlas también para sus clústeres de carga de trabajo, utilice el comando tanzu mc credentials update
como se indica anteriormente, pero sin la opción --cascading
.
Actualizar credenciales del clúster de carga de trabajo
Para actualizar las credenciales que utiliza un único clúster de carga de trabajo para acceder a Azure, utilice el comando tanzu cluster credentials update
:
Ejecute tanzu login
para iniciar sesión en el clúster de administración que creó el clúster de carga de trabajo que va a actualizar.
Ejecute tanzu cluster credentials update CLUSTER-NAME
. Puede transferir valores a las siguientes opciones de comando o permitir que la CLI le solicite:
--namespace
: El espacio de nombres del clúster para el que está actualizando las credenciales como default
.--azure-client-id
: El identificador de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.--azure-client-secret
: El secreto de cliente de la aplicación para Tanzu Kubernetes Grid que registró en Azure.--azure-tenant-id
: El identificador de tenant para Active Directory de Azure en el que se encuentra la aplicación para Tanzu Kubernetes Grid.También puede utilizar tanzu mc credentials update --cascading
para actualizar las credenciales de Azure para un clúster de administración y todos los clústeres de carga de trabajo que administra.
Configure los clústeres de TKG para renovar automáticamente sus certificados de máquina virtual de nodo del plano de control de la siguiente manera, según el método de configuración y el tipo de clúster:
Especificación de objeto de estilo Kubernetes (clústeres basados en clases):
En la especificación del objeto Cluster
, incluya el siguiente bloque en spec.topology.variables
:
- name: controlPlaneCertificateRotation.activate
value: true
- name: controlPlaneCertificateRotation.daysBefore
value: EXPIRY-DAYS
Archivo de configuración del clúster plano (clústeres basados en clases o heredados):
En el archivo de configuración del clúster, incluya los siguientes ajustes:
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
Donde EXPIRY-DAYS
es un ajuste opcional para el número de días antes de la fecha de caducidad del certificado para renovar automáticamente los certificados del nodo de clúster. Predeterminado: 90; mínimo: 7.
La administración independiente y sus clústeres de carga de trabajo utilizan certificados de cliente para autenticar solicitudes. Estos certificados son válidos durante un año. Para renovarlos, puede actualizar los clústeres o seguir el procedimiento que se indica a continuación. Este procedimiento está destinado a certificados de clúster que no han caducado y siguen siendo válidos.
Identifique el clúster para el que desea renovar sus certificados. Por ejemplo:
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
Para ver una lista de los nodos del clúster, ejecute:
kubectl get nodes -o wide
Compruebe la fecha de caducidad de los certificados:
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;
Resultados de muestra:
######
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
Establezca el contexto kubectl
en el clúster de administración. Por ejemplo:
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
Obtenga el nombre del objeto de KCP para el clúster de destino. Por ejemplo:
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
Renueve los certificados activando un lanzamiento del plano de control:
kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
Después de ejecutar este comando, Tanzu Kubernetes Grid comienza a aprovisionar de nuevo las máquinas del clúster:
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
...
Cuando todas las máquinas estén Running
, compruebe que la renovación del certificado se haya completado correctamente:
Establezca el contexto kubectl
en el clúster de carga de trabajo:
kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
Vuelva a comprobar la fecha de caducidad de los certificados:
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;
Resultados de muestra:
######
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 la renovación del certificado se completó correctamente, la columna Residual Time
muestra 364d
. Los certificados en los nodos de trabajo se renuevan automáticamente.
Para configurar un clúster de TKG implementado por Supervisor para que use un registro de contenedores privado externo a TKG, es decir, un registro con un certificado autofirmado que no se ejecuta en un clúster de TKG, consulte los siguientes temas en la documentación de vSphere:
En un entorno restringido por Internet con un clúster de administración independiente, puede configurar variables TKG_CUSTOM_IMAGE_REPOSITORY_*
para conceder a los clústeres de TKG acceso a un registro privado que contenga imágenes del sistema de TKG desde las que arrancar, por ejemplo, una máquina virtual de Harbor como se describe en Implementar un registro de Harbor sin conexión en vSphere.
Las variables ADDITIONAL_IMAGE_REGISTRY_*
configuran un nuevo clúster para que tenga comunicaciones de confianza con registros adicionales que usan certificados de entidad de certificación (CA) autofirmados, por ejemplo:
containerd
como se describe en Configurar registro de imágenes en el repositorio containerd
.La forma en que se configuran los clústeres para que confíen en estos registros privados adicionales depende de si el clúster está basado en planes o en clases, como se describe a continuación.
Para configurar un clúster de carga de trabajo basado en clases o un clúster de administración independiente con confianza para registros de imágenes personalizados adicionales, configure las variables como se indica a continuación para un máximo de tres registros de imágenes adicionales:
Para configurar más de tres registros, configure los tres primeros como se indica a continuación en el paso 1 de un proceso de dos pasos descrito en Crear un clúster basado en clases y, a continuación, siga Hacer que un clúster basado en clases confíe en un registro personalizado a continuación para agregar más registros al manifiesto generado antes de crear el clúster en el paso 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"
Donde OTHER-REGISTRY-<n>
es la dirección IP o el FQDN de un registro privado adicional y CA-BASE64-<n>
es su certificado de CA en formato codificado en base64, sin el prefijo http://
. Esto es necesario porque este archivo se escribirá en el disco, por lo que debe ser un nombre de archivo Unix normal.
Para habilitar un nuevo TKC o un clúster basado en planes para extraer imágenes de registros de contenedores que usan certificados autofirmados, agregue los certificados personalizados a los nodos del clúster de carga de trabajo mediante un archivo de superposición ytt
.
El código de superposición a continuación agrega certificados de CA personalizados a todos los nodos de un clúster nuevo. El código funciona en todas las plataformas de destino de nube para clústeres basados en plantillas de imagen de máquina virtual de Ubuntu o Photon.
Para las superposiciones que personalizan clústeres y crean un nuevo plan de clúster, consulte Superposicionesytt
.
Elija si desea aplicar la CA personalizada a todos los clústeres nuevos, solo los creados en una infraestructura de nube o los creados con una versión específica del proveedor de API del clúster, como Proveedor de API del clúster vSphere v1.5.1.
En el directorio local ~/.config/tanzu/tkg/providers/
busque el directorio ytt
que abarca el ámbito seleccionado. Por ejemplo, /ytt/03_customizations/
se aplica a todos los clústeres y /infrastructure-vsphere/ytt/
se aplica a todos los clústeres de vSphere.
En el directorio ytt
elegido, cree un nuevo archivo .yaml
o amplíe un archivo de superposición existente con el siguiente código:
#@ 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)'
En el mismo directorio ytt
, agregue la entidad de certificación a un archivo tkg-custom-ca.pem
nuevo o existente.
Antes de crear el clúster, establezca la función allow-legacy-cluster
en true
como se describe en (heredado) Crear un clúster basado en planes o un clúster de TKC.
Puede habilitar la comunicación de confianza entre un clúster existente y registros de Harbor personalizados adicionales con CA autofirmadas, además de las establecidas por las variables de configuración TKG_CUSTOM_IMAGE_REPOSITORY_*
, para TLS containerd
y otros usos. La forma de hacerlo depende de si el clúster está basado en planes o en clases, como se describe a continuación.
Para agregar un registro personalizado de confianza a un clúster basado en clases existente, edite su objeto Cluster
y agregue la configuración additionalImageRegistries
en topology.variables
en la especificación de objeto:
topology:
variables:
- name: additionalImageRegistries
value:
- caCert: "CA-BASE64"
host: OTHER-REGISTRY
skipTlsVerify: false
Donde:
OTHER-REGISTRY
es la ubicación del registro privado adicional, que sigue el formato
10.92.127.192:8443
.
CA-BASE64
es su certificado CA en formato codificado en base64, por ejemplo, LS0tLS1CRU[...]
.Para agregar confianza a varios registros, incluya varios bloques de valores additionalImageRegistries
.
Tenga en cuenta que los bloques topology.variables
para imageRepository
y trust
establecen valores a partir de las variables de configuración TKG_CUSTOM_IMAGE_REPOSITORY_*
y TKG_PROXY_CA_CERT
.
Para habilitar la confianza entre un clúster basado en un plan existente y un registro de Harbor con una CA autofirmada:
Recupere el certificado de CA de Harbor:
Cambie el contexto al clúster que ejecuta Harbor, como un clúster de servicios compartidos:
kubectl config use-context SERVICES-CLUSTER-CONTEXT
DondeSERVICES-CLUSTER-CONTEXT
es el contexto del clúster. Por ejemplo, tkg-wld-admin@tkg-wld
.
Recupere el certificado:
kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----
Agregue la CA personalizada al clúster de administración independiente kubeadmconfigtemplate
:
Cambie el contexto al clúster de administración.
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
Donde MANAGEMENT-CLUSTER-CONTEXT
es el contexto del clúster de administración. Por ejemplo, tkg-mgmt-admin@tkg-mgmt
.
En un editor, abra el archivo de plantilla kubeadmconfigtemplate
del clúster:
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
Donde CLUSTER-NAME
es el nombre del clúster que debe modificarse.
Cambie la sección spec.template.spec.files
del archivo para incluir el certificado, como se muestra aquí:
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"
En la parte inferior del archivo, agregue un bloque preKubeadmCommands
como se muestra aquí:
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)'
Guarde el archivo de plantilla kubeadmconfigtemplate
con los cambios.
Aplique las revisiones al clúster de administración independiente con los cambios siguientes:
kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
Al ejecutar este comando, se activa una actualización gradual de los nodos del clúster y se actualiza su marca de tiempo.
Puede agregar secretos de autenticación para permitir que un clúster acceda a un registro de contenedor privado, lo que requiere autenticación del usuario para extraer imágenes. También puede ver, actualizar o eliminar los secretos de autenticación que configuró para los registros privados a los que accede un clúster.
En la CLI de Tanzu puede agregar secretos de autenticación para acceder a un registro de contenedores privado desde un clúster. Después de agregar el secreto de registro a los espacios de nombres del clúster, puede extraer todos los repositorios de paquetes, los paquetes y las imágenes de contenedor que están alojados en el registro privado. Posteriormente, puede agregar el repositorio de paquetes y los recursos de paquetes al clúster.
Antes de realizar este procedimiento obtenga el nombre de usuario y la contraseña del registro de contenedores privado.
Para agregar un secreto de autenticación a un registro privado, ejecute el siguiente comando:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD
Donde:
SECRET-NAME
es el nombre del secreto de autenticación del registro que desea agregar.NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid al que pertenece el registro.USERNAME
es el nombre de usuario para acceder al registro. Ponga el nombre de usuario entre comillas simples si contiene caracteres especiales.PASSWORD
es la contraseña para acceder al registro. Ponga la contraseña entre comillas simples si contiene caracteres especiales. También puede especificar la contraseña en los siguientes formatos:
Reemplace la cadena --password PASSWORD
en el comando por --password-env-var ENV-VAR
para especificar la contraseña a través de la variable de entorno que ya configuró. El formato del comando es el siguiente:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR
Reemplace la cadena --password PASSWORD
en el comando por la cadena --password-stdin
para especificar la contraseña a través de la entrada estándar e introduzca la contraseña cuando se le solicite. El formato del comando es el siguiente:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin
Reemplace la cadena --password PASSWORD
en el comando por la cadena --password-file PASSWORD-FILE
para especificar la contraseña a través de un archivo de contraseñas. El formato del comando es el siguiente:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE
De forma opcional, para que el secreto de registro esté disponible en todos los espacios de nombres de un clúster, utilice la opción --export-to-all-namespaces
como se muestra en el siguiente formato:
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces
A continuación se muestra un ejemplo de resultados de este comando:
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'
Puede ver los secretos de autenticación del registro en el espacio de nombres predeterminado o en todos los espacios de nombres de un clúster. Puede ver los secretos en forma de una tabla o un archivo JSON o YAML.
Para ver los secretos de autenticación del registro en un espacio de nombres específico de un clúster, ejecute lo siguiente:
tanzu secret registry list -n NAMESPACE
Donde NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid al que pertenece el registro.
A continuación se muestra un ejemplo de este comando:
tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE
pkg-dev-reg registry.pivotal.io to all namespaces 15d
Para ver la lista de secretos de autenticación del registro en todos los espacios de nombres de un clúster, ejecute lo siguiente:
tanzu secret registry list -A
A continuación se muestra un ejemplo de este comando:
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
Para ver la lista de secretos de autenticación del registro en formato de archivo JSON, ejecute el siguiente comando:
tanzu secret registry list -n kapp-controller-packaging-global -o json
A continuación se muestra un ejemplo de este comando:
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"
}
]
Para ver la lista de secretos de autenticación del registro en formato de archivo YAML, ejecute lo siguiente:
tanzu secret registry list -n kapp-controller-packaging-global -o yaml
A continuación se muestra un ejemplo de este comando:
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
Para ver la lista de secretos de autenticación del registro en formato de tabla, ejecute lo siguiente:
tanzu secret registry list -n kapp-controller-packaging-global -o table
A continuación se muestra un ejemplo de este comando:
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
Puede actualizar las credenciales en un secreto y hacer que un secreto esté disponible en todos los espacios de nombres o ponerlo a disposición solo en un espacio de nombres del clúster.
Para actualizar el secreto en el espacio de nombres en el que se creó, ejecute el siguiente comando:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD
Donde:
SECRET-NAME
es el nombre del secreto del registro que desea actualizar.NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.USERNAME
es el nuevo nombre de usuario para acceder al registro (si desea actualizar el nombre de usuario).PASSWORD
es la nueva contraseña del registro (si desea actualizar la contraseña).NotaPuede actualizar el nombre de usuario o la contraseña o ambos.
A continuación se muestra un ejemplo de este comando:
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'
Para actualizar el secreto de autenticación del registro y ponerlo a disposición en otros espacios de nombres del clúster, ejecute el siguiente comando:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true
Donde:
SECRET-NAME
es el nombre del secreto del registro que desea actualizar.NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.USERNAME
es el nombre de usuario para acceder al registro. Introduzca un nuevo nombre de usuario si desea actualizar el nombre de usuario.PASSWORD
es la contraseña del registro. Introduzca una nueva contraseña si desea actualizar la contraseña.A continuación se muestra un ejemplo de este comando:
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
Para que un secreto de autenticación del registro no esté disponible en otros espacios de nombres del clúster, ejecute el siguiente comando:
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false
Donde:
SECRET-NAME
es el nombre del secreto del registro que desea actualizar.NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid donde se actualiza el secreto de autenticación del registro.USERNAME
es el nombre de usuario para acceder al registro.PASSWORD
es la contraseña del registro.A continuación se muestra un ejemplo de este comando:
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
Con la CLI de Tanzu, puede eliminar un secreto de autenticación del registro en un clúster. Para eliminar un secreto de autenticación del registro en un espacio de nombres específico, ejecute el siguiente comando:
tanzu secret registry delete SECRET-NAME -n NAMESPACE
Donde:
SECRET-NAME
es el nombre del secreto del registro que desea eliminar.NAMESPACE
es el espacio de nombres de Tanzu Kubernetes Grid del que desea eliminar el secreto de autenticación del registro. Si no especifica un espacio de nombres, el secreto de autenticación se elimina del espacio de nombres predeterminado. Si el secreto se exportó a otros espacios de nombres del clúster, también se elimina.A continuación se muestra un ejemplo de este comando:
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'