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