このページでは、複数の Google Cloud リージョンで高可用性サービスの運用やリソース管理を行う際に Config Controller を使用する最適な方法について説明します。
このページは、基盤となる技術インフラのライフサイクルを管理し、容量とインフラストラクチャのニーズを計画する管理者、アーキテクト、オペレーターを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザー ロールとタスクをご覧ください。
Config Controller は単一のリージョンで実行されるため、アベイラビリティ ゾーンの障害は許容できますが、リージョン全体が障害を起こすと、Config Controller は可用性を失います。リージョンの障害に対処するには 2 つの方法があり、リージョンで障害が発生した場合の動作によって異なります。
リージョンの障害に応じて構成を変更する場合は、2 つ目の Config Controller インスタンスを作成します。
構成を変更しない場合は、単一の Config Controller インスタンスの使用が適しています。
障害のシナリオを理解する
Config Controller はリージョン GKE クラスタを使用します。リージョン クラスタは、リージョン内の単一のゾーンの障害を許容できますが、リージョン内の複数のゾーンに障害が発生した場合、クラスタは使用できなくなります。
Config Controller インスタンスに障害が発生した場合、既存の Google Cloud リソースは現在の状態に維持されます。ただし、アプリケーションがまだ実行中であっても、Config Controller が使用できないときはそれらの構成を変更できません。これは、同じリージョンのリソースと、使用できないリージョンの Config Controller から管理している他のリージョンのリソースに適用されます。
同じリージョン内のリソースを再構成できないため、リージョンの障害によって Config Controller リージョンにある既存の Google Cloud リソースに影響が及ぶと、それらのリソースを修復できません。
他のリージョン内のリソースを再構成できないため、あるリージョンで障害が発生すると、別のリージョンで変更を行う機能が影響を受けるようになります。
他の障害シナリオも考えられます。たとえば、外部の Git プロバイダから pull するように Config Sync を構成する場合は、その Git プロバイダの障害モードを検討する必要があります。その Git プロバイダに変更を push できないため、構成を変更できない可能性があります。また、Config Sync が Git からの読み取りを実施できない場合、Git の変更はクラスタに適用されないため、Config Connector はこれらの変更を適用しません。ただし、通常は他の障害シナリオは Config Controller の障害と相関関係がないため、リージョン障害が最も重要な障害のシナリオとなります。
リージョンの可用性のために単一のクラスタを使用する
多くのシナリオでは、リージョンで障害が発生しても再構成は行われません。その場合、リージョンの障害で構成コントロール プレーンが使用不能になることを許容することもできます。
たとえば、単一のリージョンでのみ運用している場合、そのリージョンに障害が発生した際に有用な再構成を実施できない可能性があります。同様に、単一リージョンに単一障害点データベースがある場合、そのリージョンが復旧するまでリージョン全体を復旧できないことがあります。絶対的な最高の可用性を必要としないアプリケーションの場合、この状況はコストと複雑さに対する妥当なトレードオフになる可能性があります。
同じリージョンに Config Controller インスタンスを配置すると、運命共有が実現されます。つまりプライマリ リージョンが使用可能な限り、Config Controller インスタンスも使用可能です。Config Controller インスタンスを別のリージョンに配置することも有効な選択肢となります。2 つのリージョンの潜在的な障害について考慮する必要がありますが、プライマリ リージョンの障害による構成コントロール プレーンの相関障害を回避できるようになります。
また、マルチリージョンの冗長構成では、障害の起きたリージョンからシステムが自動的に分離されないこともあります。ここでも、リージョンで障害が発生した場合に再構成を行わない場合があります。この場合、1 つの Config Controller インスタンスを選択できます。
2 つ目の Config Controller インスタンスに手動でフェイルオーバーする
リージョンに障害が発生した場合は、障害に対処できるように、再構成を行うことをおすすめします。障害が発生したリージョンに Config Controller インスタンスがある場合でも、他のリージョンでリソースの構成を継続できます。この場合は、2 番目のリージョンで 2 番目の Config Controller インスタンスを使用することをおすすめします。
推奨はされませんが、2 つの Config Controller インスタンスを同じ構成で実行できます。これにより、両方のインスタンスで同じ Git リポジトリからの読み取りが競合して、Google Cloud に同じ変更を適用することになります。ただし、多くのエッジケースにより、このケースの信頼性は低くなります。2 つの Config Controller インスタンスは、多少異なるタイミングで Git リポジトリを監視します。つまり、これらのインスタンスは Google Cloud 構成が多少異なるバージョンを適用しようとしている可能性があります。Google Cloud に対する複数のアクティブなライターにより、割り当てやレート上限に達する可能性が高くなります。少数の Config Connector リソースもべき等ではないため、このセクションの残りの部分で説明するようにさらなる注意が必要です。そのため、2 つの Config Controller クラスタが両方アクティブに調整されないようにすることをおすすめします。
Config Controller を実行しているリージョンで障害が発生した場合、代わりに 2 番目のリージョンで別の Config Controller を実行することをおすすめします。新しい Config Controller インスタンスは、最初のインスタンスと同じように構成して同じ Git リポジトリから読み取りを行うようにする必要があります。このシナリオでは、Config Controller インスタンスを起動して構成するためのスクリプトを事前準備しておくと便利です。新しい Config Controller インスタンスを作成すると、Config Sync は Git から望ましい状態を読み取り、Kubernetes に適用します。Config Connector は、その望ましい状態を Google Cloud に同期します。
この場合は次の 2 つの点に注意してください。
最初の Config Controller クラスタが引き続き実行中であるか、最初のリージョンが復旧したときに実行を開始すると、古い状態を Google Cloud に適用しようとする可能性があります。最初のリージョンで Config Controller クラスタを停止してから 2 番目の Config Controller クラスタを起動することで、この潜在的な競合を回避できます。
すべての Config Connector リソースを Git からシームレスに再適用できるわけではありません。特別な注意が必要なリソースのリストについては、取得に関する制限のあるリソースをご覧ください。特に、
Folderリソースを注意深く使用し、IAMServiceAccountKeyリソースを使用しないようにすることをおすすめします（たとえば、Workload Identity Federation for GKE を使用するなど）。
リージョンごとに 1 つの Config Controller インスタンス
あるリージョンにある Config Controller インスタンスが別のリージョンに影響を与えないようにするには、各 Config Controller インスタンスがそのリージョン内のリソースを管理するように、リージョンごとに Config Controller インスタンスを実行することも検討します。
この構成は可能ですが、次の理由によりおすすめできる方法ではありません。
一部のリソースは複数のリージョン（Cloud DNS など）にまたがるため、この方法は制限されます。
一般に、同じリージョンに Config Controller クラスタがあると、相関障害の問題が発生します。つまり、リージョンの障害によってそのリージョンの Config Controller が影響を受ける場合、リソースを正確に再構成する必要があります。
Config Connector リソースをリージョンごとに分割する必要があります。
現在、Config Controller はすべてのリージョンで利用できるわけではありません。
Google Cloud リソースを直接構成する
例外として、Git または Config Connector を経由せずに、基盤となる Google Cloud リソースに直接変更を加える場合があります。Config Connector は「ブレ」の補正を試行するため、Config Controller インスタンスが引き続き実行中の場合、Config Connector は手動で行った変更を「ブレ」とみなして補正しようとします。
ただし、Config Controller インスタンスを停止する場合、またはリージョンがオフラインの場合は、この一時的な処理が役立つことがあります。
Config Controller インスタンスが復旧すると、Config Connector は手動で行った変更を元に戻そうとする場合があります。この状況を回避するには、手動で行った変更について Git で対応する変更を行います。