TKG 서비스 클러스터를 개인 컨테이너 레지스트리와 통합

TKG 서비스 클러스터를 개인 컨테이너 레지스트리와 통합하려면 이 항목을 참조하십시오.

개인 컨테이너 레지스트리 사용 사례

컨테이너 레지스트리는 컨테이너 이미지를 저장 및 공유하기 위한 중앙 집중식 저장소 역할을 하는 Kubernetes 배포에 중요한 기능을 제공합니다. 가장 일반적으로 사용되는 공용 컨테이너 레지스트리는 Docker Hub입니다. 개인 컨테이너 레지스트리 오퍼링은 많이 있습니다. VMware Harbor는 감독자와 함께 제공되는 오픈 소스, 클라우드 네이티브, 개인 컨테이너 레지스트리입니다.

개인 컨테이너 레지스트리 통합

개인 레지스트리를 TKG 서비스 클러스터와 통합하려면 HTTPS를 통해 개인 레지스트리 컨텐츠를 제공하도록 하나 이상의 자체 서명된 CA 인증서로 클러스터를 구성합니다. 이렇게 하려면 additionalTrustedCAs 값이 있는 trust 필드를 클러스터 규격에 포함합니다. TKGS 클러스터가 신뢰해야 하는 자체 서명된 CA 인증서는 원하는 수만큼 정의할 수 있습니다. 이 기능을 사용하면 인증서 목록을 쉽게 정의하고 순환이 필요한 인증서를 업데이트할 수 있습니다.

처음부터 클러스터를 생성할 때 개인 레지스트리 인증서를 구성하거나, 기존 클러스터를 업데이트하고 개인 레지스트리 인증서를 제공할 수 있습니다. 기존 클러스터를 편집하고 개인 레지스트리 인증서를 추가하려면 kubectl edit 메서드를 사용합니다. Kubectl용 텍스트 편집기 구성의 내용을 참조하십시오.

trust.additionalTrustedCAs 필드의 구현은 TKGS 클러스터 프로비저닝을 위해 지원되는 API마다 조금씩 다릅니다. 자세한 내용은 v1alpha3 API 신뢰 필드 및 v1beta1 API 신뢰 변수의 내용을 참조하십시오.

v1alpha3 API 예시

다음 예에서는 v1alpha3 API를 사용하여 프로비저닝된 TKG 서비스 클러스터를 CA 인증서를 사용하여 개인 컨테이너 레지스트리와 통합하는 방법을 보여줍니다.

TanzuKubernetesCluster v1alpha3 API를 사용할 경우, trust.additionalTrustedCAs 필드에는 각각 개인 레지스트리에 대한 TLS 인증서를 포함할 수 있는 하나 이상의 이름 데이터 쌍이 포함됩니다.

표 1. v1alpha3 API 신뢰 필드
필드	설명
`trust`	섹션 마커. 데이터를 허용하지 않습니다.
`additionalTrustedCAs`	섹션 마커. 각각에 대해 `name`과 `data`가 있는 인증서 어레이를 포함합니다.
`name`	CA 인증서의 사용자 정의 이름입니다.
`data`	이중 base64로 인코딩된 PEM 형식의 CA 인증서(`ca.crt`) 컨텐츠입니다. 참고: v1alpha3 API를 사용하려면 인증서 컨텐츠가 단일 base64로 인코딩되어야 합니다. 컨텐츠가 단일 base6로 인코딩되지 않은 경우 결과 PEM 파일을 처리할 수 없습니다.

다음 절차에 따라 Harbor 레지스트리 인증서를 사용하여 Harbor를 v1alpha3 API 클러스터와 통합합니다.

프로젝트 > 저장소 화면의 Harbor 웹 인터페이스에서 Harbor 레지스트리 인증서를 다운로드합니다.
CA 인증서 파일이 ca.crt로 다운로드됩니다.
CA 인증서의 컨텐츠를 단일 base64로 인코딩합니다.
- Linux: base64 -w 0 ca.crt
- Windows: https://www.base64encode.org/.

클러스터 규격에 trust.additionalTrustedCAs 필드를 포함하고 name 및 data 값으로 채웁니다.

#tkc-with-trusted-private-reg-cert.yaml
apiVersion: run.tanzu.vmware.com/v1alpha3
kind: TanzuKubernetesCluster
metadata:
  name: tkc01
  namespace: tkgs-cluster-ns
spec:
   topology:
     controlPlane:
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
     nodePools:
     - name: nodepool-01
       replicas: 3
       storageClass: tkgs-storage-policy
       vmClass: guaranteed-medium
       tkr:
         reference:
           name: v1.25.7---vmware.3-fips.1-tkg.1
   settings:
     storage:
       defaultClass: tkgs-storage-policy
     network:
       cni:
         name: antrea
       services:
         cidrBlocks: ["198.51.100.0/12"]
       pods:
         cidrBlocks: ["192.0.2.0/16"]
       serviceDomain: cluster.local
       trust:
         additionalTrustedCAs:
         - name: CompanyInternalCA-1
           data: LS0tLS1C...LS0tCg==
         - name: CompanyInternalCA-2
           data: MTLtMT1C...MT0tPg==

