クラスタ構成の選択肢について


このページでは、Google Cloud コンソール、Google Cloud CLI、Terraform のいずれを使用していても、Google Kubernetes Engine(GKE)でクラスタを作成する際に選択できる主なクラスタ構成について説明します。これらのオプションを使用すると、クラスタをパブリック ネットワークからアクセス可能にするかどうかから、バージョン アップグレードを受け取る方法まで、クラスタのさまざまな属性と動作をニーズに合わせてカスタマイズできます。

このガイドで説明するオプションの多くは、クラスタの作成後に変更できません。オプションには、クラスタの可用性ネットワークに影響する選択が含まれるからです。これらのオプションを変更する必要がある場合は、新しいクラスタを作成してトラフィックを移行する必要があります。この作業は停止を伴う可能性があります。

ベスト プラクティス:

クラスタ構成オプションの多くはクラスタの作成後に変更できないため、組織の管理者、アーキテクト、クラウド アーキテクト、ネットワーク管理者、または GKE と Google Cloud のアーキテクチャの定義、実装、メンテナンスを担当する別のチームと協力して、クラスタ構成を計画し、設計してください。

このページは、会社の戦略に従って IT ソリューションとシステム アーキテクチャを定義する管理者とアーキテクトを対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

このページを読む前に、次の項目と Kubernetes の基本コンセプトを理解しておく必要があります。

クラスタ管理のレベル

クラスタ オプションについて説明する前に、クラスタに必要な柔軟性、責任、管理のレベルを理解することが重要です。必要とする管理レベルによって、GKE で使用するオペレーション モードと、作成が必要なクラスタ構成の選択肢が決まります。

GKE でクラスタを作成する場合は、次のいずれかのオペレーション モードを使用します。

  • Autopilot: 完全にプロビジョニングされたマネージド クラスタ構成を提供します。Autopilot クラスタは、本番環境ワークロードに対応する最適化されたクラスタ構成を使用してあらかじめ構成されています。

  • Standard: クラスタの基盤となるインフラストラクチャに高度な構成の柔軟性を提供します。Standard モードを使用して作成されたクラスタでは、ユーザーが本番環境ワークロードに必要な構成を決定します。

これらのモードの詳細と Autopilot の詳細については、GKE のオペレーション モードAutopilot の概要をご覧ください。

2 つのモードの対照比較については、GKE Standard と Autopilot の比較をご覧ください。

クラスタ構成の選択肢

オペレーション モードを選択したら、クラスタに必要な構成を選択します。Autopilot クラスタは、Standard クラスタよりも Google Cloud によってさらに完全に管理および構成されるため、使用できる構成の選択肢は少なくなります。

すべてのクラスタの構成オプションは、次のカテゴリに分類されます。

  • 名前とその他のメタデータ: 各クラスタには、プロジェクト内で一意の識別名が必要です。必要に応じて、クラスタの説明とラベルを追加することもできます。
  • 可用性と拡張性: クラスタ コントロール プレーンとノードを実行する場所と、複数のコントロール プレーン レプリカが必要かどうかを指定します。Autopilot クラスタはすべてリージョンになります。つまり、Google Cloud リージョン内の複数のコンピューティング ゾーンに複数のコントロール プレーンがあります。
  • フリート メンバーシップ: クラスタをフリートのメンバーにするかどうかを選択します。
  • ネットワーキング: クラスタが存在する Virtual Private Cloud(VPC)ネットワークとサブネット、パブリック ネットワークからクラスタにアクセスできるようにするかどうかなどのネットワーキング オプション。
  • バージョンとアップグレードの管理: リリース チャンネルを使用して、このクラスタのソフトウェアをアップグレードする際の新機能と安定性のバランスを選択します。また、メンテナンスの時間枠と除外を設定して、アップグレードを実行できるタイミングとできないタイミングを選択します。
  • セキュリティ: これには、クラスタが Workload Identity Federation for GKE を使用するかどうか、クラスタのノードが Google Cloud の認証に使用するサービス アカウントなどがあります。
  • クラスタ機能: バックアップやオブザーバビリティなど、このクラスタに対する追加の GKE 機能と Google Cloud 機能を有効にして構成します。Standard モードでは、有効期間の短いアルファ クラスタを作成して、Kubernetes のアルファ版機能を試すこともできます。

