このドキュメントでは、Kubernetes クラスタで使用できる構成オプションについて説明します。単一のプロジェクト内で機能する Kubernetes クラスタを作成することも、複数のプロジェクトにまたがる Kubernetes クラスタを作成することもできます。これにより、Google Distributed Cloud（GDC）エアギャップでコンテナ ワークロードを管理する戦略に沿ってクラスタを構成できます。クラスタ構成では、管理アクションに対してさまざまな権限ベースの制御も提供されます。これにより、GDC でコンテナ ワークロードの設定を管理したり、ユースケースに基づいて手動で構成して柔軟性を高めることができます。
このドキュメントは、次の読者グループを対象としています。
コンテナ ワークロードをホストする Kubernetes クラスタの作成を担当するプラットフォーム管理者グループの IT 管理者。
エアギャップ環境でコンテナ アプリケーションの開発を担当するアプリケーション オペレーター グループのアプリケーション デベロッパー。
詳細については、GDC エアギャップの対象読者に関するドキュメントをご覧ください。
構成オプション
GDC には、さまざまなレベルの管理と柔軟性を提供する 2 つのクラスタ構成があります。
- 共有クラスタ: プラットフォーム管理者グループによって管理されるマルチプロジェクト Kubernetes クラスタ。組織レベルで統合されたマネージド サービスのフルスイートを提供します。
- 標準クラスタ: アプリケーション オペレータ グループによって管理される単一プロジェクトのセルフサービス Kubernetes クラスタ。共有環境のマネージド サービスと競合する可能性のあるカスタム ワークロードに対して、より高い柔軟性を提供します。
次の表に、共有 Kubernetes クラスタと標準 Kubernetes クラスタの違いを示します。
| 機能 | 共有クラスタ | Standard クラスタ |
|---|---|---|
| オーナー | プラットフォーム管理者グループ | アプリケーション オペレーター グループ |
| クラスタ管理者 | プラットフォーム管理者グループ | プラットフォーム管理者グループまたはアプリケーション オペレーター グループ |
| テナンシー | 複数のプロジェクト | 単一プロジェクト |
| 実装 | 作成、読み取り、更新、削除、アップグレード | 作成、読み取り、更新、削除、アップグレード |
| モニタリング | Kubernetes 用 Grafana ダッシュボードを使用した Prometheus | Kubernetes 用 Grafana ダッシュボードを使用した Prometheus |
| プロジェクト間の上り（内向き）と下り（外向き） | GDC によって管理される | 構成可能 |
| バックアップと復元 | クラスタ、プロジェクト、ワークロード | クラスタ、プロジェクト、ワークロード |
| Kubernetes Namespace の管理 | GDC によって管理される | 構成可能 |
| カスタム リソースとコントローラ | GDC によって管理される | 構成可能 |
| ロギング | GDC によって管理される | GDC によって管理される |
| 監査と請求 | GDC によって管理される | 構成可能 |
| リソースの種類 | ゾーンのみ | ゾーンのみ |
| Surface サポート | GDC コンソール、API、Terraform | API と Terraform |
| マネージド サービス | 構成できない保護されたサービスの包括的なセットが含まれています。 | 最小限の必須サービスが含まれており、サービスの柔軟性が向上します。 |
| Marketplace のサービス | マーケットプレイス サービスとの統合が含まれます。 | 統合には使用できません。 |
詳細については、次のクラスタ構成のセクションをご覧ください。
共有クラスタ
共有クラスタは、Istio、Gatekeeper、Managed Harbor Service、Nginx などの一連の保護されたサービスを含むシステム管理クラスタを提供します。クラスタのシステム管理アプローチでは、platform Namespace で実行され、既存のプロジェクトに接続できる Kubernetes クラスタ構成が提供されます。
共有クラスタは複数のプロジェクトにまたがることができるため、組織スコープになります。つまり、一部のユーザー グループでの可用性が制限されます。プラットフォーム管理者グループは、主に共有クラスタを作成して管理します。アプリケーション デベロッパーによる監督はほとんどありません。
プロジェクト間の上り（内向き）と下り（外向き）のネットワーキング トラフィックは GDC によって管理されます。ネットワーキング ポリシーは通常、プロジェクト ネットワーク ポリシーを使用して処理されます。
共有クラスタの主なユースケースは次のとおりです。
- カスタマイズをほとんど必要とせず、マネージド機能の完全なエコシステムをデフォルトで提供するクラスタが必要です。
- 複数のプロジェクトにわたってコンテナ ワークロードを管理する。
- 既存のクラウド環境からワークロードを移行する要件がない。
共有クラスタの作成の詳細については、共有クラスタを作成するをご覧ください。
Standard クラスタ
Standard クラスタは、Prometheus や Grafana などの最小限のサービスを含む構成可能な Kubernetes クラスタを提供します。標準クラスタには、必要な Kubernetes コンテナ ワークロード機能に不可欠なサービスのみが含まれています。追加のサービスをインストールして、ユースケースに合わせてクラスタをカスタマイズできます。
標準クラスタはプロジェクト内でのみスコープ設定されるため、プロジェクト内に限定されたアプリケーション デベロッパーは、その機能方法を直接制御できます。アプリケーション オペレーター グループは、主にプラットフォーム管理者の監督をほとんど受けずに標準クラスタを作成して管理します。
多くの場合、アプリケーション デベロッパーは、GDC 固有のネットワーキング構成に依存するのではなく、標準の Kubernetes ネットワーキング API を使用してクラスタ ネットワーキングを制御します。ただし、標準クラスタでは、次のような GDC 固有のネットワーキング構成のサブセットを構成できます。
- ポリシー
- ロード バランシング
- Cloud NAT
標準クラスタの主なユースケースは次のとおりです。
- デフォルトで最小限のサービスを提供するクラスタが必要です。これにより、ニーズに合わせて包括的な構成が可能になります。
- カスタム リソース定義や Namespace などの Kubernetes 構造をより詳細に制御したい。
- コンテナ ワークロードを単一のプロジェクト内でのみ管理する場合。
- 既存のクラウド環境に既存のコンテナ ワークロードがあり、GDC のエアギャップ環境に移行したい。
Standard クラスタの作成の詳細については、Standard クラスタを作成するをご覧ください。