このページでは、Google Kubernetes Engine（GKE）内のリージョン クラスタの動作について説明します。リージョン クラスタの作成や、クラスタのさまざまなタイプに関する詳細の確認ができます。
概要
デフォルトでは、クラスタのコントロール プレーン（マスター）とノードのすべてが、クラスタ作成時に指定した単一のコンピューティング ゾーンで実行されます。リージョン クラスタは、1 つのリージョンの複数ゾーンにわたってクラスタのコントロール プレーン（マスター）とそのノード複製することにより、それらの可用性を高めます。これにより、マルチゾーン クラスタの利点に加えて、以下の追加的な利点が得られます。
- リージョン内の 1 つ以上の（ただし全部ではない）ゾーンが停止した場合、コントロール プレーンのレプリカが 1 つでも使用可能であれば、クラスタのコントロール プレーンはアクセス可能なままになります。
- クラスタ アップグレードなどのクラスタ メンテナンス中は、コントロール プレーンのレプリカが一度に 1 つだけ使用不可になり、クラスタは動作を継続します。
デフォルトで、コントロール プレーンと各ノードプールはリージョンの 3 つのゾーンにわたって複製されますが、レプリカの数をカスタマイズすることができます。
クラスタを作成した後は、そのクラスタがゾーン、マルチゾーン、リージョンのいずれであるかを変更することはできません。
リージョン クラスタの仕組み
リージョン クラスタは、単一のリージョン内の複数のゾーンにクラスタ マスターとノードを複製します。たとえば、us-east1 リージョン内のリージョン クラスタは、3 つの us-east1 ゾーン（us-east1-b、us-east1-c、us-east1-d）でコントロール プレーンとノードのレプリカを作成します。インフラストラクチャが停止しても、ワークロードは動作を継続し、手動またはクラスタ オートスケーラーを使用してノードを再均衡化できます。
リージョン クラスタを使用するメリットは次の通りです。
- 単一ゾーンの障害からの回復力。 リージョン クラスタを、リージョン内の単一のゾーンだけでなく、リージョン全体で使用できます。単一のゾーンが使用できなくなっても、Kubernetes コントロール プレーンとリソースには影響がありません。
- ゼロ ダウンタイムのマスター アップグレード、マスター リサイズ、およびマスター障害時のダウンタイム短縮。リージョン クラスタのコントロール プレーンは可用性が高いので、アップグレード中でもコントロール プレーンにアクセスできます。
制限事項
デフォルトで、リージョン クラスタは、リージョン内の 3 つのゾーンに均一に分散した 9 つのノードで構成されます。これにより 9 つの IP アドレスが使われます。必要に応じて、ノードの数をゾーンあたり 1 つに減らすことができます。新しく作成された Google Cloud アカウントにはリージョンあたり 8 つの IP アドレスだけが与えられるので、リージョン クラスタのサイズによっては、リージョンで使用中の IP アドレスの割り当て増加をリクエストする必要が生じる場合があります。使用可能な IP アドレスが少なすぎると、クラスタの作成が失敗します。
GPU を実行するリージョン クラスタでは、3 つのゾーンに GPU が存在するリージョンを選択するか、
--node-locationsフラグを使ってゾーンを指定する必要があります。そうしないと、次のようなエラーが表示されることがあります。ERROR: (gcloud.container.clusters.create) ResponseError: code=400, message= (1) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-c. (2) accelerator type "nvidia-tesla-k80" does not exist in zone us-west1-a.
GPU を使用できるリージョンとゾーンの一覧については、Compute Engine の GPU をご覧ください。
クラスタのゾーンの外部にあるゾーンでノードプールを作成することはできません。ただし、クラスタのゾーンを変更することはできます。変更すると、新規ノードと既存ノードのすべてがそれらのゾーンにまたがることになります。
料金
リージョン クラスタを使用する場合、類似するゾーンクラスタやマルチゾーン クラスタよりも多くのプロジェクトのリージョン割り当てが必要となります。リージョン クラスタを使用する前に、割り当てと GKE の料金を確実に理解してください。Insufficient regional quota to satisfy request for resource エラーが発生した場合、そのリクエストは現在のリージョンで使用可能な割り当てを超えています。
また、複数のゾーンにまたがるノード間トラフィックに対しても料金が発生します。たとえば、あるゾーンで実行中のワークロードが別のゾーンのワークロードと通信する必要がある場合、ゾーン間トラフィックが課金されます。詳細については、Compute Engine の料金ページで同一リージョン内のゾーン間の下り（GB あたり）をご覧ください。
リージョン クラスタ内の永続ストレージ
永続ストレージ ディスクはゾーンのリソースです。クラスタに永続ストレージを追加するとき、ゾーンが指定されない限り、GKE はディスクを単一のゾーンに割り当てます。その際、GKE はゾーンをランダムに選択します。StatefulSet を使用する場合は、各レプリカ用にプロビジョニングされた永続ディスクがゾーン全体に分散されます。
永続ディスクがプロビジョニングされると、そのディスクを参照するすべてのポッドが、ディスクと同じゾーンにスケジュールされます。
読み取り / 書き込み用の永続ディスクを複数のノードに接続することはできません。
リージョン クラスタの自動スケーリング
クラスタ オートスケーラーを使用してリージョン クラスタ内のノードプールを自動的にスケーリングする場合は、次の点に留意してください。
さらに、リージョン クラスタの自動スケーリングの制限に関する詳細や、クラスタ オートスケーラーがゾーン間で均衡化を図る方法の詳細を確認することもできます。
スケーリング制限のオーバープロビジョニング
万一ゾーンで障害が発生しても容量を維持できるように、GKE にスケーリング制限の超過を許可し、一部のゾーンが使用できない場合でも最小限の可用性を確保できます。
たとえば、3 つのゾーンにまたがるクラスタに対して 150%（50% の容量超過）のオーバープロビジョニングを設定すると、クラスタの容量の 3 分の 1 が失われたとしても、利用可能なゾーンにトラフィックの 100% が確実にルーティングされます。上記の例では、ゾーンごとの最大ノード数を 4 ではなく 6 に指定することで、このオーバープロビジョニングを設定できます。この場合、いずれか 1 つのゾーンで障害が発生すると、クラスタは残りのゾーン内にある 12 のノードにスケールします。
同様に、2 つのゾーンにまたがるクラスタに対して 200% のオーバープロビジョニングを設定すると、クラスタの容量の半分が失われたとしても、トラフィックの 100% が確実にルーティングされます。
Kubernetes の資料でクラスタ オートスケーラーの詳細を確認したり、自動スケーリングに関するよくある質問を読んだりできます。
次のステップ
- リージョン クラスタを作成する。
- さまざまなクラスタのタイプの詳細を確認する。
- ノードプールの詳細を理解する。
- クラスタ アーキテクチャの詳細を理解する。