클러스터 암호 관리
이 항목에서는 다음을 포함하여 Tanzu Kubernetes Grid의 워크로드 클러스터에 사용되는 암호를 구성하고 관리하는 방법을 설명합니다.
- 클러스터가 클라우드 인프라 API 및 리소스에 액세스하는 데 사용하는 자격 증명입니다. 클러스터 자격 증명 업데이트를 참조하십시오.
- 내부 클러스터 구성 요소가 요청을 인증하는 데 사용하는 클라이언트 인증서(독립형 관리 클러스터 배포 워크로드 클러스터만 해당). 클러스터 인증서 갱신을 참조하십시오.
- 클러스터가 개인 컨테이너 레지스트리에 액세스하는 데 사용하는 CA(인증 기관) 인증서입니다. 신뢰할 수 있는 여러 개의 레지스트리로 클러스터 구성 및 기존 클러스터에 사용자 지정 CA 인증서 신뢰 추가를 참조하십시오
- 클러스터가 인증된 개인 컨테이너 레지스트리에 액세스하는 데 사용하는 자격 증명입니다. 개인 컨테이너 레지스트리에 대한 인증 구성을 참조하십시오.
워크로드 클러스터 자격 증명 업데이트
vSphere 또는 Azure에 액세스하는 데 사용하는 자격 증명이 변경되면 새 자격 증명을 사용하도록 클러스터를 업데이트할 수 있습니다. AWS는 자격 증명을 다르게 처리하므로 이 섹션은 vSphere 및 Azure에만 적용됩니다.
- vSphere
-
독립형 관리 및 워크로드 클러스터 자격 증명 업데이트
현재 독립형 관리 클러스터 및 모든 워크로드 클러스터에서 사용하는 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 자격 증명을 업데이트할 수도 있습니다. -
- AWS
- 이 섹션은 AWS 배포에는 해당되지 않습니다.
- Azure
-
독립형 관리 및 워크로드 클러스터 자격 증명 업데이트
중요
시작하기 전에 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.
클러스터 인증서 갱신(독립형 MC)
독립형 관리 및 해당 워크로드 클러스터는 클라이언트 인증서를 사용하여 요청을 인증합니다. 이러한 인증서는 1년 동안 유효합니다. 클러스터를 갱신하려면 클러스터를 업그레이드하거나 아래 절차를 따릅니다. 이 절차는 만료되지 않았으며 여전히 유효한 클러스터 인증서를 위한 것입니다.
-
인증서를 갱신할 클러스터를 식별합니다. 예:
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클러스터 노드를 나열하려면 다음을 실행합니다.
kubectl get nodes -o wide -
인증서의 만료 날짜를 확인합니다.
- vSphere
-
다음 명령을 실행합니다.
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; - AWS
-
다음 명령을 실행합니다.
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; - Azure
-
다음 명령을 실행합니다.
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.25.7+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.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 ... -
모든 시스템이
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 노드의 인증서가 자동으로 갱신됩니다.
-
신뢰할 수 있는 레지스트리를 사용하여 클러스터 구성(Supervisor)
TKG 외부의 개인 컨테이너 레지스트리를 사용하도록 Supervisor 배포 TKG 클러스터를 구성하려면, 즉 TKG 클러스터에서 실행되지 않는 자체 서명된 인증서가 있는 레지스트리를 구성하려면 vSphere 설명서에서 다음 항목을 참조하십시오.
- vSphere 8: TKG 2 클러스터를 개인 컨테이너 레지스트리와 통합
- vSphere 7: Tanzu Kubernetes 클러스터에서 외부 컨테이너 레지스트리 사용
신뢰할 수 있는 여러 레지스트리를 사용하여 클러스터 구성(독립형 MC)
독립형 관리 클러스터가 있는 인터넷 제한 환경에서 TKG 클러스터에 부트스트랩할 TKG 시스템 이미지가 포함된 개인 레지스트리(예: vSphere 오프라인 Harbor 레지스트리 배포에 설명된 대로 Harbor VM)에 대한 액세스 권한을 부여하도록 TKG_CUSTOM_IMAGE_REPOSITORY_* 변수를 구성할 수 있습니다.
ADDITIONAL_IMAGE_REGISTRY_* 변수는 자체 서명된 CA(인증 기관) 인증서를 사용하는 추가 레지스트리와의 신뢰할 수 있는 통신을 갖도록 새 클러스터를 구성합니다. 예를 들면 다음과 같습니다.
- CLI 관리 패키지를 설치하기 위한 패키지 저장소 역할을 하는 개인 레지스트리입니다.
- 서비스 레지스트리용 Harbor 설치에 설명된 대로 Harbor 패키지와 함께 배포된 TKG 호스팅 애플리케이션 이미지에 대한 확장 가능한 자체 서명된 Harbor 레지스트리입니다.
containerd저장소의 구성 이미지 레지스트리에 설명된 대로containerd에 대한 자체 서명된 이미지 레지스트리입니다.
이러한 추가 개인 레지스트리를 신뢰하도록 클러스터를 구성하는 방법은 아래 설명된 대로 클러스터가 계획 기반인지 클래스 기반인지에 따라 다릅니다.
클래스 기반 클러스터에 대해 신뢰할 수 있는 레지스트리
추가 사용자 지정 이미지 레지스트리에 대한 신뢰를 사용하여 클래스 기반 워크로드 클러스터 또는 독립형 관리 클러스터를 구성하려면 최대 3개의 추가 이미지 레지스트리에 대해 아래와 같이 변수를 설정합니다.
-
3개 이상의 레지스트리를 구성하려면 클래스 기반 클러스터 생성에 설명된 2단계 프로세스의 1단계에서 아래와 같이 처음 3개를 구성한 다음 클래스 기반 클러스터를 사용자 지정 레지스트리로 만들기에 따라 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"여기서
OTHER-REGISTRY-<n>는 추가 개인 레지스트리의 IP 주소 또는 FQDN이고,CA-BASE64-<n>는http://접두사 없이 base64로 인코딩된 형식의 CA 인증서입니다. 이 파일은 디스크에 기록되므로 일반적인 Unix 파일 이름이어야 하기 때문에 필요합니다.
새 계획 기반 클러스터에 대한 신뢰할 수 있는 레지스트리
자체 서명된 인증서를 사용하는 컨테이너 레지스트리에서 이미지를 끌어오기 위해 새 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 인증서 신뢰 추가(독립형 MC)
기존 클러스터와 자체 서명된 CA가 있는 추가 사용자 지정 Harbor 레지스트리 간에 신뢰할 수 있는 통신을 사용하도록 설정할 수 있습니다. TKG_CUSTOM_IMAGE_REPOSITORY_* 구성 변수에서 설정한 것 외에 containerd TLS 및 기타 용도로 사용할 수 있습니다. 이 작업을 수행하는 방법은 아래 설명된 대로 클러스터가 계획 기반인지 클래스 기반인지에 따라 다릅니다.
클래스 기반 클러스터를 사용자 지정 레지스트리로 만들기
신뢰할 수 있는 사용자 지정 레지스트리를 기존 클래스 기반 클러스터에 추가하려면 해당 Cluster 개체를 편집하고 개체 규격의 topology.variables 아래에 additionalImageRegistries 설정을 추가합니다.
topology:
variables:
- name: additionalImageRegistries
value:
- caCert: "CA-BASE64"
host: OTHER-REGISTRY
skipTlsVerify: false
여기서:
OTHER-REGISTRY는 형식에 따라 추가 개인 레지스트리 위치입니다.: . 예: 10.92.127.192:8443.CA-BASE64는 base64로 인코딩된 형식의 CA 인증서입니다(예:LS0tLS1CRU[...].
여러 레지스트리에 대한 신뢰를 추가하려면 여러 additionalImageRegistries 값 블록을 포함합니다.
topology.variables 및 imageRepositorytopology.variablestrust 블록은 TKG_CUSTOM_IMAGE_REPOSITORY_* 및 TKG_PROXY_CA_CERT 구성 변수의 값을 설정합니다.
계획 기반 클러스터를 사용자 지정 레지스트리 신뢰로 만들기
자체 서명된 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'
