追加の信頼できる CA に関するエラーのトラブルシューティング

TKG クラスタに信頼できる CA 証明書を追加する際に問題が発生した場合は、このトピックを参照してください。

追加の信頼できる CA に関するエラーのトラブルシューティング

v1alpha3 API または v1beta1 API のいずれかを使用して、追加の信頼できる CA 証明書の値を含む trust 変数を指定できます。一般的な使用事例は、プライベート コンテナ レジストリ証明書をクラスタに追加する場合です。TKG サービス クラスタとプライベート コンテナ レジストリの統合を参照してください。

v1beta1 API を使用する場合の例は次のとおりです。

topology:
  variables:
    - name: trust
      value:
        additionalTrustedCAs:
          - name: my-ca

シークレットは次のようになります。

apiVersion: v1
data:
  my-ca: # Double Base64 encoded CA certificate
kind: Secret
metadata:
  name: CLUSTER_NAME-user-trusted-ca-secret
  namespace: tap
type: Opaque

TKG クラスタ仕様に trust.additionalTrustedCAs スタンザを追加すると、スーパーバイザー はローリング アップデート方式でクラスタ ノードを更新します。ただし、trust 値が誤っていると、マシンが適切に起動せず、クラスタへの参加に失敗します。

v1beta1 API を使用している場合は、証明書の内容を double 型の base64 エンコード形式にする必要があります。証明書の内容が double 型の base64 エンコード形式でない場合は、次のエラーが表示されることがあります。

ls cannot access '/var/tmp/_var_ib_containerd': No such file or directory

v1alpha3 API（または v1alpha2 API）を使用している場合は、証明書の内容を single 型の base64 エンコード形式にする必要があります。証明書の内容が base64 エンコード形式でない場合は、次のエラーが表示されることがあります。

"default.validating.tanzukubernetescluster.run.tanzu.vmware.com" denied the request: 
Invalid certificate internalharbor, Error decoding PEM block for internalharbor in the TanzuKubernetesCluster spec's trust configuration

適切なエンコードを使用しないと、マシン ノードが起動せず、上記のエラーが表示されます。この問題を解決するには、証明書の内容を適切にエンコードして、その値をシークレットのデータ マップに追加します。

「kubectl replace -f /tmp/kubectl-edit-2005376329.yaml」を実行して、この更新を再試行できます。