同じ名前のワークロード クラスターを削除して再作成した後、「kubectl vsphere login」経由でアクセスすると、正しくログインしても「サーバーにログインしている必要があります」というエラーが発生します。

Products

• VMware vSphere Kubernetes Service

Issue/Introduction

免責事項：これは英文の記事「After deleting and re-creating workload cluster with same name, accessing via "kubectl vsphere login" results in error "You must be logged in to the server" even with correct login」の日本語訳です。記事はベストエフォートで翻訳を進めているため、ローカライズ化コンテンツは最新情報ではない可能性があります。最新情報は英語版の記事で参照してください。

• 同一の名前が過去に使用されていた状態で、同じ namespace 内にワークロードクラスタを新規作成した場合、作成自体は成功しますが、kubectl を使用したログインは失敗します。
• "kubectl vsphere login" によるログインを実行すると、認証情報が正しいにもかかわらずエラーが発生します：
  

  # kubectl vsphere login ...
  E1002 11:43:39.772988  922913 memcache.go:265] couldn't get current server API group list: the server has asked for the client to provide credentials
  error: You must be logged in to the server (the server has asked for the client to provide credentials)

• 該当のワークロードクラスタへ SSH でアクセスし、kube-apiserver Pod のログを確認すると、"kubernetes-extensions" に関する証明書エラーが確認できます：
  

  # kubectl logs -n kube-system kube-apiserver-<tkc>-#####-##### | grep extension | tail -n5
  E1002 ##:##:##.00       1 authentication.go:74] "Unable to authenticate the request" err="[invalid bearer token, Post \"https://localhost:5443/tokenreview?timeout=30s\": tls: failed to verify certificate: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kubernetes-extensions\")]"

• 作成日時および証明書の有効期間を確認すると、それぞれの時刻が一致していないことが分かります。以下は架空のタイムスタンプによる出力例です：
  

  # kubectl get cluster -n <namespace> <tkc> -o jsonpath='{.metadata.creationTimestamp}'
  2025-10-10T12:00:00Z  <--- クラスタが作成された日時
  
  # kubectl get certificate -n <namespace> <tkc>-auth-svc-cert -o yaml | grep -iE "creationTimestamp|notAfter|notBefore"
    creationTimestamp: "2025-10-10T12:00:00Z"  <--- tkg-controller が secret を作成した日時
    notAfter: "2035-09-25T12:00:00Z"
    notBefore: "2025-09-27T12:00:00Z"  <--- cert-manager が secret を生成した日時
  
  # kubectl get secret -n <namespace> <tkc>-auth-svc-cert -o yaml | grep -i "creationTimestamp"
    creationTimestamp: "2025-09-27T12:00:00Z"  <--- secret が作成された日時

  具体的な観察事項:
  1. ワークロードクラスタは 2025-10-10 に作成されました。
  2. 対象の certificate リソースも同日（2025-10-10）に作成されていますが、その有効開始日（notBefore）は 2025-09-27 であり、クラスタ作成日より前となっています。
  3. 対象の secret も 2025-09-27 に作成されており、クラスタが存在する前に作成されています。
  
  結論: 証明書および secret は、クラスタが最初に作成されるよりも前に生成されていました。これは、過去にクラスタを削除した際に、これらのリソースが適切にクリーンアップされずに残存していたことを示唆しています。

Environment

vSphere Supervisor

vSphere Kubernetes Service 3.5 and earlier

Cause

ワークロードクラスタが削除される際、Supervisor 上の対応する secret <tkc>-auth-svc-cert も同様に削除されます。しかし、cert-manager サービスはその削除を想定していないため、同じ secret を再作成します。この secret の再作成により、削除されたワークロードクラスタとの適切な関連付けや関係性が失われます。その結果、secret は孤立（orphan）状態で残存します。最終的には、ワークロードクラスタの削除自体は正常に進行し、成功します。

しかしながら、同じ名前で新しいワークロードクラスタをプロビジョニングした場合、secret/<tkc>-auth-svc-cert リソースはすでに存在しています。そのため、既存の secret が再利用されます。これにより、Supervisor とワークロードクラスタ間で証明書の不整合が発生し、その結果、後続のログイン試行が失敗します。

Resolution

本事象については Engineering にて認識しており、今後のリリースで修正される予定です。

Workaround

回避策については、本 KB 記事をご参照のうえ、Broadcom Support までお問い合わせください。本回避策には、場合によっては影響を伴う手順が含まれる可能性があるため、必ず Broadcom Support へご連絡いただいた上で、または指示に従って実施してください。