これに加えて、Standard クラスタには次のカテゴリのオプションもあります。

  • ノードプール: ノードプール、ノードのオペレーティング システム、ノードのサイズなど、クラスタのノードの詳細を指定します。

以降のセクションでは、これらのカテゴリの一部について詳しく説明します。特に、クラスタの作成後に設定を変更できないオプションについて説明します。構成オプションの完全なリストについては、構成リファレンスをご覧ください。

次の表は、Autopilot クラスタと Standard クラスタのいくつかの主要な領域で使用可能なオプションを比較したものです。

クラスタの可用性タイプ

GKE では、ワークロードの可用性要件と予算に合わせてクラスタを作成できます。Google Cloud リージョン内の複数のコンピューティング ゾーンに及ぶ、複数のコントロール プレーン レプリカがあるリージョン クラスタにするか、1 つのゾーンに 1 つのコントロール プレーンがあるゾーンクラスタにするかを選択できます。Autopilot クラスタは常にリージョン クラスタになります。

Standard モードで作成するクラスタタイプを選択する方法については、リージョンまたはゾーンのコントロール プレーンの選択をご覧ください。

これらの設定は、クラスタの作成後には更新できません。ゾーンクラスタをリージョン クラスタに変更することはできず、リージョン クラスタをゾーンクラスタに変更することもできません。

ベスト プラクティス:

本番環境ワークロードには、ゾーンクラスタよりも可用性が高いリージョン クラスタを使用します。開発環境の場合は、ゾーン ノードプールを使用するリージョン クラスタを使用します。リージョン コントロール プレーンとゾーン ノードプールを使用するクラスタの費用は、ゾーンクラスタと同じです。

リージョン クラスタ

リージョン クラスタには、指定した Google Cloud リージョン内の複数のゾーンで動作するコントロール プレーンの複数のレプリカが含まれています。Autopilot クラスタやその他のリージョン クラスタを作成するときは、必ずリージョンを指定する必要があります。

リージョン Standard クラスタの場合のみ、クラスタのノードが実行されるゾーンを選択することもできます。リージョン クラスタ内のノードは、構成されたノードのロケーションに応じて、複数のゾーンまたはシングルゾーンで実行できます。デフォルトでは、GKE は各ノードプールをコントロール プレーンのリージョンの 3 つのゾーンに複製します。Standard クラスタを作成するときや新しいノードプールを追加するときに、クラスタのノードが実行されるゾーンを指定してデフォルト構成を変更できます。すべてのゾーンは、コントロール プレーンと同じリージョン内に存在する必要があります。

本番環境ワークロードを実行するには、リージョン クラスタを使用します。リージョン クラスタの方がゾーンクラスタと比較して可用性に優れているためです。

クラスタの作成後にリージョン クラスタのリージョンは変更できません。

ゾーンクラスタ(Standard クラスタのみ)

ゾーンクラスタには、1 つのゾーン内に 1 つのコントロール プレーンが含まれています。ワークロード可用性の要件に応じて、ゾーンクラスタのノードを単一のゾーンに分散するか、複数のゾーンに分散するかを選択できます。

ゾーンクラスタを作成するには、ゾーンクラスタの作成をご覧ください。

シングルゾーン クラスタ

シングルゾーン クラスタには、1 つのゾーンで動作する 1 つのコントロール プレーンが含まれています。このコントロール プレーンは、同じゾーンで動作するノード上のワークロードを管理します。ワークロードを単一ゾーンで実行している場合、ゾーンが停止するとこのワークロードは使用できなくなります。

マルチゾーン クラスタ

