이 항목에서는 다음을 포함하여 Tanzu Kubernetes Grid의 워크로드 클러스터에 사용되는 암호를 구성하고 관리하는 방법을 설명합니다.
vSphere 또는 Azure에 액세스하는 데 사용하는 자격 증명이 변경되면 새 자격 증명을 사용하도록 클러스터를 업데이트할 수 있습니다. AWS는 자격 증명을 다르게 처리하므로 이 섹션은 vSphere 및 Azure에만 적용됩니다.
현재 독립형 관리 클러스터 및 모든 워크로드 클러스터에서 사용하는 vSphere 자격 증명을 업데이트하려면 tanzu mc credentials update --cascading
명령을 사용합니다.
tanzu login
을 실행하여 업데이트 중인 관리 클러스터에 로그인합니다.
tanzu mc credentials update
를 실행합니다. 다음 명령 옵션에 값을 전달하거나 CLI에서 값을 묻는 메시지를 표시하도록 할 수 있습니다.
--vsphere-user
: vSphere 계정의 이름.--vsphere-password
: vSphere 계정의 암호.워크로드 클러스터에 대해 업데이트하지 않고 독립형 관리 클러스터의 vSphere 자격 증명을 업데이트하려면 위에서와 같이 tanzu mc credentials update
명령을 사용하지만 --cascading
옵션을 사용하지 않습니다.
단일 워크로드 클러스터가 vSphere에 액세스하는 데 사용하는 자격 증명을 업데이트하려면 tanzu cluster credentials update
명령을 사용합니다.
tanzu login
을 실행하여 업데이트 중인 워크로드 클러스터를 생성한 관리 클러스터에 로그인합니다. 관리 클러스터는 Supervisor 클러스터 또는 독립형 관리 클러스터일 수 있습니다.
tanzu cluster credentials update CLUSTER-NAME
을 실행합니다. 다음 명령 옵션에 값을 전달하거나 CLI에서 값을 묻는 메시지를 표시하도록 할 수 있습니다.
--namespace
: 자격 증명을 업데이트하는 클러스터의 네임스페이스입니다(예: default
).--vsphere-user
: vSphere 계정의 이름.--vsphere-password
: vSphere 계정의 암호.tanzu mc credentials update --cascading
을 사용하여 관리 클러스터 및 관리하는 모든 워크로드 클러스터에 대한 vSphere 자격 증명을 업데이트할 수도 있습니다.
중요시작하기 전에 Azure Portal 또는 Azure 관리자로부터 새 Azure 자격 증명을 받습니다.
현재 독립형 관리 클러스터 및 모든 워크로드 클러스터에서 사용하는 Azure 자격 증명을 업데이트하려면 tanzu mc credentials update --cascading
명령을 사용합니다.
tanzu login
을 실행하여 업데이트 중인 관리 클러스터에 로그인합니다.
tanzu mc credentials update
를 실행합니다. 다음 명령 옵션에 값을 전달하거나 CLI에서 값을 묻는 메시지를 표시하도록 할 수 있습니다.
--azure-client-id
: Azure에 등록한 Tanzu Kubernetes Grid 애플리케이션의 클라이언트 ID입니다.--azure-client-secret
: Azure에 등록한 Tanzu Kubernetes Grid 애플리케이션의 클라이언트 암호입니다.--azure-tenant-id
: Tanzu Kubernetes Grid용 앱이 있는 Azure Active Directory의 테넌트 ID입니다.워크로드 클러스터에 대해 업데이트하지 않고 독립형 관리 클러스터의 Azure 자격 증명을 업데이트하려면 위에서와 같이 tanzu mc credentials update
명령을 사용하지만 --cascading
옵션을 사용하지 않습니다.
단일 워크로드 클러스터가 Azure에 액세스하는 데 사용하는 자격 증명을 업데이트하려면 tanzu cluster credentials update
명령을 사용합니다.
tanzu login
을 실행하여 업데이트 중인 워크로드 클러스터를 생성한 관리 클러스터에 로그인합니다.
tanzu cluster credentials update CLUSTER-NAME
을 실행합니다. 다음 명령 옵션에 값을 전달하거나 CLI에서 값을 묻는 메시지를 표시하도록 할 수 있습니다.
--namespace
: 자격 증명을 업데이트하는 클러스터의 네임스페이스입니다(예: default
).--azure-client-id
: Azure에 등록한 Tanzu Kubernetes Grid 애플리케이션의 클라이언트 ID입니다.--azure-client-secret
: Azure에 등록한 Tanzu Kubernetes Grid 애플리케이션의 클라이언트 암호입니다.--azure-tenant-id
: Tanzu Kubernetes Grid용 앱이 있는 Azure Active Directory의 테넌트 ID입니다.tanzu mc credentials update --cascading
을 사용하여 관리 클러스터 및 관리하는 모든 워크로드 클러스터에 대한 Azure 자격 증명을 업데이트할 수도 있습니다.
구성 방법 및 클러스터 유형에 따라 다음과 같이 제어부 노드 VM 인증서를 자동으로 갱신하도록 TKG 클러스터를 구성합니다.
Kubernetes 스타일 개체 규격(클래스 기반 클러스터):
Cluster
개체 규격에서 spec.topology.variables
아래에 다음 블록을 포함합니다.
- name: controlPlaneCertificateRotation.activate
value: true
- name: controlPlaneCertificateRotation.daysBefore
value: EXPIRY-DAYS
플랫 클러스터 구성 파일(클래스 기반 또는 레거시 클러스터):
클러스터 구성 파일에 다음 설정을 포함합니다.
CONTROLPLANE_CERTIFICATE_ROTATION_ENABLED: true
CONTROLPLANE_CERTIFICATE_ROTATION_DAYS_BEFORE: EXPIRY-DAYS
여기서 EXPIRY-DAYS
는 인증서 만료 날짜 전의 일 수에 대한 선택적 설정으로, 클러스터 노드 인증서를 자동으로 갱신합니다. 기본값: 90; 최소: 7.
독립형 관리 및 해당 워크로드 클러스터는 클라이언트 인증서를 사용하여 요청을 인증합니다. 이러한 인증서는 1년 동안 유효합니다. 클러스터를 갱신하려면 클러스터를 업그레이드하거나 아래 절차를 따릅니다. 이 절차는 만료되지 않았으며 여전히 유효한 클러스터 인증서를 위한 것입니다.
인증서를 갱신할 클러스터를 식별합니다. 예:
tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR
workload-slot35rp10 default running 3/3 3/3 v1.24.10+vmware.1 <none> prod v1.24.10---vmware.2-tkg.1
클러스터 노드를 나열하려면 다음을 실행합니다.
kubectl get nodes -o wide
인증서의 만료 날짜를 확인합니다.
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;
샘플 출력:
######
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
kubectl
컨텍스트를 관리 클러스터로 설정합니다. 예:
kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
대상 클러스터의 KCP 개체 이름을 가져옵니다. 예:
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.24.10+vmware.1
제어부 롤아웃을 트리거하여 인증서를 갱신합니다.
kubectl patch kcp workload-slot35rp10-control-plane --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}
이 명령을 실행하면 Tanzu Kubernetes Grid는 클러스터 시스템 프로비저닝을 다시 시작합니다.
kubectl get machines
workload-slot35rp10-control-plane-7z95k workload-slot35rp10 Provisioning 20s v1.24.10+vmware.1
workload-slot35rp10-control-plane-ggsmj workload-slot35rp10 workload-slot35rp10-control-plane-ggsmj vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f Running 42h v1.24.10+vmware.1
workload-slot35rp10-control-plane-hxbxb workload-slot35rp10 workload-slot35rp10-control-plane-hxbxb vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd Running 42h v1.24.10+vmware.1
workload-slot35rp10-control-plane-sm4nw workload-slot35rp10 workload-slot35rp10-control-plane-sm4nw vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce Running 42h v1.24.10+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.24.10+vmware.1
...
모든 시스템이 Running
인 경우 인증서 갱신이 성공적으로 완료되었는지 확인합니다.
kubectl
컨텍스트를 워크로드 클러스터로 설정합니다.
kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
인증서의 만료 날짜를 다시 확인합니다.
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;
샘플 출력:
######
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
인증서 갱신이 성공적으로 완료되면 Residual Time
열에 364d
가 표시됩니다. Worker 노드의 인증서가 자동으로 갱신됩니다.
TKG 외부의 개인 컨테이너 레지스트리를 사용하도록 Supervisor 배포 TKG 클러스터를 구성하려면, 즉 TKG 클러스터에서 실행되지 않는 자체 서명된 인증서가 있는 레지스트리를 구성하려면 vSphere 설명서에서 다음 항목을 참조하십시오.
TKG_CUSTOM_IMAGE_REPOSITORY_*
변수는 자체 서명된 CA(인증 기관) 인증서를 사용하는 Harbor 레지스트리와의 신뢰할 수 있는 통신을 구축하도록 새 클러스터를 구성합니다(예: 인터넷 제한 환경의 사용자 지정 레지스트리에서 TKG 이미지를 끌어오기).
containerd
TLS 및 기타 용도에 대한 추가 개인 레지스트리를 신뢰하도록 클러스터를 구성할 수 있습니다. 이 작업을 수행하는 방법은 아래 설명된 대로 클러스터가 계획 기반인지 클래스 기반인지에 따라 다릅니다.
추가 사용자 지정 이미지 레지스트리에 대한 신뢰로 구성된 클래스 기반 클러스터를 생성하려면 다음을 수행합니다.
클래스 기반 클러스터 생성에 설명된 2단계 프로세스의 1단계에 따라 새 클러스터 매니페스트를 생성합니다.
생성된 매니페스트의 topology.variables
아래에 있는 trust
설정을 편집하여 additionalTrustedCAs
블록을 추가합니다.
topology:
variables:
- name: trust
value:
additionalTrustedCAs:
- data: CA-BASE64
- name: proxy
여기서 CA-BASE64
는 base64로 인코딩된 형식의 CA 인증서입니다.
trust
변수 블록에는 TKG_CUSTOM_IMAGE_REPOSITORY_CA_CERTIFICATE
및 TKG_PROXY_CA_CERT
구성 변수에서 설정된 값이 이미 포함되어 있습니다.
수정된 매니페스트를 사용하여 tanzu cluster create
를 2단계 클러스터 생성 프로세스의 2단계로 실행합니다.
자체 서명된 인증서를 사용하는 컨테이너 레지스트리에서 이미지를 끌어오기 위해 새 TKC 또는 계획 기반 클러스터를 사용하도록 설정하려면 ytt
오버레이 파일을 사용하여 워크로드 클러스터 노드에 사용자 지정 인증서를 추가합니다.
아래 오버레이 코드는 새 클러스터의 모든 노드에 사용자 지정 CA 인증서를 추가합니다. 코드는 Photon 또는 Ubuntu VM 이미지 템플릿을 기반으로 하는 클러스터의 모든 클라우드 대상 플랫폼에서 작동합니다.
클러스터를 사용자 지정하고 새 클러스터 계획을 생성하는 오버레이는 ytt
오버레이를 참조하십시오.
모든 새 클러스터에 사용자 지정 CA를 적용할지, 하나의 클라우드 인프라에서 생성된 클러스터만 적용할지 또는 특정 클러스터 API 제공자 버전(예: Cluster API 제공자 vSphere v1.5.1)으로 생성되었는지를 선택합니다.
로컬 ~/.config/tanzu/tkg/providers/
디렉토리에서 선택한 범위를 포함하는 ytt
디렉토리를 찾습니다. 예를 들어 /ytt/03_customizations/
는 모든 클러스터에 적용되고 /infrastructure-vsphere/ytt/
는 모든 vSphere 클러스터에 적용합니다.
선택한 ytt
디렉토리에서 새 .yaml
파일을 생성하거나 다음 코드로 기존 오버레이 파일을 확대합니다.
#@ 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)'
동일한 ytt
디렉토리에서 CA(인증 기관)를 새 파일 또는 기존 tkg-custom-ca.pem
파일에 추가합니다.
클러스터를 생성하기 전에 (레거시) 계획 기반 또는 TKC 클러스터 생성에 설명된 대로 allow-legacy-cluster
기능을 true
로 설정합니다.
기존 클러스터와 자체 서명된 CA가 있는 추가 사용자 지정 Harbor 레지스트리 간에 신뢰할 수 있는 통신을 사용하도록 설정할 수 있습니다. TKG_CUSTOM_IMAGE_REPOSITORY_*
구성 변수에서 설정한 것 외에 containerd
TLS 및 기타 용도로 사용할 수 있습니다. 이 작업을 수행하는 방법은 아래 설명된 대로 클러스터가 계획 기반인지 클래스 기반인지에 따라 다릅니다.
신뢰할 수 있는 사용자 지정 레지스트리를 기존 클래스 기반 클러스터에 추가하려면 Cluster
개체를 편집하고, 위의 클래스 기반 클러스터의 신뢰할 수 있는 레지스트리에 설명된 대로 additionalTrustedCAs
값을 추가하고, 수정된 Cluster
규격을 적용합니다.
자체 서명된 CA를 사용하여 기존 계획 기반 클러스터와 Harbor 레지스트리 간에 신뢰할 수 있는 통신을 사용하는 방법:
Harbor CA 인증서를 검색합니다.
공유 서비스 클러스터와 같이 Harbor를 실행하는 클러스터로 컨텍스트를 전환합니다.
kubectl config use-context SERVICES-CLUSTER-CONTEXT
여기서 SERVICES-CLUSTER-CONTEXT
는 클러스터의 컨텍스트입니다. 예: tkg-wld-admin@tkg-wld
.
인증서를 검색합니다.
kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
-----BEGIN CERTIFICATE-----
MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
[...]
yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
-----END CERTIFICATE-----
독립형 관리 클러스터의 kubeadmconfigtemplate
에 사용자 지정 CA를 추가합니다.
컨텍스트를 관리 클러스터로 전환합니다.
kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
여기서 MANAGEMENT-CLUSTER-CONTEXT
는 관리 클러스터의 컨텍스트입니다. 예: tkg-mgmt-admin@tkg-mgmt
.
편집기에서 클러스터의 kubeadmconfigtemplate
템플릿 파일을 엽니다.
kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
여기서 CLUSTER-NAME
은 수정해야 하는 클러스터의 이름입니다.
여기에 표시된 것처럼 파일의 spec.template.spec.files
섹션을 인증서를 포함하도록 변경합니다.
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"
파일의 맨 아래에 다음과 같이 preKubeadmCommands
블록을 추가합니다.
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)'
kubeadmconfigtemplate
템플릿 파일을 변경 내용과 함께 저장합니다.
다음과 같은 변경 사항을 적용하여 독립형 관리 클러스터에 패치를 적용합니다.
kubectl patch machinedeployments.cluster.x-k8s.io tkg-test-md-0 --type merge -p "{\"spec\":{\"template\":{\"metadata\":{\"annotations\":{\"date\":\"`date +'%s'`\"}}}}}"
이 명령을 실행하면 클러스터 노드의 롤링 업데이트가 트리거되고 해당 타임 스탬프가 업데이트됩니다.
인증 암호를 추가하여 클러스터가 개인 컨테이너 레지스트리에 액세스할 수 있도록 할 수 있습니다. 이 경우 이미지를 풀하기 위해 사용자 인증이 필요합니다. 클러스터에서 액세스하는 개인 레지스트리에 대해 구성한 인증 암호를 보거나 업데이트하거나 삭제할 수도 있습니다.
Tanzu CLI를 사용하여 인증 암호를 추가하여 클러스터에서 개인 컨테이너 레지스트리에 액세스할 수 있습니다. 레지스트리 암호가 클러스터의 네임스페이스에 추가되면, 개인 레지스트리에서 호스팅되는 모든 패키지 저장소, 패키지, 컨테이너 이미지를 끌어올 수 있습니다. 이후에는 패키지 저장소 및 패키지 리소스를 클러스터에 추가할 수 있습니다.
이 절차를 수행하기 전에 개인 컨테이너 레지스트리의 사용자 이름과 암호를 가져옵니다.
개인 레지스트리에 인증 암호를 추가하려면 다음 명령을 실행합니다.
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD
형식 설명:
SECRET-NAME
은 추가하려는 레지스트리 인증 암호의 이름입니다.NAMESPACE
는 레지스트리가 속한 Tanzu Kubernetes Grid 네임스페이스입니다.USERNAME
은 레지스트리에 액세스하기 위한 사용자 이름입니다. 특수 문자가 포함된 경우 사용자 이름을 큰 따옴표로 래핑합니다.PASSWORD
는 레지스트리에 액세스하기 위한 암호입니다. 특수 문자가 포함되어 있으면 큰 따옴표로 암호를 래핑합니다. 다음 형식으로 암호를 지정할 수도 있습니다.
명령의 --password PASSWORD
문자열을 --password-env-var ENV-VAR
로 바꿔서 이미 구성한 환경 변수를 통해 암호를 지정합니다. 명령의 형식은 다음과 같습니다.
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-env-var ENV-VAR
명령의 --password PASSWORD
문자열을 --password-stdin
문자열로 바꿔서 표준 입력을 통해 암호를 지정하고 메시지가 표시되면 암호를 입력합니다. 명령의 형식은 다음과 같습니다.
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-stdin
명령의 --password PASSWORD
문자열을 --password-file PASSWORD-FILE
문자열로 바꿔서 암호 파일을 통해 암호를 지정합니다. 명령의 형식은 다음과 같습니다.
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password-file PASSWORD-FILE
필요한 경우 클러스터의 모든 네임스페이스에서 레지스트리 암호를 사용할 수 있도록 하려면 다음 형식에 표시된 --export-to-all-namespaces
옵션을 사용합니다.
tanzu secret registry add SECRET-NAME -n NAMESPACE --server REGISTRY-URL --username USERNAME --password PASSWORD --export-to-all-namespaces
다음은 이 명령의 샘플 출력입니다.
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'
기본 네임스페이스에서 레지스트리 인증 암호를 보거나 클러스터의 모든 네임스페이스를 볼 수 있습니다. 테이블 또는 JSON 또는 YAML 파일 형태로 암호를 볼 수 있습니다.
클러스터의 특정 네임스페이스에 있는 레지스트리 인증 암호를 보려면 다음을 실행합니다.
tanzu secret registry list -n NAMESPACE
여기서 NAMESPACE
는 레지스트리가 속한 Tanzu Kubernetes Grid 네임스페이스입니다.
다음은 이 명령의 예입니다.
tanzu secret registry list -n test-ns
/ Retrieving registry secrets...
NAME REGISTRY EXPORTED AGE
pkg-dev-reg registry.pivotal.io to all namespaces 15d
클러스터의 모든 네임스페이스에서 레지스트리 인증 암호 목록을 보려면 다음을 실행합니다.
tanzu secret registry list -A
다음은 이 명령의 예입니다.
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
레지스트리 인증 암호 목록을 JSON 파일 형식으로 보려면 다음 명령을 실행합니다.
tanzu secret registry list -n kapp-controller-packaging-global -o json
다음은 이 명령의 예입니다.
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"
}
]
YAML 파일 형식으로 레지스트리 인증 암호 목록을 보려면 다음을 실행합니다.
tanzu secret registry list -n kapp-controller-packaging-global -o yaml
다음은 이 명령의 예입니다.
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
레지스트리 인증 암호 목록을 테이블 형식으로 보려면 다음을 실행합니다.
tanzu secret registry list -n kapp-controller-packaging-global -o table
다음은 이 명령의 예입니다.
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
암호에서 자격 증명을 업데이트하거나 모든 네임스페이스에서 암호를 사용할 수 있도록 하거나 클러스터의 네임스페이스 하나에서만 사용할 수 있도록 할 수 있습니다.
암호가 생성된 네임스페이스에서 암호를 업데이트하려면 다음 명령을 실행합니다.
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD
형식 설명:
SECRET-NAME
은 업데이트하려는 레지스트리 암호의 이름입니다.NAMESPACE
는 레지스트리 인증 암호를 업데이트하는 Tanzu Kubernetes Grid 네임스페이스입니다.USERNAME
은 레지스트리에 액세스하기 위한 새 사용자 이름입니다(사용자 이름을 업데이트하려는 경우).PASSWORD
는 레지스트리의 새 암호입니다(암호를 업데이트하려는 경우).참고사용자 이름이나 암호를 업데이트하거나 둘 다 업데이트할 수 있습니다.
다음은 이 명령의 예입니다.
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'
레지스트리 인증 암호를 업데이트하고 클러스터의 다른 네임스페이스에서 사용할 수 있도록 하려면 다음 명령을 실행합니다.
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=true
형식 설명:
SECRET-NAME
은 업데이트하려는 레지스트리 암호의 이름입니다.NAMESPACE
는 레지스트리 인증 암호를 업데이트하는 Tanzu Kubernetes Grid 네임스페이스입니다.USERNAME
은 레지스트리에 액세스하기 위한 사용자 이름입니다. 사용자 이름을 업데이트하려면 새 사용자 이름을 입력합니다.PASSWORD
는 레지스트리의 암호입니다. 암호를 업데이트하려면 새 암호를 입력합니다.다음은 이 명령의 예입니다.
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
클러스터의 다른 네임스페이스에서 레지스트리 인증 암호를 사용할 수 없게 하려면 다음 명령을 실행합니다.
tanzu secret registry update SECRET-NAME --username USERNAME -n NAMESPACE --password PASSWORD --export-to-all-namespaces=false
형식 설명:
SECRET-NAME
은 업데이트하려는 레지스트리 암호의 이름입니다.NAMESPACE
는 레지스트리 인증 암호를 업데이트하는 Tanzu Kubernetes Grid 네임스페이스입니다.USERNAME
은 레지스트리에 액세스하기 위한 사용자 이름입니다.PASSWORD
는 레지스트리의 암호입니다.다음은 이 명령의 예입니다.
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
Tanzu CLI를 사용하여 클러스터에서 레지스트리 인증 암호를 삭제할 수 있습니다. 특정 네임스페이스에서 레지스트리 인증 암호를 삭제하려면 다음 명령을 실행합니다.
tanzu secret registry delete SECRET-NAME -n NAMESPACE
형식 설명:
SECRET-NAME
은 삭제하려는 레지스트리 암호의 이름입니다.NAMESPACE
는 레지스트리 인증 암호를 삭제하려는 Tanzu Kubernetes Grid 네임스페이스입니다. 네임스페이스를 지정하지 않으면 인증 암호가 기본 네임스페이스에서 삭제되었습니다. 암호를 클러스터의 다른 네임스페이스로 내보낸 경우에도 삭제되었습니다.다음은 이 명령의 예입니다.
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'