追加の信頼済みCA証明書を含むTanzuKubernetesCluster(TKC)の廃止
search cancel

追加の信頼済みCA証明書を含むTanzuKubernetesCluster(TKC)の廃止

book

Article ID: 435642

calendar_today

Updated On:

Products

Tanzu Kubernetes Runtime VMware vSphere Kubernetes Service

Issue/Introduction

免責事項:これは英文の記事「Retiring a TanzuKubernetesCluster (TKC) with Additional Trusted CA Certificates」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

本KB記事では、Additional Trusted CA Certificates が構成された TanzuKubernetesCluster(TKC)をリタイアする前に実施すべき必要な手順について説明します。

以下の手順をTKCのリタイア前に実施しない場合、対象のワークロードクラスタにおいてスケールまたはアップグレード操作を実行できなくなります。

 

Supervisorクラスタのコンテキストに接続した状態で:

  • Additional Trusted CA Certificates を使用しているTKCを、本KB記事の手順を実施する前にリタイアした場合、クラスタ内ノードのマシンを describe した際に以下のエラーが表示されます:
    • kubectl get machines -n <cluster namespace>

      kubectl describe machine -n <cluster namespace> <machine name>
    • - lastTransitionTime: "YYYY-MM-DDTHH:MM:SSZ"
          message: 'failed to resolve file source: secret not found: <NAMESPACE>/<CLUSTER_NAME>-user-trusted-ca-secret: secrets "<CLUSTER_NAME>-user-trusted-ca-secret" not found'
          reason: DataSecretGenerationFailed
          severity: Warning
          status: "False"
          type: BootstrapReady

    • 対象のワークロードクラスタにおけるスケーリングおよびアップグレード操作が実行できなくなります。

注: 本手順は、VKS 3.3.3 および 3.4 では、TKCのリタイア時に自動的に実行されるため、実施する必要はありません。

Environment

vSphere Supervisor

vCenter 8.0u3

TKG/VKS supervisor service 3.3.2 and lower

Cause

v1beta1 TanzuKubernetesCluster(TKC)に Additional Trusted CAs を構成すると、証明書の値が二重に base-64 エンコードされた Kubernetes の secret オブジェクトが作成され、TKC はその secret オブジェクト内のデータを参照するように構成されます。

この secret オブジェクトは、ワークロードクラスタ名と user-trusted-ca-secret を組み合わせて、以下のように命名されます:

<cluster-name>-user-trusted-ca-secret

TKC をリタイアすると、上記の secret はシステムによって削除されます。

この secret が存在しない場合、対象のワークロードクラスタに対してスケーリングまたはアップグレード操作を実行することができません。

対象のワークロードクラスタ内の既存のアプリケーションおよび Pod は、元々構成されていた Additional Trusted CAs の有効期限が切れるまでは引き続き動作します。

v1beta1 Cluster Example with Additional Trusted CAs

 

Resolution

解決策

この問題は、VKS Supervisor Service バージョン 3.3.3 以降で解決されています。

以下の回避策は、VKS 3.3.3 以降では実施する必要はありません。

 

回避策

Additional Trusted CA Certificates が構成されている Tanzu Kubernetes Cluster(TKC)をリタイアする前に、関連する secret オブジェクトをクラスタオブジェクトへ移行し、消失を防ぐ必要があります。

TKC がまだリタイアされていない場合は、以下の Transfer the Trusted CA Secret セクションを参照し、AdditionalTrustedCA secret の所有権をクラスタオブジェクトへ変更してください。

 

すでに転送手順を実施する前に TKC をリタイアしてしまった場合は、以下の Create a new Trusted CA Secret セクションを参照し、目的の AdditionalTrustedCA 設定を含む secret を手動で作成してください。

 

Transfer the Trusted CA Secret

  1. Supervisor cluster コンテキストに接続します

  2. 対象のワークロードクラスタオブジェクトの CLUSTER-UID を取得します:
    • kubectl get cluster -n <NAMESPACE> <CLUSTER-NAME> -o jsonpath={".metadata.uid"}

  3. 対象のワークロードクラスタの user-trusted-ca-secret を特定します:
    • kubectl get secret -n <NAMESPACE> <CLUSTER-NAME>-user-trusted-ca-secret

  4. secret の cluster フィールドを更新し、その所有権を対象のワークロードクラスタオブジェクトへ移行します(<CLUSTER-UID> は手順2で取得した uid を使用):
    • kubectl patch secret -n <NAMESPACE> <CLUSTER-NAME>-user-trusted-ca-secret --type merge  -p '{"metadata": {"ownerReferences":[{"apiVersion":"cluster.x-k8s.io/v1beta1", "kind": "Cluster", "name":"<CLUSTER-NAME>", "uid": "<CLUSTER-UID>"}]}}'

  5. secret が正しく更新されたことを確認します:
    • kubectl get secret -n <NAMESPACE> <CLUSTER_NAME>-user-trusted-ca-secret -o yaml | grep ownerReference -A 4

 

Create a new Trusted CA Secret

  1. Supervisor cluster コンテキストに接続します

  2. v1beta1 Cluster Example with Additional Trusted CAs"Procedure: Existing Cluster" の手順に従ってください

  3. Additional Trusted CAs の構成に関する一般的な問題については、Troubleshooting Additional Trusted CA Errors を参照してください

Additional Information