マルチゾーン クラスタには、1 つのゾーンで動作するコントロール プレーンの 1 つのレプリカと、複数のゾーンで動作する複数のノードが含まれています。クラスタのアップグレード中や、コントロール プレーンが動作するゾーンの停止中にも、ワークロードは動作を継続します。ただし、コントロール プレーンが使用可能になるまでは、クラスタや、その中にあるノードとワークロードを構成できません。マルチゾーン クラスタでは、可用性とコストのバランスをとりながら一貫したワークロードが実現されます。ノードとノードプールの数が頻繁に変化するような環境で可用性を維持する必要がある場合は、リージョン クラスタの使用を検討してください。複数のゾーンでワークロードを実行しているときにゾーンが停止すると、そのゾーンではワークロードが中断されますが、他のゾーンでは引き続き実行を継続できます。

フリート メンバーシップ

組織で複数のクラスタを使用している場合は、Kubernetes クラスタの論理グループであるフリートにクラスタを追加することで、マルチクラスタ管理を簡素化できます。フリートを作成すると、組織は個々のクラスタを管理する体制から、クラスタ グループ全体を管理する体制にレベルアップでき、マルチクラスタ IngressConfig SyncPolicy Controller などのフリート対応機能を使用できます。

クラスタはいつでもフリートに追加できますが、GKE Enterprise を有効にしている場合は、クラスタの作成時に新しいクラスタをフリートに登録することを強くおすすめします。このようにして「フリートで生成される」クラスタは、多くのエンタープライズ機能用に選択されているフリートレベルのデフォルト設定を使用し、推奨されるログと指標がすでに有効になった状態で作成されるためです。詳しくは、次のガイドをご覧ください。

この設定は、クラスタの作成後に更新してクラスタを登録または登録解除できます。ただし、ライブ ワークロードがあるクラスタをフリート間で移動することはおすすめしません。

フリートにクラスタを追加する方法について詳しくは、フリートを作成してマルチクラスタ管理を簡素化するをご覧ください。

ネットワークの設定

GKE クラスタを作成するときに、クラスタが存在するネットワーク、ネットワーク ルーティング モード、パブリック ネットワークからクラスタノードにアクセスできるようにするかどうかなど、さまざまなネットワーク設定を指定できます。

自分がネットワーク管理者でない場合は、これらのオプションの多くはクラスタの作成後に変更できないため、プロダクション レディ クラスタを作成する前に組織のネットワーク スペシャリストに相談する必要があります。ネットワーク管理者の場合は、GKE ネットワーキングについてで GKE ネットワーキングの詳細を確認できます。ネットワーキング オプションのベスト プラクティスについては、GKE ネットワーキングのベスト プラクティスをご覧ください。このセクションでは、使用可能なネットワーキング オプションのサブセットのみについて説明します。

ネットワークとサブネット

クラスタが存在する Virtual Private Cloud(VPC)ネットワークによって、クラスタが通信できる他の Compute Engine リソースが決まります。デフォルトでは、GKE クラスタはプロジェクトのデフォルト ネットワークに作成されますが、自分または管理者が作成した別のネットワークを選択することもできます。可能な場合は、クラスタを特定の VPC サブネットに属するように指定できます。指定しない場合、デフォルトのサブネットが使用されます。必要に応じて、そのサブネット内の特定の IP アドレス範囲を Pod と Service に使用するように指定することもできます。

これらの設定は、クラスタの作成後に更新できません。

ネットワーク分離の選択肢