인증서를 순환하려면 클러스터 규격에 대해 kubectl edit을 실행하고 trust.additionalTrustedCAs.data 값을 업데이트한 다음 롤링 업데이트를 시작합니다.

v1beta1 API 예시

다음 예에서는 v1beta1 API를 사용하여 프로비저닝된 TKG 서비스 클러스터를 CA 인증서를 사용하여 개인 컨테이너 레지스트리와 통합하는 방법을 설명합니다.

개인 컨테이너 레지스트리를 Cluster v1beta1 API로 프로비저닝된 TKGS 클러스터와 통합하려면 trust변수를 사용하고 변수를 개인 레지스트리 인증서가 포함된 Kubernetes 암호로 채웁니다.

표 2. v1beta1 API 신뢰 변수
필드	설명
`trust`	섹션 마커. 데이터를 허용하지 않습니다.
`additionalTrustedCAs`	섹션 마커. 각각에 대한 이름이 있는 인증서 어레이를 포함합니다.
`name`	이중 base64로 인코딩된 PEM 형식의 CA 인증서가 포함된 Kubernetes 암호의 `data` 맵 필드에 대한 사용자 정의 이름입니다. 참고: v1beta1 API를 사용하려면 인증서 컨텐츠가 이중 base64로 인코딩되어야 합니다. 컨텐츠가 이중 base6로 인코딩되지 않은 경우 결과 PEM 파일을 처리할 수 없습니다.

다음 절차에 따라 Harbor 레지스트리 인증서를 사용하여 Harbor를 v1beta1 API 클러스터와 통합합니다.

프로젝트 > 저장소 화면의 Harbor 웹 인터페이스에서 Harbor 레지스트리 인증서를 다운로드합니다.
CA 인증서 파일이 ca.crt로 다운로드됩니다.
CA 인증서의 컨텐츠를 이중 base64로 인코딩합니다.
- Linux: base64 -w 0 ca.crt | base64 -w 0
- Windows: https://www.base64encode.org/.
다음 컨텐츠로 Kubernetes 암호 정의 YAML 파일을 생성합니다.
```
#additional-ca-1.yaml
apiVersion: v1
data:
  additional-ca-1: TFMwdExTMUNSGlSzZ3Jaa...VVNVWkpRMEMwdExTMHRDZz09
kind: Secret
metadata:
  name: cluster01-user-trusted-ca-secret
  namespace: tkgs-cluster-ns
type: Opaque
```
형식 설명:
- 암호의 data 맵 값은 CA 인증서의 이름(이 예에서는 additional-ca-1)인 사용자 정의 문자열이며, 값은 이중 base64로 인코딩된 인증서입니다.
- metadata 섹션에서 암호의 이름을 CLUSTER-NAME-user-trusted-ca-secret으로 지정합니다. 여기서 CLUSTER-NAME은 클러스터의 이름입니다. 이 암호는 클러스터와 동일한 vSphere 네임스페이스에서 생성해야 합니다.
Kubernetes 암호를 선언적으로 생성합니다.
```
kubectl apply -f additional-ca-1.yaml
```

암호 생성을 확인합니다.

kubeclt get secret -n tkgs-cluster-ns cluster01-user-trusted-ca-secret
NAME                                             TYPE     DATA   AGE
cluster01-user-trusted-ca-secret                 Opaque   12     2d22h

암호에 대한 데이터 맵의 이름(이 예에서는 additional-ca-1)을 참조하는 클러스터 규격에 trust 변수를 포함합니다.

#cluster-with-trusted-private-reg-cert.yaml
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: cluster01
  namespace: tkgs-cluster-ns
spec:
  clusterNetwork:
    services:
      cidrBlocks: ["198.52.100.0/12"]
    pods:
      cidrBlocks: ["192.101.2.0/16"]
    serviceDomain: "cluster.local"
  topology:
    class: tanzukubernetescluster
    version: v1.26.5+vmware.2-fips.1-tkg.1
    controlPlane:
      replicas: 3
    workers:
      machineDeployments:
        - class: node-pool
          name: node-pool-01
          replicas: 3
    variables:
      - name: vmClass
        value: guaranteed-medium
      - name: storageClass
        value: tkgs-storage-profile
      - name: defaultStorageClass
        value: tkgs-storage-profile
      - name: trust
        value:
          additionalTrustedCAs:
          - name: additional-ca-1

인증서를 순환하려면 새 암호를 생성하고 적절한 값으로 클러스터 규격을 편집합니다. 이렇게 하면 클러스터의 롤링 업데이트가 트리거됩니다.
참고: 시스템은 CLUSTER-NAME-user-trusted-ca-secret에 대한 변경 내용을 모니터링하지 않습니다. data 맵 값이 변경되어도 이러한 변경 내용이 클러스터에 반영되지 않습니다. trust.additionalTrustCAs에 대한 새 암호와 해당 데이터 맵 name을 생성해야 합니다.