vSphere IaaS control plane は、トランスポート レイヤー セキュリティ (TLS) 暗号化を使用してコンポーネント間の通信を保護します。スーパーバイザー 上の TKG には、この暗号化インフラストラクチャをサポートするいくつかの TLS 証明書が含まれています。スーパーバイザー 証明書のローテーションは手動で行います。TKG 証明書のローテーションは自動化されていますが、必要に応じて手動で行うこともできます。
TKG サービス クラスタの TLS 証明書について
vSphere IaaS control plane は、TLS 証明書を使用して、次のコンポーネント間の通信を保護します。
vSphere IaaS control plane 環境で使用される各 TLS 証明書のさらに詳しい情報と完全なリストについては、ナレッジベースの記事「
vSphere with Tanzu Certificate Guide」を参照してください。
- vCenter Server
- スーパーバイザー 制御プレーン ノード
- vSphere ポッド のワーカー ノードとして機能している ESXi ホスト
- TKG クラスタ ノード（制御プレーンとワーカーの両方）
| 信頼ドメイン | 説明 |
|---|---|
| vCenter Server の信頼ドメイン | この信頼ドメインの TLS 証明書のデフォルトの署名者は、vCenter Server に組み込まれている VMware Certificate Authority (VMCA) です。 |
| Kubernetes の信頼ドメイン | この信頼ドメインの TLS 証明書のデフォルトの署名者は、Kubernetes Certificate Authority (CA) です。 |
TLS 証明書のローテーション
TLS 証明書をローテーションする手順は、証明書が
スーパーバイザー と TKG サービス クラスタのどちらで使用されるかによって異なります。
- スーパーバイザー証明書のローテーション
-
スーパーバイザー の TLS 証明書は、VMCA 証明書から取得されます。スーパーバイザー 証明書の詳細については、ナレッジベースの記事「vSphere with Tanzu Certificate Guide」を参照してください。
スーパーバイザー の証明書のローテーションは手動で行います。WCP Cert Manager ツールを使用して スーパーバイザー 証明書を置き換える方法については、ナレッジベースの記事「Replace vSphere with Tanzu Supervisor Certificates」を参照してください。
- TKG 2.0 クラスタ証明書のローテーション
-
通常、TKG クラスタの TLS 証明書を手動でローテーションする必要はありません。TKG クラスタを更新すると、ローリング アップデート プロセスによって、TLS 証明書が自動的にローテーションされるためです。
TKG クラスタの TLS 証明書の有効期限が切れていない場合に、これらの証明書を手動でローテーションする必要がある場合は、次のセクションの手順を実行します。
TKG サービス クラスタの TLS 証明書の手動ローテーション
これらの手順を行うには、TKG クラスタ管理に関する高度な知識と経験が必要です。また、これらの手順では、TLS 証明書が期限切れになっていないことが前提となります。証明書が期限切れになっている場合は、次の手順を実行しないでください。
- これらの手順を実行するには、スーパーバイザー ノードのいずれかに SSH 接続します。Kubernetes 管理者およびシステム ユーザーとしての TKG サービス クラスタへの接続を参照してください。
- TKG クラスタ名を取得します。
export CLUSTER_NAMESPACE="tkg-cluster-ns" kubectl get clusters -n $CLUSTER_NAMESPACE NAME PHASE AGE VERSION tkg-cluster Provisioned 43h
- TKG クラスタの kubeconfig を取得します。
export CLUSTER_NAME="tkg-cluster" kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-kubeconfig -o jsonpath='{.data.value}' | base64 -d > $CLUSTER_NAME-kubeconfig - TKG クラスタの SSH キーを取得します。
kubectl get secrets -n $CLUSTER_NAMESPACE $CLUSTER_NAME-ssh -o jsonpath='{.data.ssh-privatekey}' | base64 -d > $CLUSTER_NAME-ssh-privatekey chmod 600 $CLUSTER_NAME-ssh-privatekey - 証明書ローテーションを行う前に環境を確認します。
export KUBECONFIG=$CLUSTER_NAME-kubeconfig
kubectl get nodes -o wide
kubectl get nodes \ -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \ -l node-role.kubernetes.io/master= > nodesfor i in `cat nodes`; do printf "\n######\n" ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration done;前のコマンドの結果の例：
tkg-cluster-control-plane-k8bqh [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' CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Oct 04, 2023 23:00 UTC 363d no apiserver Oct 04, 2023 23:00 UTC 363d ca no apiserver-etcd-client Oct 04, 2023 23:00 UTC 363d etcd-ca no apiserver-kubelet-client Oct 04, 2023 23:00 UTC 363d ca no controller-manager.conf Oct 04, 2023 23:00 UTC 363d no etcd-healthcheck-client Oct 04, 2023 23:00 UTC 363d etcd-ca no etcd-peer Oct 04, 2023 23:00 UTC 363d etcd-ca no etcd-server Oct 04, 2023 23:00 UTC 363d etcd-ca no front-proxy-client Oct 04, 2023 23:00 UTC 363d front-proxy-ca no scheduler.conf Oct 04, 2023 23:00 UTC 363d no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Oct 01, 2032 22:56 UTC 9y no etcd-ca Oct 01, 2032 22:56 UTC 9y no front-proxy-ca Oct 01, 2032 22:56 UTC 9y no
- TKG 2.0 クラスタの TLS 証明書をローテーションします。
次の手順に進む前に、コンテキストを スーパーバイザー に戻します。
unset KUBECONFIG kubectl config current-context kubernetes-admin@kubernetes
kubectl get kcp -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane -o jsonpath='{.apiVersion}{"\n"}' controlplane.cluster.x-k8s.io/v1beta1kubectl get kcp -n $CLUSTER_NAMESPACE $CLUSTER_NAME-control-plane NAME CLUSTER INITIALIZED API SERVER AVAILABLE REPLICAS READY UPDATED UNAVAILABLE AGE VERSION tkg-cluster-control-plane tkg-cluster true true 3 3 3 0 43h v1.21.6+vmware.1
kubectl patch kcp $CLUSTER_NAME-control-plane -n $CLUSTER_NAMESPACE --type merge -p "{\"spec\":{\"rolloutAfter\":\"`date +'%Y-%m-%dT%TZ'`\"}}" kubeadmcontrolplane.controlplane.cluster.x-k8s.io/tkg-cluster-control-plane patchedマシン ロールアウトの開始：kubectl get machines -n $CLUSTER_NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION tkg-cluster-control-plane-k8bqh tkg-cluster tkg-cluster-control-plane-k8bqh vsphere://420a2e04-cf75-9b43-f5b6-23ec4df612eb Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-l7hwd tkg-cluster tkg-cluster-control-plane-l7hwd vsphere://420a57cd-a1a0-fec6-a741-19909854feb6 Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-mm6xj tkg-cluster tkg-cluster-control-plane-mm6xj vsphere://420a67c2-ce1c-aacc-4f4c-0564daad4efa Running 43h v1.21.6+vmware.1 tkg-cluster-control-plane-nqdv6 tkg-cluster Provisioning 25s v1.21.6+vmware.1 tkg-cluster-workers-v8575-59c6645b4-wvnlz tkg-cluster tkg-cluster-workers-v8575-59c6645b4-wvnlz vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b Running 43h v1.21.6+vmware.1
マシン ロールアウトの完了：kubectl get machines -n $CLUSTER_NAMESPACE NAME CLUSTER NODENAME PROVIDERID PHASE AGE VERSION tkg-cluster-control-plane-m9745 tkg-cluster tkg-cluster-control-plane-m9745 vsphere://420a5758-50c4-3172-7caf-0bbacaf882d3 Running 17m v1.21.6+vmware.1 tkg-cluster-control-plane-nqdv6 tkg-cluster tkg-cluster-control-plane-nqdv6 vsphere://420ad908-00c2-4b9b-74d8-8d197442e767 Running 22m v1.21.6+vmware.1 tkg-cluster-control-plane-wdmph tkg-cluster tkg-cluster-control-plane-wdmph vsphere://420af38a-f9f8-cb21-e05d-c1bcb6840a93 Running 10m v1.21.6+vmware.1 tkg-cluster-workers-v8575-59c6645b4-wvnlz tkg-cluster tkg-cluster-workers-v8575-59c6645b4-wvnlz vsphere://420aa071-9ac2-02ea-6530-eb59ceabf87b Running 43h v1.21.6+vmware.1
- TKG 2.0 クラスタの手動による証明書のローテーションを確認します。
次のコマンドを実行して、証明書のローテーションを確認します。
export KUBECONFIG=$CLUSTER_NAME-kubeconfig kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME tkg-cluster-control-plane-m9745 Ready control-plane,master 15m v1.21.6+vmware.1 10.244.0.55 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-control-plane-nqdv6 Ready control-plane,master 21m v1.21.6+vmware.1 10.244.0.54 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-control-plane-wdmph Ready control-plane,master 9m22s v1.21.6+vmware.1 10.244.0.56 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 tkg-cluster-workers-v8575-59c6645b4-wvnlz Ready <none> 43h v1.21.6+vmware.1 10.244.0.51 <none> VMware Photon OS/Linux 4.19.198-1.ph3-esx containerd://1.4.11 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 -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo kubeadm certs check-expiration done;更新された有効期限を示す結果の例。###### tkg-cluster-control-plane-m9745 [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' CERTIFICATE EXPIRES RESIDUAL TIME CERTIFICATE AUTHORITY EXTERNALLY MANAGED admin.conf Oct 06, 2023 18:18 UTC 364d no apiserver Oct 06, 2023 18:18 UTC 364d ca no apiserver-etcd-client Oct 06, 2023 18:18 UTC 364d etcd-ca no apiserver-kubelet-client Oct 06, 2023 18:18 UTC 364d ca no controller-manager.conf Oct 06, 2023 18:18 UTC 364d no etcd-healthcheck-client Oct 06, 2023 18:18 UTC 364d etcd-ca no etcd-peer Oct 06, 2023 18:18 UTC 364d etcd-ca no etcd-server Oct 06, 2023 18:18 UTC 364d etcd-ca no front-proxy-client Oct 06, 2023 18:18 UTC 364d front-proxy-ca no scheduler.conf Oct 06, 2023 18:18 UTC 364d no CERTIFICATE AUTHORITY EXPIRES RESIDUAL TIME EXTERNALLY MANAGED ca Oct 01, 2032 22:56 UTC 9y no etcd-ca Oct 01, 2032 22:56 UTC 9y no front-proxy-ca Oct 01, 2032 22:56 UTC 9y no
- Kubelet 証明書を確認します。
Kubelet 構成のパラメータ
rotateCertificatesがデフォルトの構成であるtrueに設定されている場合、Kubelet 証明書をローテーションする必要はありません。この構成は、次のコマンドを使用して確認できます。kubectl get nodes \ -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}' \ -l node-role.kubernetes.io/master!= > workernodes for i in `cat workernodes`; do printf "\n######\n" ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i hostname ssh -o "StrictHostKeyChecking=no" -i $CLUSTER_NAME-ssh-privatekey -q vmware-system-user@$i sudo grep rotate /var/lib/kubelet/config.yaml done;結果の例：###### tkg-cluster-workers-v8575-59c6645b4-wvnlz rotateCertificates: true