クラスタのネットワーク分離は、次の 2 つの側面を考慮してカスタマイズできます。

  • コントロール プレーンへのアクセス: デフォルトでは、コントロール プレーンの内部エンドポイントと外部エンドポイントの両方が有効になり、DNS ベースのエンドポイントは無効になります。以下からオプションを選ぶことができます。

    • 外部エンドポイントと内部エンドポイントの両方を無効にして、DNS エンドポイントのみを使用する。
    • 外部クライアントへのアクセスを防ぐために、外部エンドポイントのみを無効にする。
    • 承認済みネットワークを有効にして、コントロール プレーン エンドポイントに到達する IP アドレスを制御する。
  • クラスタ ネットワーキングの構成: クラスタでプライベート ノードを有効にして、ワークロードをパブリック ネットワークから完全に分離できます。プライベート ノードをクラスタ全体、ノードプール(Standard の場合)またはワークロード(Autopilot の場合)レベルで有効にできます。ノードプールまたはワークロード レベルでプライベート ノードを有効にすると、クラスタレベルのノード構成がオーバーライドされます。

これらの設定は、クラスタの作成後に変更できます。

ネットワーク分離の詳細については、ネットワーク分離のカスタマイズ関するページをご覧ください。

ベスト プラクティス:

Cloud NAT を使用して、GKE Pod がパブリック IP アドレスでリソースにアクセスできるようにします。Cloud NAT を使用すると、Pod は直接インターネットに公開されませんが、インターネットに接続するリソースにはアクセスできるため、クラスタの全体的なセキュリティ ポスチャーが向上します。

VPC ネイティブ クラスタとルートベース クラスタ

GKE では、Pod 間でトラフィックを転送する方法によってクラスタを区別できます。エイリアス IP アドレスを使用するクラスタは、VPC ネイティブ クラスタと呼ばれます。Google Cloud のルートを使用するクラスタは、ルートベース クラスタと呼ばれています。

デフォルトでは、新しい GKE クラスタはすべて VPC ネイティブ ルーティングを使用します。こちらのオプションをおすすめします。この設定は、Standard モードでのみルートベース クラスタを作成するように、クラスタの作成時に変更できます。この設定は、クラスタの作成後に更新できません。

VPC ネイティブ クラスタとそのメリット(特別な要件など)の詳細については、VPC ネイティブ クラスタをご覧ください。

ベスト プラクティス:

クラスタに VPC ネイティブ ネットワーク モードを使用します。これは Autopilot クラスタのデフォルトです。

バージョンとアップグレード

リリース チャンネルを使用すると、GKE は機能の可用性と安定性のバランスを考慮して、クラスタのソフトウェア バージョンを選択します。クラスタを作成するときに、使用するリリース チャンネルを選択できます。新しいクラスタ(Autopilot と Standard の両方)は、デフォルトで Regular リリース チャンネルに登録されますが、必要に応じてクラスタの作成時に特定のバージョンを選択できます。

Autopilot クラスタは常にリリース チャンネルを使用します。Standard クラスタはデフォルトでリリース チャンネルを使用しますが、クラスタをリリース チャンネルに登録しないように選択することもできます(ただし、この設定ではクラスタ機能へのアクセスが制限されるため、おすすめしません)。

GKE は、リリース チャンネルに登録されているかどうかに関係なく、時間の経過とともにすべてのクラスタを自動的にアップグレードします。そのリリース チャンネルで新しいバージョンが利用可能になると、GKE はクラスタのコントロール プレーンとそのノードを自動的にアップグレードします。アップグレードのタイミングと範囲は、メンテナンスの時間枠と除外で制御できます。

クラスタのリリース チャンネルはいつでも変更できます。

今後の自動アップグレードについては、GKE リリースノートをご覧ください。

ベスト プラクティス:

GKE のリリース チャンネルを選択し、機能の可用性と安定性のバランスを考慮してクラスタのバージョンを選択します。メンテナンスの時間枠と除外を使用して、自動アップグレードのタイミングと範囲を制御します。

アルファ版機能(Standard クラスタのみ)

Kubernetes の新機能は、開発状況に応じてアルファ版、ベータ版、安定版のいずれかで示されます。ほとんどの場合、ベータ版または安定版として表示された Kubernetes 機能が GKE に同梱されます。

