このチュートリアルでは、Google Kubernetes Engine（GKE）の主要な機能とサービスに集中できるように、計画に関する考慮事項の一部を簡略化しています。このチュートリアルで説明する Google Kubernetes Engine 環境を独自に作成する前に、考慮すべきいくつかの計画上の考慮事項があります。考慮事項には、クラスタ管理レベル、ネットワーキング、可用性の種類が含まれます。
ネットワーキング
GKE クラスタでは、IP アドレスを慎重に計画する必要があります。選択するネットワーキング オプションは、GKE クラスタのアーキテクチャに影響します。これらのオプションの一部は、クラスタを再作成しない限り構成後に変更することはできません。
このチュートリアルでは、常に VPC ネイティブ モード ネットワーキングを使用する Autopilot モードクラスタを使用します。VPC ネイティブ クラスタは GKE ノードのエイリアス IP アドレス範囲を使用し、共有 VPC でクラスタを作成するために必要です。VPC ネイティブ クラスタは、Google Cloud ルートを消費することなく、ルートベースのクラスタよりも簡単にスケールできるため、ルーティング上限に達する可能性が低くなります。
独自の GKE 環境を作成してワークロードをデプロイする前に、次のネットワークに関するガイダンスを確認してください。
クラスタモード
このチュートリアルでは、Autopilot モードを使用するリージョン GKE クラスタを作成します。Autopilot クラスタは、本番環境ワークロードに対応する最適化されたクラスタ構成を使用してあらかじめ構成されています。または、Standard モードのクラスタを使用して、基盤となるインフラストラクチャに高度な構成の柔軟性を持たせることもできます。
より包括的な概要については、クラスタ構成の選択肢から始まる計画ドキュメントをご覧ください。
Namespace
Namespace を使用すると、アプリケーションを整理し、コンポーネントを互いに分離できます。各 Namespace は、Pod、Service、Deployment など、独自のリソースセットを持ちます。たとえば、すべてのフロントエンド サービス用の Namespace とバックエンド サービス用の Namespace を作成できます。これにより、Service の管理とアクセスの制御が容易になります。
このチュートリアルでは、Cymbal Bank サンプル アプリケーションの Pod と Service を単一の Namespace にデプロイします。このアプローチでは、デプロイの複雑さが軽減しますが、本番環境で行うように、Namespace を使用してさまざまなチームやユーザーにリソースを割り当てることはできません。複数の Namespace を使用する Cymbal Bank サンプル アプリケーションの、より安全でプロダクション レディな例については、Cymbal Bank アプリケーション アーキテクチャをご覧ください。
Pod Disruption Budget
Pod Disruption Budget（PDB）ポリシーは、システムを変更する際に Pod が同時に停止しないようにすることで、アプリのパフォーマンスを保証します。また、複製されたアプリケーションで同時に使用できない Pod の数を制限します。
このチュートリアルでは、PDB の構成と使用は行いません。チュートリアルを完了して障害をシミュレートすると、サービスとノードはすべて想定どおりに応答します。独自のワークロードをデプロイすると、ノードの PDB によってノードのドレインがブロックされることがあります。
PDB を使用する場合は、ノードを隔離してドレインする前に構成を確認してください。ノードが正常にドレインできない場合は、スケジュールされたメンテナンス イベントに問題がある可能性があります。
次のステップ
マイクロサービス ベースのアプリケーションを実行する最初のチュートリアルで単一の GKE クラスタをデプロイする方法を学習します。