このページでは、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）ネットワークとサブネット、パブリック ネットワークからクラスタにアクセスできるようにするかどうかなどのネットワーキング オプション。
- バージョンとアップグレード管理: リリース チャンネルを使用して、このクラスタのソフトウェアをアップグレードする際の新機能と安定性のバランスを選択します。また、メンテナンスの時間枠と除外を設定して、アップグレードを実行できるタイミングとできないタイミングを選択します。
- セキュリティ: これには、クラスタが GKE 用 Workload Identity 連携を使用するかどうか、クラスタのノードが Google Cloud の認証に使用するサービス アカウントが含まれます。
- クラスタ機能: バックアップやオブザーバビリティなど、このクラスタの GKE 機能と Google Cloud 機能を有効にして構成します。Standard モードでは、有効期間の短いアルファ クラスタを作成して、Kubernetes のアルファ版機能を試すこともできます。
これに加えて、Standard クラスタには次のカテゴリのオプションもあります。
- ノードプール: ノードプール、ノードのオペレーティング システム、ノードのサイズなど、クラスタのノードの詳細を指定します。
以降のセクションでは、これらのカテゴリの一部について詳しく説明します。特に、クラスタの作成後に設定を変更できないオプションについて説明します。構成オプションの完全なリストについては、構成リファレンスをご覧ください。
次の表に、Autopilot クラスタと Standard クラスタのいくつかの主要な領域で使用可能なオプションを比較します。
| クラスタの選択肢 | モード | |
|---|---|---|
| Autopilot | Standard | |
| 可用性タイプ | リージョン | リージョンまたはゾーン |
| リリース チャンネル | Rapid、Regular、Stable | チャネルなし |
| クラスタのバージョン | デフォルトまたは他の利用可能なバージョン | デフォルトまたは他の利用可能なバージョン |
| ネットワーク ルーティング | VPC ネイティブ | VPC ネイティブまたはルートベース |
| ネットワーク分離 | カスタマイズ可能 | カスタマイズ可能 |
| Kubernetes の機能 | 本番環境 | 本番環境またはアルファ版 |
クラスタの可用性タイプ
GKE では、ワークロードの可用性要件と予算に合わせてクラスタを作成できます。Google Cloud リージョン内の複数のコンピューティング ゾーンに複数のコントロール プレーン レプリカがあるリージョン クラスタと、単一ゾーンに単一のコントロール プレーンがあるゾーンクラスタのどちらかを選択できます。Autopilot クラスタは常にリージョン クラスタです。
Standard モードで作成するクラスタタイプを選択する方法については、リージョンまたはゾーンのコントロール プレーンの選択をご覧ください。
これらの設定は、クラスタの作成後に更新できません。ゾーンクラスタをリージョン クラスタに変更することはできず、リージョン クラスタをゾーンクラスタに変更することもできません。
本番環境ワークロードには、通常、ゾーンクラスタよりも可用性が高いリージョン クラスタを使用します。開発環境の場合は、ゾーン ノードプールを使用するリージョン クラスタを使用します。リージョン コントロール プレーンとゾーンノードプールを使用するクラスタの費用は、ゾーンクラスタと同じです。リージョンの詳細については、リージョンとゾーンをご覧ください。
リージョン クラスタ
リージョン クラスタには、指定した Google Cloud リージョン内の複数のゾーンで動作するコントロール プレーンの複数のレプリカが含まれています。Autopilot クラスタやその他のリージョン クラスタを作成するときは、必ずリージョンを指定する必要があります。
リージョン Standard クラスタの場合のみ、クラスタのノードが実行されるゾーンを選択することもできます。リージョン クラスタ内のノードは、構成されたノードのロケーションに応じて、複数のゾーンまたは単一ゾーンで実行できます。デフォルトでは、GKE は各ノードプールをコントロール プレーンのリージョンの 3 つのゾーンに複製します。Standard クラスタを作成するときや新しいノードプールを追加するときに、クラスタのノードが実行されるゾーンを指定してデフォルト構成を変更できます。すべてのゾーンは、コントロール プレーンと同じリージョン内に存在する必要があります。
本番環境ワークロードを実行するには、リージョン クラスタを使用します。リージョン クラスタの方がゾーンクラスタと比較して可用性に優れているためです。
- リージョン Standard クラスタを作成するには、リージョン クラスタの作成をご覧ください。
- リージョン Autopilot クラスタを作成するには、Autopilot クラスタの作成をご覧ください。
クラスタの作成後にリージョン クラスタのリージョンを変更することはできません。
ゾーンクラスタ（Standard クラスタのみ）
ゾーンクラスタには、1 つのゾーン内に 1 つのコントロール プレーンが含まれています。ワークロードの可用性の要件に応じて、ゾーンクラスタのノードを単一のゾーンに分散するか、複数のゾーンに分散するかを選択できます。
ゾーンクラスタを作成するには、ゾーンクラスタの作成をご覧ください。
シングルゾーン クラスタ
シングルゾーン クラスタには、1 つのゾーンで動作する 1 つのコントロール プレーンが含まれています。このコントロール プレーンは、同じゾーンで動作するノード上のワークロードを管理します。ワークロードを単一ゾーンで実行している場合、ゾーンが停止するとこのワークロードは使用できなくなります。
マルチゾーン クラスタ
マルチゾーン クラスタには、1 つのゾーンで動作するコントロール プレーンの 1 つのレプリカと、複数のゾーンで動作する複数のノードが含まれています。クラスタのアップグレード中や、コントロール プレーンが動作するゾーンの停止中にも、ワークロードは動作を継続します。ただし、コントロール プレーンが使用可能になるまでは、クラスタや、その中にあるノードとワークロードを設定できません。マルチゾーン クラスタでは、可用性とコストのバランスをとりながら一貫したワークロードが実現されます。ノードとノードプールの数が頻繁に変化するような環境で可用性を維持する必要がある場合は、リージョン クラスタの使用を検討してください。複数のゾーンでワークロードを実行しているときにゾーンが停止すると、そのゾーンではワークロードが中断されますが、他のゾーンでは引き続き実行を継続できます。
クラスタの階層
GKE エディションで説明したように、GKE には 2 つの機能階層があります。1 つはすべての GKE ユーザーが利用できるスタンダード ティアで、もう 1 つはエンタープライズ規模で作業するための強力な機能を追加したエンタープライズ ティアです。これらの機能の多くは、GKE フリート管理に基づいています。
Google Cloud 上の GKE クラスタの場合、追加の機能階層をクラスタごとに追加するかどうかを選択します。クラスタが GKE Enterprise ティアに登録されると、利用可能なすべてのエンタープライズ機能を使用できるようになります。クラスタ階層を指定しない場合は、一部の例外を除き、デフォルトで標準階層が使用されます。
クラスタ階層を選択する際は、次の点を理解してください。
- GKE Enterprise の多くの機能は、動作するためにフリート メンバーシップが必要です。クラスタをフリートに登録するタイミングは、クラスタの作成時またはクラスタの作成後です。クラスタでフリート対応の GKE Enterprise 機能を使用する場合、クラスタの作成時にクラスタをフリートに登録することをおすすめします。これにより、クラスタは Enterprise 機能のフリートレベルの設定を継承します。詳細については、フリート メンバーシップをご覧ください。
- クラスタの Enterprise ティアを有効にできるのは、クラスタのプロジェクトで GKE Enterprise（Anthos）API が有効になっている場合のみです。
この設定は、クラスタの作成後に変更できます。
フリート メンバーシップを必要としない機能のサブセットなど、GKE Enterprise に含まれる機能の詳細については、 GKE Enterprise のデプロイ オプションをご覧ください。
フリート メンバーシップ
組織で複数のクラスタを使用している場合は、Kubernetes クラスタの論理グループであるフリートにクラスタを追加することで、マルチクラスタ管理を簡素化できます。フリートを作成すると、組織は個々のクラスタを管理する体制から、クラスタ グループ全体を管理する体制にレベルアップでき、マルチクラスタ Ingress、Config Sync、Policy 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 は、ノードに接続されている IAM サービス アカウントを使用して、ロギングやモニタリングなどのシステムタスクを実行します。少なくとも、これらのノード サービス アカウントには、プロジェクトに対する Kubernetes Engine デフォルト ノード サービス アカウント（roles/container.defaultNodeServiceAccount）ロールが必要です。デフォルトでは、GKE はプロジェクトで自動的に作成される Compute Engine のデフォルトのサービス アカウントをノード サービス アカウントとして使用します。
組織で iam.automaticIamGrantsForDefaultServiceAccounts 組織のポリシー制約が適用されている場合、プロジェクトのデフォルトの Compute Engine サービス アカウントに GKE に必要な権限が自動的に付与されないことがあります。
プロジェクトまたは組織内の他の機能に Compute Engine のデフォルトのサービス アカウントを使用すると、サービス アカウントに GKE が必要とする以上の権限が付与され、セキュリティ リスクにさらされる可能性があります。
Autopilot モードのクラスタまたは Standard モードのノードプールのサービス アカウントは、作成後に変更できません。
ノードプールの設定（Standard クラスタのみ）
クラスタ管理の概要と GKE の運用モードで説明したように、クラスタに Autopilot を使用する場合、GKE がノードを構成するため、ノード構成について心配する必要はありません。Autopilot クラスタノードはすべて GKE によって完全に管理され、すべて同じノード オペレーティング システム（OS）を使用します。
Standard クラスタを作成する場合は、クラスタの作成時に次のノード オプションを指定できます。
- 使用するノードプールの名前、数、サイズ、ロケーション。ノードプールとは、共通の構成を共有する、クラスタ内のノードのグループです。
- 新しいノードに使用するノード OS。
- ノードにエフェメラル Spot VM を使用するかどうか。
- ノードに使用する Compute Engine のマシンタイプ。
- セキュリティ設定で説明されているように、ノードに使用するサービス アカウント。
クラスタのノードプールの設定の一部は、クラスタの作成後に変更できますが、すべての Standard クラスタには少なくとも 1 つのノードプールが必要です。Standard クラスタを作成するときにノード数とマシンタイプを指定しない場合、デフォルトのノードプールは、クラスタの各ゾーンに 3 つのノード、デフォルトのノードイメージ cos_containerd、汎用マシンタイプで構成されます。
ノードプールの構成の詳細については、ノードプールについてとノードプールの追加と管理をご覧ください。
構成リファレンス
使用可能な構成オプションの一覧については、次のリファレンス ガイドをご覧ください。
gcloud container clusters create-auto: Autopilot クラスタの Google Cloud CLI リファレンスgcloud container clusters create: Standard クラスタの Google Cloud CLI リファレンスgoogle_container_cluster: Terraform リファレンス
次のステップ
- クラスタ アーキテクチャの詳細については、GKE クラスタ アーキテクチャをご覧ください。
- GKE Standard と Autopilot の比較で、Standard クラスタと Autopilot クラスタの比較を確認します。 * クラスタの作成を開始します。