クラスタ シークレットの管理
このトピックでは、Tanzu Kubernetes Grid のワークロード クラスタで使用される以下のシークレットを構成および管理する方法について説明します。
- クラスタがクラウド インフラストラクチャ API およびリソースへのアクセスに使用する認証情報。「クラスタ認証情報の更新」を参照してください。
- 内部クラスタ コンポーネントが要求の認証に使用するクライアント証明書（スタンドアローン管理クラスタが展開されたワークロード クラスタのみ）。「クラスタ証明書の更新」を参照してください。
- クラスタがプライベート コンテナ レジストリにアクセスするために使用する認証局 (CA) 証明書。「信頼できる複数のレジストリを持つクラスタの構成」および「既存のクラスタへのカスタム CA 証明書の信頼の追加」を参照してください。
- クラスタが認証済みのプライベート コンテナ レジストリにアクセスするために使用する認証情報。「プライベート コンテナ レジストリへの認証の構成」を参照してください。
クラスタ認証情報の更新
vSphere または Azure へのアクセスに使用する認証情報が変更された場合は、新しい認証情報を使用するようにクラスタを更新できます。AWS では認証情報の処理方法が異なるため、このセクションは vSphere と Azure にのみ適用されます。
- vSphere
-
スタンドアローン管理クラスタおよびワークロード クラスタの認証情報の更新
現在のスタンドアローン管理クラスタとそのすべてのワークロード クラスタで使用される vSphere 認証情報を更新するには、
tanzu mc credentials update --cascadingコマンドを使用します。-
tanzu context use MGMT-CLUSTERを実行して、更新する管理クラスタにログインします。 -
tanzu mc credentials updateを実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。--vsphere-user：vSphere アカウントの名前。--vsphere-password：vSphere アカウントのパスワード。--vsphere-thumbprint：vCenter Server インスタンスの TLS サムプリント。
スタンドアローン管理クラスタの vSphere 認証情報を更新し、ワークロード クラスタについては更新しない場合は、上記のように
tanzu mc credentials updateコマンドを使用しますが、--cascadingオプションは使用しません。単一のワークロード クラスタが vSphere にアクセスするために使用する認証情報を更新するには、
tanzu cluster credentials updateコマンドを使用します。-
tanzu context use MGMT-CLUSTERを実行して、更新するワークロード クラスタを作成した管理クラスタにログインします。管理クラスタは、スーパーバイザー クラスタまたはスタンドアローン管理クラスタです。 -
tanzu cluster credentials update CLUSTER-NAMEを実行します。次のコマンド オプションに値を渡すか CLI でプロンプトを表示させることができます。--namespace：defaultなど、認証情報を更新するクラスタの名前空間。--vsphere-user：vSphere アカウントの名前。--vsphere-password：vSphere アカウントのパスワード。--vsphere-thumbprint：vCenter Server インスタンスの TLS サムプリント。
また、
tanzu mc credentials update --cascadingを使用して、管理クラスタおよび管理対象のすべてのワークロード クラスタの vSphere 認証情報を更新することもできます。 -
- AWS
- このセクションは、AWS 環境には適用されません。
- Azure
-
スタンドアローン管理クラスタおよびワークロード クラスタの認証情報の更新
重要
開始する前に、Azure ポータルまたは Azure 管理者から新しい Azure 認証情報を取得します。
現在のスタンドアローン管理クラスタとそのすべてのワークロード クラスタで使用される Azure 認証情報を更新するには、
tanzu mc credentials update --cascadingコマンドを使用します。-
tanzu context use MGMT-CLUSTERを実行して、更新する管理クラスタにログインします。 -
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 context use MGMT-CLUSTERを実行して、更新するワークロード クラスタを作成した管理クラスタにログインします。 -
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 認証情報を更新することもできます。 -
制御プレーン ノードの証明書の自動更新
構成方法とクラスタ タイプに応じて、制御プレーン ノード仮想マシンの証明書を自動的に更新するように、次のように 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; minimum: 7.
クラスタ証明書の更新（スタンドアローン MC）
スタンドアローン管理クラスタとそれらのワークロード クラスタは、クライアント証明書を使用して要求を認証します。これらの証明書は 1 年間有効です。証明書を更新するには、クラスタをアップグレードするか、次の手順に従います。この手順は、期限切れになっていない有効なクラスタ証明書を対象としています。
-
更新する証明書を使用しているクラスタを特定します。例：
tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN TKR workload-slot35rp10 default running 3/3 3/3 v1.26.8+vmware.1 <none> prod v1.26.8---vmware.2-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.26.8+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.26.8+vmware.1 workload-slot35rp10-control-plane-ggsmj workload-slot35rp10 workload-slot35rp10-control-plane-ggsmj vsphere://4201a86e-3c15-879a-1b85-78f76a16c27f Running 42h v1.26.8+vmware.1 workload-slot35rp10-control-plane-hxbxb workload-slot35rp10 workload-slot35rp10-control-plane-hxbxb vsphere://42014b2e-07e4-216a-24ef-86e2d52d7bbd Running 42h v1.26.8+vmware.1 workload-slot35rp10-control-plane-sm4nw workload-slot35rp10 workload-slot35rp10-control-plane-sm4nw vsphere://4201cff3-2715-ffe1-c4a6-35fc795995ce Running 42h v1.26.8+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.26.8+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と表示されます。ワーカー ノードの証明書は自動的に更新されます。
-
信頼されたレジストリを持つクラスタの構成 (スーパーバイザー)
TKG の外部にあるプライベート コンテナ レジストリ、つまり TKG クラスタで実行されない自己署名証明書を持つレジストリを使用するようにスーパーバイザーで展開された TKG クラスタを構成するには、vSphere ドキュメントの次のトピックを参照してください。
- vSphere 8：TKG 2 クラスタとプライベート コンテナ レジストリの統合
- vSphere 7：Tanzu Kubernetes クラスタでの外部コンテナ レジストリの使用
複数の信頼できるレジストリを持つクラスタの構成（スタンドアローン MC）
スタンドアローン管理クラスタを使用するインターネットが制限された環境では、「vSphere でのオフライン Harbor レジストリの展開」の説明に従って、TKG_CUSTOM_IMAGE_REPOSITORY_* 変数を構成し、Harbor 仮想マシンなどの、ブートストラップ元の TKG システム イメージを含むプライベート レジストリへのアクセスを TKG クラスタに許可できます。
ADDITIONAL_IMAGE_REGISTRY_* 変数は、次に示すような、自己署名認証局 (CA) 証明書を使用する追加のレジストリとの信頼できる通信がある新しいクラスタを構成します。
- CLI で管理されるパッケージをインストールするためのパッケージ リポジトリとして機能するプライベート レジストリ。
- TKG でホストされるアプリケーション イメージ用のスケーラブルな自己署名 Harbor レジストリ。「サービス レジストリ用の Harbor のインストール」で説明されているように、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 仮想マシン イメージ テンプレートに基づくクラスタに対して、すべてのターゲット プラットフォームで機能します。
クラスタをカスタマイズし、新しいクラスタ プランを作成するオーバーレイについては、「ytt オーバーレイ」を参照してください。ytt のダウンロードおよびインストール方法については、「Carvel ツールのインストール」を参照してください。
-
カスタム CA をすべての新しいクラスタに適用するか、1 つのクラウド インフラストラクチャで作成されたクラスタにのみ適用するか、または特定のクラスタ API プロバイダ バージョン（クラスタ API プロバイダ vSphere v1.7.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ディレクトリで、新規または既存のtkg-custom-ca.pemファイルに認証局を追加します。 -
クラスタを作成する前に、「（レガシー）プランベースまたは TKC クラスタの作成」の説明に従って、
allow-legacy-cluster機能をtrueに設定します。
既存のクラスタへのカスタム CA 証明書の信頼の追加（スタンドアローン MC）
containerd TLS およびその他の用途のために、TKG_CUSTOM_IMAGE_REPOSITORY_* 構成変数によって設定されたものを超えて、既存のクラスタと自己署名 CA を使用した追加のカスタム Harbor レジストリ間の信頼できる通信を有効にできます。これを行う方法は、次に説明するように、クラスタがプランベースかクラスベースかによって異なります。
クラスベースのクラスタがカスタム レジストリを信用するようにする
信頼できるカスタム レジストリを既存のクラスベースのクラスタに追加するには、その 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 は、TKG_CUSTOM_IMAGE_REPOSITORY_* および TKG_PROXY_CA_CERT 構成変数からの imageRepository と trust セット値をブロックすることに注意してください。
プランベースのクラスタがカスタム レジストリを信用するようにする
自己署名 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-----
-
-
カスタム CA をスタンドアローン管理クラスタの
kubeadmconfigtemplateに追加します。-
コンテキストを管理クラスタに切り替えます。
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
レジストリ認証シークレットの更新
シークレットの認証情報を更新したり、すべての名前空間でシークレットを使用できるようにしたり、クラスタ内の 1 つの名前空間でのみ使用できるようにしたりできます。
シークレットが作成された名前空間内でシークレットを更新するには、次のコマンドを実行します。
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'
