TKG サービスクラスタとプライベートコンテナレジストリの統合

TKG サービスクラスタをプライベートコンテナレジストリと統合するには、このトピックを参照してください。

プライベートコンテナレジストリの使用事例

コンテナレジストリは、Kubernetes 環境に重要な機能を提供し、コンテナイメージを保存して共有するための一元的なリポジトリとして機能します。最もよく使用されるパブリックコンテナレジストリは Docker Hubです。プライベートコンテナレジストリのサービスは多数あります。VMware Harbor は、スーパーバイザーに付属するオープンソースのクラウドネイティブなプライベートコンテナレジストリです。

プライベートコンテナレジストリの統合

プライベートレジストリを TKG サービスクラスタと統合するには、1 つ以上の自己署名 CA 証明書を使用して、HTTPS 経由でプライベートレジストリコンテンツを提供するようにクラスタを構成します。そのためには、クラスタ仕様の trust フィールドに additionalTrustedCAs 値を設定します。TKGS クラスタが信頼する自己署名 CA 証明書は、いくつでも定義できます。この機能を使用すると、証明書のリストを簡単に定義し、ローテーションが必要な証明書を更新できます。

最初にクラスタを作成するときにプライベートレジストリ証明書を構成することも、既存のクラスタを更新してプライベートレジストリ証明書を指定することもできます。既存のクラスタを編集し、プライベートレジストリ証明書フィールドを追加するには、kubectl edit メソッドを使用してください。kubectl のテキストエディタの構成を参照してください。

trust.additionalTrustedCAs フィールドの実装は、TKGS クラスタのプロビジョニング用にサポートされている API 間で若干異なることに注意してください。詳細については、「v1alpha3 API の trust フィールド」および「v1beta1 API の trust 変数」を参照してください。

v1alpha3 API の例

次の例は、v1alpha3 API を使用してプロビジョニングされた TKG サービスクラスタを、CA 証明書を使用してプライベートコンテナレジストリと統合する方法を示しています。

TanzuKubernetesCluster v1alpha3 API では、 trust.additionalTrustedCAs フィールドには 1 つ以上の名前とデータのペアが含まれており、それぞれにプライベートレジストリの TLS 証明書を含めることができます。

表 1. v1alpha3 API の trust フィールド
フィールド	説明
`trust`	セクションマーカー。データを受け入れない。
`additionalTrustedCAs`	セクションマーカー。それぞれの `name` と `data` を示す証明書の配列が含まれます。
`name`	CA 証明書のユーザー定義名。
`data`	double 型の base64 エンコードの PEM 形式の CA 証明書 (`ca.crt`) の内容。注： v1alpha3 API では、証明書の内容を single 型の base64 エンコード形式にする必要があります。内容が single 型の base64 エンコード形式でない場合は、結果の PEM ファイルを処理できません。

Harbor レジストリ証明書を使用して Harbor を v1alpha3 API クラスタと統合するには、次の手順を実行します。

Harbor Web インターフェイスの [プロジェクト] > [リポジトリ] 画面で Harbor [レジストリ証明書] をダウンロードします。
CA 証明書ファイルが ca.crt としてダウンロードされます。
CA 証明書の内容を single 型の 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 証明書を使用してプライベートコンテナレジストリと統合する方法について説明します。

プライベートコンテナレジストリを、クラスタ v1beta1 API でプロビジョニングされた TKGS クラスタと統合するには、 trust 変数を使用して、プライベートレジストリ証明書を含む Kubernetes シークレットをポピュレートします。

表 2. v1beta1 API の trust 変数
フィールド	説明
`trust`	セクションマーカー。データを受け入れない。
`additionalTrustedCAs`	セクションマーカー。それぞれの名前を示す証明書の配列が含まれます。
`name`	double 型の base64 エンコードの PEM 形式の CA 証明書を含む Kubernetes シークレットの `data` マップフィールドのユーザー定義名。注： v1beta1 API では、証明書の内容を double 型の base64 エンコード形式にする必要があります。内容が double 型の base64 エンコード形式でない場合は、結果の PEM ファイルを処理できません。

Harbor レジストリ証明書を使用して Harbor を v1beta1 API クラスタと統合するには、次の手順を実行します。

Harbor Web インターフェイスの [プロジェクト] > [リポジトリ] 画面で Harbor [レジストリ証明書] をダウンロードします。
CA 証明書ファイルが ca.crt としてダウンロードされます。
CA 証明書の内容を double 型の 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）であり、値は double 型の 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

シークレットのデータマップの名前を参照するクラスタ仕様に trust 変数を含めます。この例では、additional-ca-1 です。

#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 マップ値が変更された場合は、クラスタに反映されません。新しいシークレットを作成して、そのデータマップの name を trust.additionalTrustCAs にする必要があります。

プライベート コンテナ レジストリの使用事例

プライベート コンテナ レジストリの統合

v1alpha3 API の例

v1beta1 API の例

プライベートコンテナレジストリの使用事例

プライベートコンテナレジストリの統合