このガイドでは、組織内でのフリートの実装に関するおすすめの方法、実践的な考慮事項、推奨事項を示します。
このガイドを読む前に、フリートの仕組みのコンセプトを理解しておく必要があります。こちらの例をご覧になる前に、このガイドを読むことをおすすめします。
コンポーネントの要件
組織が使用するフリート対応の GKE Enterprise と Google Cloud コンポーネントに基づいてフリートを実装する場合は、考慮すべきいくつかの制限事項があります。たとえば、現時点で一部のコンポーネントは、フリートのホスト プロジェクトに含まれていないクラスタでの作業に対応していない場合があります。
次の表に、各コンポーネントの現在の要件と制限事項を示します。
| コンポーネント |
クラスタの種類 |
プロジェクト要件 |
VPC の要件 |
|---|---|---|---|
| Config Sync | GKE Enterprise でサポートされるすべてのクラスタ | なし | なし |
| Policy Controller | GKE Enterprise でサポートされるすべてのクラスタ | なし | なし |
| Anthos Service Mesh | サポートされているプラットフォームをご覧ください | クラスタをフリートに登録し、同じプロジェクト内のクラスタをすべて同じフリートに登録する必要があります。詳細については、Anthos Service Mesh のフリートの要件をご覧ください。 | GKE クラスタは同じ VPC ネットワーク内にある必要があります。 |
| マルチクラスタ Ingress | Google Cloud 上の GKE クラスタ | Ingress リソース、GKE クラスタ、フリートは同じプロジェクトを共有する必要があります。 | Ingress リソースと GKE クラスタは同じ VPC ネットワーク内に存在する必要があります。 |
| Workload Identity プール | GKE Enterprise、Google Cloud 上の GKE、GKE on VMware 向けに最適化されています。GKE Enterprise では他の Kubernetes クラスタもサポートされていますが、手動での設定作業が必要です。 | なし | なし |
フリート用のプロジェクトと VPC ネットワークの構成
フリートを設計する際は、Google Cloud プロジェクトと Virtual Private Cloud（VPC）ネットワークという 2 つの基本的なリソースを考慮する必要があります。
フリートの仕組みで説明したように、各フリートは 1 つのプロジェクト内に作成されます。ただし（上の表に示した制限により）、フリートはフリートホスト プロジェクト、別の Google Cloud プロジェクト、その他のクラウド プロバイダ、またはオンプレミスのフリート対応リソースを扱うことを目的としています。
ほとんどの場合は明示的に防止されませんが、同じプロジェクト内のフリート対応リソースを同じフリートに追加することをおすすめします。異なるフリートに分割しないでください。同じプロジェクトのリソースを複数のフリートに分割すると、プロジェクトの境界によってポリシーとガバナンスがより強固に保護されるため、アンチパターンとみなされます。
Google は、フリート対応リソースを複数のプロジェクトに配置する方法を決定する際に、多くの組織で異なるテナント要件が必要になることを想定しています。次の 2 つの極を考えてみましょう。
- 一方の極には、すべてのフリート対応リソースを一元管理された数個のプロジェクトに配置し、名前空間を複数のチームに割り当てる組織があります。
- もう一方の極には、チーム独自のプロジェクト内で専用のクラスタを用意する組織があります。
最初の極の組織では、リソース全体で一元管理によるガバナンスを維持するほうが簡単なものの、目的の分離を実現するには追加の作業が必要になることがあります。2 番目の極の組織では、このトレードオフが逆になります。複雑な場合には、共有インフラストラクチャ リソースと専用のリソースを別々のプロジェクトに分離して設定することも考えられます。最終的な結論によらず、高信頼関係のセクションで説明したように、フリートに登録されたリソースに対して相互信頼関係を維持することがフリート整合性を保持するうえで重要です。
プロジェクトの編成と密接に関連しているのは、ネットワークの編成です。コンポーネント要件の表に記載されているように、いくつかのフリート コンポーネントでは、フリート内で登録されたリソース間の特定の接続が必要です。こうした要件は今後緩和されるかもしれませんが、今のところ、たとえばマルチクラスタ Ingress では、Pod は同じ VPC ネットワーク内になくてはならず、クラスタ自体はフリートと同じプロジェクトになくてはなりません。
Googleは、初期プロジェクトと VPC ネットワークの要件をコンポーネントで緩和できる場合、複数のプロジェクトが必要となるときには常に、共有 VPC モデルの採用が推奨されるものと想定しています。このようなモデルでは、各サービス プロジェクトから登録されたリソースを使用して VPC ネットワークのホスト プロジェクトでフリートをインスタンス化できます。共有 VPC で複数のフリートが必要な場合は、プロジェクトをフリートのホスト プロジェクトに指名できます。
フリート リソース（クラスタ）の追加 / 削除
既存のフリート対応リソースは、フリートに追加できますが、追加した結果、サービスが中断されないようにするために特別な注意を払う必要があります。特に大切なのは、フリートにリソースを追加する前に、必ず同一性と信頼性のプロパティを考慮することです。フリート管理者は、アクティブなフリート コンポーネントによる同一性の扱いに特別な注意を払う必要があります。これによって、フリートへのリソースの追加前に、一貫した命名方法への移行やリソースのガバナンスの確立などのアクションを実行することが必要になる可能性があります。
フリートからリソースを削除する際には、さらに注意が必要です。たとえば、サービス メッシュのアクティブな構成要素であるリソースや、マルチクラスタ ロードバランサの一部としてターゲットに設定されているリソースに影響します。リソースを削除する準備として、フリートで有効にした各コンポーネントを確認し、必要な手順を実施してアクティブなサービス メッシュ トラフィックまたは外部トラフィックをドレインすることをおすすめします。
フリート リソースを追加および削除する際のより具体的なガイダンスについては、今後のフリートの進化にあわせて提供してまいります。
フリート コンポーネントの有効化または再構成
フリートを使用する Google Cloud または GKE Enterprise コンポーネントの有効化または再構成を行う際には、特別な注意が必要です。新しいコンポーネントを有効にする場合は、すべてのクラスタでコンポーネントを有効にすることにより副作用が生じる可能性があることに注意する必要があります。たとえば、Anthos Service Mesh を有効にする前に、どのサービス エンドポイントがリソース間でマージされるのかを把握し、意図したとおりの結果となっていることを確認します。
フリート対応のコンポーネントを構成する場合の、より具体的なガイダンスは、今後フリートのコンセプトを深める過程で提供してまいります。
次のステップ
- このガイドで説明する考慮事項を示す架空のシナリオについて、フリートの例で確認する。