このページでは、リージョン クラスタの仕組みについて説明します。リージョン クラスタを作成する方法は、クラスタを作成するを参照してください。
概要
デフォルトでは、クラスタがクラスタ マスターとノードを、作成時に指定した 1 つのコンピューティング ゾーン内に作成します。リージョン クラスタを作成することで、クラスタの可用性と復元力を向上させることができます。
リージョン クラスタはクラスタ全体に対して 1 つの静的エンドポイントを提供し、クラスタのポッドを所定のリージョンの複数ゾーンにまたがって分散します。これにより、1 つ以上の（ただしすべてではない）個別ゾーンが関与する停止あるいはダウンタイム時にも、クラスタのコントロール プレーンにアクセスできるようになります。
リージョン クラスタは、Kubernetes リソースをリージョン内の複数ゾーンに配分します。リージョン クラスタのマスターとノードは、複数のゾーンにわたって分散しています。デフォルトのマスター数、ゾーンごとのデフォルトのノード数、含まれるデフォルトのゾーン数はすべて 3 つです。ただし、この数を減らしたり増やしたりして、適切なクラスタサイズとゾーン数にできます。
ゾーンクラスタにするかリージョン クラスタにするかは、作成時に決めます。既存のゾーンクラスタをリージョン クラスタに変換することはできず、その逆に変換することもできません。
制限事項
- デフォルトでは、リージョン クラスタは、リージョン内の 3 つのゾーンに均一に分散した 9 つのノードで構成されています。これにより 9 つの IP アドレスが使われます。必要に応じて、ノードの数をゾーンあたり 1 つに減らすことができます。新たに作成された Google Cloud Platform アカウントにはリージョン毎の IP アドレスが 8 つしか付与されないため、リージョン クラスタのサイズに応じて、リージョン使用 IP アドレスについて割り当ての増加のリクエストが必要となる場合があります。利用可能な使用 IP アドレスが少なすぎると、クラスタの作成は失敗します。
- GPU を実行するリージョン クラスタでは、3 つのゾーン内に GPU タイプを持つリージョンは現在ありません。GPU をリージョン クラスタで実行する場合は、
--node-locationsフラグを使用してゾーンを指定する必要があります。3 つのゾーンにまたがる GPU クラスタを作成しようとすると、次のようなエラーが返されます。
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. - ノードプールをクラスタのゾーンの外側のゾーンに作成することはできません。しかし、クラスタのゾーンを変更することはできます。変更すると、新規ノードと既存ノードのすべてがこれらのゾーンにまたがることになります。
料金
リージョン クラスタは、追加の料金がかかりません。
リージョン クラスタを使用する場合、プロジェクトのリージョン割り当てがさらに必要になります。リージョン クラスタを使用する前に、割り当てと Google Kubernetes Engine の料金を理解するようにしてください。Insufficient regional quota to satisfy request for resource（リソースのリクエストに対応する十分なリージョン割り当てがありません）というエラーが発生した場合、そのリクエストは現在のリージョンで利用できる割り当てを超えています。
さらに、複数のゾーンにまたがるノード間トラフィックに対しては料金が発生します。たとえば、あるゾーン内のサービスが別のゾーン内のサービスと通信する必要がある場合、ソーン間ネットワーク トラフィックに対する料金が発生します。詳細については、Compute Engine の料金ページの「同一リージョン内のゾーン間の下り（GB あたり）」をご覧ください。
リージョン クラスタの仕組み
リージョン クラスタは、単一のリージョン内の複数のゾーンにクラスタ マスターとノードを複製します。たとえば us-east1 リージョン内のリージョン クラスタは、3 つすべての us-east1 ゾーン（us-east1-b、us-east1-c、us-east1-d）でマスターとノードを作成します。これにより、リソースの可用性が高まり、ゾーンのダウンタイムからクラスタが保護されることになります。それは、単一のゾーンで障害が発生しても、リージョン クラスタとそのリソースで障害が発生することはないためです。インフラストラクチャが停止しても、リージョンのコントロール プレーンは引き続き使用できるため、手動で、またはクラスタ オートスケーラーを使用してノードを再び均衡化できます。
リージョン クラスタを使用するメリット:
- 単一ゾーンの障害からの回復力。 リージョン クラスタを、リージョン内の単一のゾーンだけでなく、リージョン全体で使用できます。単一のゾーンが使用できなくなっても、Kubernetes コントロール プレーンとリソースには影響がありません。
- ゼロ ダウンタイムのマスター アップグレード、マスター リサイズ、およびマスター障害によるダウンタイムの短縮化。リージョン クラスタのコントロール プレーンは可用性が高いため、アップグレード中でもコントロール プレーンにアクセスできます。
リージョン クラスタの永続ストレージ
永続ストレージ ディスクはゾーンのリソースです。クラスタに永続ストレージを追加する場合、ゾーンが指定されていない限り、GKE はこのディスクを単一のゾーンに割り当てます。その際、GKE はゾーンをランダムに選択します。StatefulSet を使用する場合は、各レプリカ用にプロビジョニングされた永続ディスクがゾーン全体に分散されます。
永続ディスクがプロビジョニングされると、そのディスクを参照するすべてのポッドが、ディスクと同じゾーンにスケジュールされます。
読み取り / 書き込み用の永続ディスクを複数のノードに接続することはできません。
リージョン クラスタの自動スケーリング
クラスタ オートスケーラーを使用して、リージョン クラスタを自動的にスケーリングできます。以下のセクションでは、クラスタ オートスケーラーをリージョン クラスタで使用する場合の考慮事項について説明します。
スケーリング制限のオーバープロビジョニング
万が一ゾーンで障害が発生したとしても容量を維持できるよう、スケーリング制限をオーバープロビジョニングできます。
たとえば、3 つのゾーンにまたがるクラスタに対して 150% のオーバープロビジョンを設定すると、クラスタの容量の 3 分の 1 が失われたとしても、利用可能なゾーンにトラフィックの 100% が確実にルーティングされます。上記の例では、ゾーンごとの最大ノード数を 4 ではなく 6 に指定することで、このオーバープロビジョニングを設定できます。この場合、いずれか 1 つのゾーンで障害が発生すると、クラスタは残りのゾーン内にある 12 のノードにスケールします。
同様に、2 つのゾーンにまたがるクラスタに対して 200% のオーバープロビジョニングを設定すると、クラスタの容量の半分が失われたとしても、トラフィックの 100% が確実にルーティングされます。
クラスタ オートスケーラーの詳細については、クラスタ オートスケーラーのドキュメント、または Kubernetes のドキュメントに記載されている自動スケーリングに関する FAQ をご覧ください。
自動スケーリングの制限
リージョン クラスタにおける自動スケーリングの制限について詳しくは、自動スケーリングの制限事項をご覧ください。
ゾーン間での均衡化
クラスタ オートスケーラーが複数のゾーンでクラスタのサイズを均衡化する仕組みについては、ゾーン間での均衡化をご覧ください。
