클러스터 암호 관리

이 항목에서는 다음을 포함하여 Tanzu Kubernetes Grid의 워크로드 클러스터에 사용되는 암호를 구성하고 관리하는 방법을 설명합니다.

워크로드 클러스터 자격 증명 업데이트

vSphere 또는 Azure에 액세스하는 데 사용하는 자격 증명이 변경되면 새 자격 증명을 사용하도록 클러스터를 업데이트할 수 있습니다. AWS는 자격 증명을 다르게 처리하므로 이 섹션은 vSphere 및 Azure에만 적용됩니다.

vSphere
독립형 관리 및 워크로드 클러스터 자격 증명 업데이트

현재 독립형 관리 클러스터 및 모든 워크로드 클러스터에서 사용하는 vSphere 자격 증명을 업데이트하려면 tanzu mc credentials update --cascading 명령을 사용합니다.

  1. tanzu login을 실행하여 업데이트 중인 관리 클러스터에 로그인합니다.

  2. tanzu mc credentials update를 실행합니다. 다음 명령 옵션에 값을 전달하거나 CLI에서 값을 묻는 메시지를 표시하도록 할 수 있습니다.

    • --vsphere-user: vSphere 계정의 이름.
    • --vsphere-password: vSphere 계정의 암호.

독립형 관리 클러스터 자격 증명만 업데이트

워크로드 클러스터에 대해 업데이트하지 않고 독립형 관리 클러스터의 vSphere 자격 증명을 업데이트하려면 위에서와 같이 tanzu mc credentials update 명령을 사용하지만 --cascading 옵션을 사용하지 않습니다.

워크로드 클러스터 자격 증명 업데이트

단일 워크로드 클러스터가 vSphere에 액세스하는 데 사용하는 자격 증명을 업데이트하려면 tanzu cluster credentials update 명령을 사용합니다.

  1. tanzu login을 실행하여 업데이트 중인 워크로드 클러스터를 생성한 관리 클러스터에 로그인합니다. 관리 클러스터는 Supervisor 클러스터 또는 독립형 관리 클러스터일 수 있습니다.

  2. 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 명령을 사용합니다.

  1. tanzu login을 실행하여 업데이트 중인 관리 클러스터에 로그인합니다.

  2. 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 명령을 사용합니다.

  1. tanzu login을 실행하여 업데이트 중인 워크로드 클러스터를 생성한 관리 클러스터에 로그인합니다.

  2. 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년 동안 유효합니다. 클러스터를 갱신하려면 클러스터를 업그레이드하거나 아래 절차를 따릅니다. 이 절차는 만료되지 않았으며 여전히 유효한 클러스터 인증서를 위한 것입니다.

  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
    
  2. 인증서의 만료 날짜를 확인합니다.

    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
    
  3. kubectl 컨텍스트를 관리 클러스터로 설정합니다. 예:

    kubectl config use-context mgmt-slot35rp10-admin@mgmt-slot35rp10
    
  4. 대상 클러스터의 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
    
  5. 제어부 롤아웃을 트리거하여 인증서를 갱신합니다.

    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
    ...
    
  6. 모든 시스템이 Running인 경우 인증서 갱신이 성공적으로 완료되었는지 확인합니다.

    1. kubectl 컨텍스트를 워크로드 클러스터로 설정합니다.

      kubectl config use-context workload-slot35rp10-admin@workload-slot35rp10
      
    2. 인증서의 만료 날짜를 다시 확인합니다.

      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 설명서에서 다음 항목을 참조하십시오.

신뢰할 수 있는 여러 레지스트리를 사용하여 클러스터 구성(독립형 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 오버레이를 참조하십시오.

  1. 모든 새 클러스터에 사용자 지정 CA를 적용할지, 하나의 클라우드 인프라에서 생성된 클러스터만 적용할지 또는 특정 클러스터 API 제공자 버전(예: Cluster API 제공자 vSphere v1.5.1)으로 생성되었는지를 선택합니다.

  2. 로컬 ~/.config/tanzu/tkg/providers/ 디렉토리에서 선택한 범위를 포함하는 ytt 디렉토리를 찾습니다. 예를 들어 /ytt/03_customizations/는 모든 클러스터에 적용되고 /infrastructure-vsphere/ytt/는 모든 vSphere 클러스터에 적용합니다.

  3. 선택한 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)'
    
  4. 동일한 ytt 디렉토리에서 CA(인증 기관)를 새 파일 또는 기존 tkg-custom-ca.pem 파일에 추가합니다.

  5. 클러스터를 생성하기 전에 (레거시) 계획 기반 또는 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.variablesimageRepositorytopology.variablestrust 블록은 TKG_CUSTOM_IMAGE_REPOSITORY_*TKG_PROXY_CA_CERT 구성 변수의 값을 설정합니다.

계획 기반 클러스터를 사용자 지정 레지스트리 신뢰로 만들기

자체 서명된 CA를 사용하여 기존 계획 기반 클러스터와 Harbor 레지스트리 간에 신뢰할 수 있는 통신을 사용하는 방법:

  1. Harbor CA 인증서를 검색합니다.

    1. 공유 서비스 클러스터와 같이 Harbor를 실행하는 클러스터로 컨텍스트를 전환합니다.

      kubectl config use-context SERVICES-CLUSTER-CONTEXT
      

      여기서 SERVICES-CLUSTER-CONTEXT는 클러스터의 컨텍스트입니다. 예: tkg-wld-admin@tkg-wld.

    2. 인증서를 검색합니다.

      kubectl -n tanzu-system-registry get secret harbor-tls -o=jsonpath="{.data.ca\.crt}" | base64 -d
      -----BEGIN CERTIFICATE-----
      MIIFazCCA1OgAwIBAgIQMfZy08muvIVKdZVDz7/rYzANBgkqhkiG9w0BAQsFADBI
      [...]
      yiDghW7antzYL9S1CC8sVgVOwFJwfFXpdiir35mQlySG301V4FsRV+Z0cFp4Ni0=
      -----END CERTIFICATE-----
      
  2. 독립형 관리 클러스터의 kubeadmconfigtemplate에 사용자 지정 CA를 추가합니다.

    1. 컨텍스트를 관리 클러스터로 전환합니다.

      kubectl config use-context MANAGEMENT-CLUSTER-CONTEXT
      

      여기서 MANAGEMENT-CLUSTER-CONTEXT는 관리 클러스터의 컨텍스트입니다. 예: tkg-mgmt-admin@tkg-mgmt.

    2. 편집기에서 클러스터의 kubeadmconfigtemplate 템플릿 파일을 엽니다.

      kubectl edit kubeadmconfigtemplate CLUSTER-NAME-md-0
      

      여기서 CLUSTER-NAME은 수정해야 하는 클러스터의 이름입니다.

    3. 여기에 표시된 것처럼 파일의 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"
      
    4. 파일의 맨 아래에 다음과 같이 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)'
      
  3. kubeadmconfigtemplate 템플릿 파일을 변경 내용과 함께 저장합니다.

  4. 다음과 같은 변경 사항을 적용하여 독립형 관리 클러스터에 패치를 적용합니다.

    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'
check-circle-line exclamation-circle-line close-line
Scroll to top icon