Google Distributed Cloud は、証明書と秘密鍵を使用して、管理クラスタ内の Kubernetes システム コンポーネント間の通信を認証します。管理クラスタを作成すると、新しい認証局（CA）証明書が作成され、それらのルート証明書が Kubernetes システム コンポーネントに追加のリーフ証明書を発行するために使用されます。
このガイドは、管理クラスタの CA 証明書のローテーションにのみ適用されます。ユーザー クラスタについては、ユーザー クラスタの CA 証明書のローテーションをご覧ください。
管理クラスタでは、Kubernetes システムで使用される CA 証明書が 3 つあります。
etcd CA 証明書は、Kubernetes API サーバーから etcd レプリカへの通信と、etcd レプリカ間の通信を保護します。この証明書は自己署名によるものです。
クラスタ CA 証明書は、Kubernetes API サーバーとすべての内部 Kubernetes API クライアント（kubelet、コントローラ マネージャー、スケジューラなど）間の通信を保護します。この証明書は自己署名によるものです。
フロントプロキシ CA 証明書は、集約 API との通信を保護します。この証明書は自己署名によるものです。
証明書のローテーションは、gkectl を使用してトリガーできます。ローテーションの際、gkectl によって管理クラスタのコアシステムの CA 証明書が新しく生成された証明書に置き換えられます。その後、新しい CA 証明書、リーフ証明書、秘密鍵が管理クラスタのシステム コンポーネントに配布されます。ローテーションは段階的に行われるため、システム コンポーネントはローテーション中も通信を継続できます。ただし、ローテーション中にワークロードとノードが再起動されることに注意してください。
ローテーションを行わないと、CA 証明書とコントロール プレーン証明書はクラスタの作成日から 5 年で期限切れになります。コントロール プレーンの証明書はクラスタのアップグレード中に自動的にローテーションされますが、CA は自動的にローテーションされません。つまり、定期的なバージョン アップグレードに加え、少なくとも 5 年に 1 回 CA ローテーションを実行する必要があります。
制限事項
CA 証明書のローテーションの対象は、前述の etcd、クラスタ、フロント プロキシの証明書のみです。
CA 証明書のローテーションの対象は、Google Distributed Cloud によって自動的に発行される証明書のみです。管理者が手動で発行した証明書は、システム CA によって署名されている場合でも、ローテーションで更新されることはありません。
CA 証明書のローテーションにより、Kubernetes API サーバー、他のコントロール プレーン プロセス、管理クラスタ内の各ノードが複数回再起動されます。ローテーションの各ステージは、クラスタのアップグレードと同じように進行します。管理クラスタと、管理クラスタが管理するユーザー クラスタは、証明書のローテーション中も動作し続けますが、管理クラスタ内のワークロードは再起動、再スケジュール設定されることが想定されます。また、管理クラスタ コントロール プレーンとユーザー クラスタ コントロール プレーンでは、短時間のダウンタイムも想定されます。
証明書のローテーションの途中と、ローテーションの完了後に、管理クラスタの kubeconfig ファイルを更新する必要があります。古いクラスタ証明書が取り消され、kubeconfig ファイルの認証情報が機能しなくなるためです。
CA 証明書のローテーションは、一旦開始するとロールバックできません。
クラスタのサイズによっては、CA 証明書のローテーションが完了するまでに、かなりの時間を要する場合があります。
証明書のローテーション プロセスが中断された場合、同じコマンドを再実行することにより再開できます。ただし、1 度に実行されるローテーション コマンドは 1 つだけにする必要があります。
ローテーションを開始する
証明書のローテーションを開始するには、次のコマンドを実行します。ローテーションの前半が実行され、一時停止点で停止します。
ローテーションを開始します。
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
次のように置き換えます。
ADMIN_CLUSTER_CONFIG: 管理クラスタの構成ファイルのパス
ADMIN_CLUSTER_KUBECONFIG: 管理クラスタの kubeconfig ファイルのパス
コマンドが中断した場合は、同じコマンドを実行すれば再開できます。
kubeconfig ファイルを更新する
前述のコマンドが一時停止したら、管理クラスタの kubeconfig ファイルを更新します。これにより、新しいクライアント証明書と新しい CA 証明書が kubeconfig ファイルに配置されます。古いクライアント証明書は kubeconfig ファイルから削除され、古い CA 証明書は kubeconfig ファイル内に保持されます。
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
ローテーションを続ける
次のコマンドを実行して、プロセスの後半を実行します。コマンドは、更新された kubeconfig ファイルが現在のディレクトリにあることを gkectl が確認できてはじめて続行されます。
gkectl update credentials certificate-authorities rotate \
--admin-cluster \
--complete \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
コマンドが中断した場合は、同じコマンドを実行すれば再開できます。
ローテーションが完了すると、現在の CA バージョンが報告されます。
再度 kubeconfig ファイルを更新する
ローテーションの後半が完了したら、再度 kubeconfig ファイルを更新します。これにより、古い CA 証明書が kubeconfig ファイルから削除されます。
gkectl update credentials certificate-authorities update-kubeconfig \
--admin-cluster \
--config ADMIN_CLUSTER_CONFIG \
--kubeconfig ADMIN_CLUSTER_KUBECONFIG
新しい kubeconfig ファイルを配布する
新しい管理クラスタの kubeconfig ファイルをすべてのクラスタ ユーザーに配布します。