このドキュメントでは、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 クラスタを作成するをご覧ください。