フリートの要件とベストプラクティス

このガイドでは、組織内でのフリートの実装に関するおすすめの方法、実践的な考慮事項、推奨事項を示します。

このガイドを読む前に、フリートの仕組みのコンセプトを理解しておく必要があります。こちらの例をご覧になる前に、このガイドを読むことをおすすめします。

コンポーネントの要件

組織が使用するフリート対応の GKE Enterprise と Google Cloud コンポーネントに基づいてフリートを実装する場合は、考慮すべきいくつかの制限事項があります。たとえば、現時点で一部のコンポーネントは、フリートのホストプロジェクトに含まれていないクラスタでの作業に対応していない場合があります。

次の表に、各コンポーネントの現在の要件と制限事項を示します。この表には、GKE Enterprise に含まれているものの、Fleet API を使用して構成するのではない機能も記載されています。

コンポーネント	クラスタの種類	プロジェクト要件	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 クラスタもサポートされていますが、手動での設定作業が必要です。	なし	なし
Binary Authorization	Google Cloud 上の GKE クラスタ、GKE on Bare Metal、GKE on VMware	なし	なし
Advanced Vulnerability Insights	Google Cloud 上の GKE クラスタ	なし	なし
GKE のセキュリティポスチャー	Google Cloud 上の GKE クラスタ	なし	なし
GKE のセキュリティポスチャー	Google Cloud 上の GKE クラスタ	なし	なし
コンプライアンス体制	Google Cloud 上の GKE クラスタ	なし	なし
フリートのリソース使用率の指標	Google Cloud 上の GKE クラスタ	なし	なし
フリートのロギング	すべて	なし	なし
Connect Gateway	すべて	なし	なし
フリートチーム管理	すべて	なし	なし
Pod FQDN ネットワークポリシー	Google Cloud 上の GKE クラスタ	なし	なし
ノード間の透過的暗号化	Google Cloud 上の GKE クラスタ	なし	なし
Config Controller	該当なし	なし	なし
ロールアウトシーケンス	Google Cloud 上の GKE クラスタ	なし	なし

フリート用のプロジェクトと 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 を有効にする前に、どのサービスエンドポイントがリソース間でマージされるのかを把握し、意図したとおりの結果となっていることを確認します。

フリート対応のコンポーネントを構成する場合の、より具体的なガイダンスは、今後フリートのコンセプトを深める過程で提供してまいります。

次のステップ

このガイドで説明する考慮事項を示す架空のシナリオについて、フリートの例で確認する。

フリートの要件とベスト プラクティス