本番環境に対応していない新しい機能をテストする場合は、特別な GKE アルファ クラスタでアルファ版機能を使用できます。アルファ クラスタでは、すべての Kubernetes アルファ API(機能ゲートともいう)が有効になっています。アルファ クラスタは、Kubernetes 機能の早期テストや検証に使用できます。アルファ クラスタは本番環境ワークロードではサポートされず、アップグレードやリリース チャンネルへの追加もできません。また、30 日以内に期限が切れます。

アルファ版機能は、Autopilot クラスタでは使用できません。

アルファ クラスタを作成するには、アルファ クラスタの作成をご覧ください。

セキュリティ設定

GKE には、クラスタの作成時に指定できる多くのセキュリティ設定があります。たとえば、暗号化設定、Binary Authorization などのセキュリティ機能、クラスタのノードに使用するサービス アカウント(次のセクションで詳しく説明します)、クラスタで Workload Identity Federation for GKE を使用するかどうかなどです。

他の設定と同様、プロダクション レディ クラスタを作成する前に、専門知識のある同僚(この場合は組織のセキュリティ スペシャリスト)に相談する必要があります。GKE セキュリティの詳細については、セキュリティの概要クラスタ セキュリティを強化するをご覧ください。

ノードのサービス アカウント

各 GKE ノードには、Google Cloud APIs やサービスへの認証に使用するサービス アカウントがあります。Autopilot クラスタの場合は、クラスタ全体に指定します。Standard クラスタの場合は、ノードプールごとに指定します。デフォルトでは、GKE はノードに Compute Engine のデフォルトのサービス アカウントを使用しますが、別のカスタム サービス アカウントを指定することもできます。

この設定は、クラスタ(Autopilot の場合)またはノードプール(Standard の場合)の作成後に変更できません。選択したサービス アカウントや組織のポリシーによっては、選択内容が、指標の書き込みなど、クラスタが Google Cloud サービスを使用できるかどうかに影響する可能性があります。ただし、必要な権限が付与されている場合は、サービス アカウントに追加の権限を付与できます。

ベスト プラクティス:

セキュリティを強化するため、ノードに IAM の編集者ロール(2024 年 5 月より前に作成された組織のデフォルトの動作)が付与されている場合は、Compute Engine のデフォルトのサービス アカウントを使用しないでください。このロールには、クラスタの実行に必要な権限よりも多くの権限が付与されています。代わりに、デフォルトのサービス アカウントの権限を変更するか、権限の制限が緩いカスタム サービス アカウントを使用してください。組織で、デフォルトのサービス アカウントに編集者の権限が付与されないように、すでに指定されている場合があります。その場合は、ユーザーまたは ID とアカウントの管理者がデフォルトのサービス アカウントに適切なロールを付与できます。

ノードプールの設定(Standard クラスタのみ)

クラスタ管理の概要GKE のオペレーション モードで説明したように、クラスタに Autopilot を使用する場合は GKE がノードを構成するので、ユーザーがノード構成を考慮する必要はありません。Autopilot クラスタノードはすべて GKE によるフルマネージドとなり、すべて同じノードのオペレーティング システム(OS)を使用します。

Standard クラスタの作成を選択した場合は、クラスタの作成時に次のように多数のノード オプションを指定できます。

  • 使用するノードプールの名前、数、サイズ、ロケーション。ノードプールとは、共通の構成を共有する、クラスタ内のノードのグループです。
  • 新しいノードに使用するノードの OS。
  • ノードにエフェメラル Spot VM を使用するかどうか。
  • ノードに使用する Compute Engine のマシンタイプ
  • セキュリティ設定の説明にある、ノードに使用するサービス アカウント。

クラスタのノードプールの設定の一部は、クラスタの作成後に変更できますが、すべての Standard クラスタには少なくとも 1 つのノードプールが必要です。ノードプールの構成の詳細については、ノードプールの追加と管理をご覧ください。

構成リファレンス

使用可能な構成オプションの一覧については、次のリファレンス ガイドをご覧ください。

次のステップ