Container Service for Kubernetes:kubeconfig の取得と kubectl を使用したクラスターへの接続

有効期間別

アクセス方法別

バインドした EIP には、従量課金料金が発生します。

パブリックアクセスが可能な ACK 専用クラスターでは、SSH 経由でマスターノードに接続して kubeconfig を取得することもできます。

有効期限が切れる前の認証情報のローテーション

長期的な kubeconfig は 3 年間有効です。サービスの中断を避けるため、有効期限が切れる 180 日以内に ACK コンソールまたは DescribeClusterUserKubeconfig API から新しい kubeconfig を取得してください。

新しい kubeconfig は 3 年間有効です。古い kubeconfig は、元の有効期限まで引き続き有効です。

漏洩した認証情報の失効

kubeconfig が漏洩した疑いがある場合は、直ちに クラスターの kubeconfig 認証情報を失効させてください。これにより、既存のすべての接続が無効になり、新しい kubeconfig が生成されます。

退職したユーザーの権限のクリーンアップ

プロジェクトの終了後や従業員の退職など、ユーザーがアクセスを必要としなくなった場合は、kubeconfig ファイルを削除するか、ack-ram-tool を使用することで、そのユーザーの kubeconfig 権限を一括で失効させてください。失効後、システムは新しい kubeconfig を生成しません。

誤って失効させた権限を復元するには、kubeconfig のごみ箱を使用します。

kubeconfig 証明書に関連付けられた ID を確認するにはどうすればよいですか。

証明書のサブジェクトを抽出します。

# クライアント証明書を抽出し、base64 からデコードします
# 次に OpenSSL を使用して Subject フィールドを表示します
grep client-certificate-data kubeconfig | awk '{print $2}' | base64 -d | openssl x509 -noout -text | grep Subject:

期待される出力：

        Subject: O=system:users, OU=, CN=1***-1673419473

• O — Kubernetes ユーザーグループ。この例では system:users です。

• CN — ユーザー識別子。この例では 1***-1673419473 で、1*** は Alibaba Cloud のユーザー ID です。

kubeconfig 証明書の有効期限を確認するにはどうすればよいですか。

証明書の有効期限を確認します。

# クライアント証明書を抽出し、base64 からデコードします
# 次に OpenSSL を使用して有効期限を表示します
grep client-certificate-data kubeconfig | awk '{print $2}' | base64 -d | openssl x509 -noout -enddate

期待される出力：

notAfter=Jan 10 06:44:34 2026 GMT

この例では、証明書は 2026 年 1 月 10 日に失効します。

有効期限が切れる 180 日前、または失効後いつでも、コンソールまたは API から新しい kubeconfig を取得してください。

kubeconfig からクライアント証明書、秘密鍵、API サーバーの URL を抽出するにはどうすればよいですか。

証明書、キー、API サーバーの URL を抽出します。

# クライアント証明書を抽出し、PEM ファイルにデコード
grep client-certificate-data ./kubeconfig | awk -F ' ' '{print $2}' | base64 -d > ./client-cert.pem

# クライアントの秘密鍵を抽出し、PEM ファイルにデコード
grep client-key-data ./kubeconfig | awk -F ' ' '{print $2}' | base64 -d > ./client-key.pem

# API サーバーの URL を変数に抽出
APISERVER=$(grep server ./kubeconfig | awk -F ' ' '{print $2}')

「certificate is valid for」エラーを解決するにはどうすればよいですか。

このエラーは、API サーバー用の Server Load Balancer (SLB) インスタンスに新しい IP アドレスをバインドした場合に発生します。新しい IP アドレスを宛先とする kubectl コマンドは、Error while proxying request: x509: certificate is valid for xxx または Unable to connect to the server: x509: certificate is valid for xxx というエラーで失敗します。

修正方法はクラスターのタイプによって異なります。

• ACK マネージドクラスター：API サーバー証明書の サブジェクト代替名 (SAN) に新しい IP アドレスを追加します。

• ACK 専用クラスター：以下のいずれかの方法で、kubectl が TLS 検証をスキップするように設定します。

  重要

  TLS 検証をスキップすることはセキュリティリスクです。本番環境では使用しないでください。ACK Pro クラスターに移行し、API サーバー証明書の SAN に新しい IP アドレスを追加することを推奨します。

  • 方法 1： --insecure-skip-tls-verify フラグを渡します。

    kubectl -s https://<IP>:6443 --insecure-skip-tls-verify get ns

  • 方法 2：kubeconfig ファイルを編集します。insecure-skip-tls-verify: true を追加し、certificate-authority-data フィールドを削除します。

    apiVersion: v1
    clusters:
    - cluster:
        server: https://<IP>:6443
        insecure-skip-tls-verify: true
      name: kubernetes
    contexts:
    ...

ACK マネージドクラスターのルート証明書キーを取得して、自分で kubeconfig を生成できますか。

いいえ。ACK マネージドクラスターはルート証明書キーを公開していません。コンソールまたは DescribeClusterUserKubeconfig API から kubeconfig を取得してください。