GDCV for Bare Metal は、証明書と秘密鍵を使用して、クラスタ内のシステム コンポーネント間の接続を認証および暗号化します。クラスタ認証局（CA）はこれらの証明書と鍵を管理します。bmctl update credentials certificate-authorities rotate コマンドを実行すると、ベアメタル版 GKE は次のアクションを実行します。
クラスタ CA、etcd CA、フロントプロキシ CA の新しいクラスタ認証局（CA）を作成して、管理クラスタ内のユーザー クラスタ名前空間にアップロードします。
管理クラスタ コントローラにより、ユーザー クラスタ認証局が新しく生成した認証局に置き換えられます。
管理クラスタ コントローラにより、新しい公開 CA 証明書とリーフ証明書の鍵ペアがユーザー クラスタ システム コンポーネントに配布されます。
安全なクラスタ通信を維持するには、セキュリティ侵害が発生する可能性がある場合に、定期的にユーザー クラスタ CA をローテーションします。
準備
クラスタの認証局をローテーションする前に、次の条件と影響に従って計画を立ててください。
CA ローテーションを開始する前に、管理クラスタとユーザー クラスタがバージョン 1.9.0 以降であることを確認します。
CA ローテーションは増分であり、ローテーション中、システム コンポーネントは通信できます。
CA のローテーション プロセスにより、ユーザー クラスタ内の API サーバー、コントロール プレーン プロセス、Pod は再起動されます。
ワークロードは、CA のローテーション中に再起動され、再スケジュールされることが想定されます。
非高可用性クラスタ構成では、CA ローテーション中にコントロール プレーンのダウンタイムが一時的に発生します。
CA ローテーション中は、クラスタ管理操作を行えません。
CA ローテーションの期間は、クラスタのサイズによって異なります。たとえば、1 つのコントロール プレーンと 50 個のワーカーノードがあるクラスタでは、CA ローテーションの完了に 2 時間程度かかります。
制限事項
認証局のローテーション機能には、次の制限があります。
クラスタ CA が証明書に署名しても、CA ローテーションでは管理者が手動で発行した証明書を更新しません。手動で発行した証明書は、ユーザー クラスタの CA ローテーションが完了した後に更新して再配布します。
CA ローテーションが開始されると、一時停止やロールバックはできません。
クラスタ CA ローテーションを開始する
CA ローテーション プロセスは、次のコマンドを使用して開始します。
bmctl update credentials certificate-authorities rotate --cluster CLUSTER_NAME \
--kubeconfig KUBECONFIG
次のように置き換えます。
CLUSTER_NAME: CA をローテーションするクラスタの名前。KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス。自己管理クラスタの場合、このファイルは、クラスタの kubeconfig ファイルです。
bmctl コマンドは、CA が正常にローテーションされ、新しい kubeconfig ファイルが生成されると終了します。kubeconfig ファイルの標準パスは bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME-kubeconfig です。
クラスタ CA ローテーションのトラブルシューティング
bmctl update credentials コマンドは、CA ローテーションの進行状況を表示します。関連する update-credentials.log ファイルは、次のタイムスタンプ付きディレクトリに保存されます。
bmctl-workspace/CLUSTER_NAME/log/update-credentials-TIMESTAMP