Environ の導入

Environ は、クラスタなどのリソースを論理的に編成するための Google Cloud のコンセプトです。Environ では、マルチクラスタ機能の使用と管理、システム間での一貫したポリシーの適用が可能になります。Environ は、エンタープライズ マルチクラスタ機能を Anthos で機能させるうえで重要な役割を果たします。一部の Google Kubernetes Engine(GKE)機能で使用されることもあります。

このガイドでは Environ について紹介します。具体的には、Environ の意味、コンポーネントで Environ が使用される場所、Environ レベルの機能を活用できるようにシステムをセットアップする方法について説明します。また、クラスタとシステム管理の簡素化に役立ついくつかのや、Environ を使ってマルチクラスタ システムを構築して運用する際のベスト プラクティスも紹介しています。

このガイドは、複数のクラスタと関連インフラストラクチャを利用するシステム アーキテクト、プラットフォーム オペレータ、サービス オペレータなどの技術リーダーを対象としています。これらのコンセプトは、Google Cloud 上、複数のクラウド プロバイダ間、オンプレミスなど、複数のクラスタを組織で実行しているあらゆる場所で役立ちます。

このガイドは、Kubernetes の基本的なコンセプト(クラスタなど)に精通していることを前提としています。精通していない場合は、Kubernetes の基礎GKE のドキュメントAnthos Service Mesh 用アプリケーションの準備をご覧ください。

Anthos と Environ を使用するコンポーネントの詳細については、Anthos の技術概要Anthos を試すのチュートリアルをご覧ください。ただし、このガイドに沿って操作を行うために Anthos に精通している必要はありません。

はじめに

通常、組織がコンテナやコンテナ オーケストレーション、サービス メッシュなどのクラウドネイティブ テクノロジーを利用していると、単一クラスタを実行しているだけでは不十分になってきます。技術やビジネスの目標を達成するために、組織はさまざまな理由から複数のクラスタをデプロイします。たとえば、本番環境と非本番環境の分離や、層、ロケール、チーム間でサービスの分離を行います。マルチクラスタ アプローチの利点とトレードオフについては、複数クラスタのユースケースをご覧ください。

クラスタの数が増えると、これらのクラスタとそのリソースに対する管理とガバナンスが難しくなります。多くの場合、必要なレベルの制御を実現するために、組織はカスタムツールと運用ポリシーの構築を行います。

Google Cloud には、管理者が複数のクラスタを管理する際に役立つ Environ のコンセプトが用意されています。Environ では、クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になります。Environ は Anthos と GKE 両方のコンテキストで使用できます。Environ を活用できる Anthos コンポーネントと GKE コンポーネントのリストについては、このドキュメント後半の Environ 対応コンポーネントのセクションをご覧ください。

Environ を導入することで、組織は個々のクラスタを管理している状態から、クラスタ グループ全体を管理する体制へと強化できます。さらに、Environ で必要な正規化は、Google 社内で使用されるようなベスト プラクティスをチームに導入する場合にも役立ちます。組織リソースは Google Cloud リソース階層のルートノードで、そのルートノード内でグループ化されたリソースのポリシーと制御に使用されます。Environ では、複数のクラスタを管理するためのルートを形成します。

用語

ここでは Environ に関する重要な用語についていくつか説明します。

Environ-aware のリソース

Environ-aware リソースは、Environ として論理的にグループ化と管理が可能な Google Cloud プロジェクトのリソースです。現時点で Environ メンバーになれるのは Kubernetes クラスタだけです。ただし、仮想マシン(VM)インスタンスやその他のリソースは、将来のプラットフォーム リリースで Environ に参加できるようにする予定です。Google Cloud には、リソースを Environ メンバーとして登録するための Connect サービスが用意されています。

Environ ホスト プロジェクト

他の多くの Google Cloud リソースと同様に、Environ の実装は Google Cloud プロジェクトにルート化されています。これは Environ ホスト プロジェクトと呼ばれます。1 つの Cloud プロジェクトに関連付けられる Environ は 1 つ(またはゼロ)だけです。この制限により、Cloud プロジェクトを使用して、制御されていないリソースや一緒に使用されないリソースの分離を強化します。

Environ 対応コンポーネント

次の Anthos と GKE のコンポーネントはすべて、名前空間や ID の同一性など、Environ のコンセプトを活用してクラスタとサービスの操作を簡略化します。各コンポーネントで Environ を使用するための現在の要件または制限については、コンポーネントの要件をご覧ください。

  • Workload Identity プール(Anthos クラスタと GKE クラスタ)
    Environ は、サービス メッシュ内および外部サービスに対してワークロードを均一に認証し、承認するために使用できる共通の Workload Identity プールを提供します。

  • Anthos Service Mesh(Anthos)
    Anthos Service Mesh は、Google Cloud、またはオンプレミス上の信頼性の高いサービス メッシュをモニタリングおよび管理するためのツールセットです。同じ Environ に属するリソース(クラスタや VM など)全体でサービス メッシュを形成できます。

  • Anthos Config Management(Anthos)と Config Sync(GKE)
    Anthos Config Management は、名前空間、ラベル、アノテーションなど Kubernetes の中核的なコンセプトを活用しているため、中央の Git リポジトリに格納された、システム用の宣言型ポリシーと構成変更をデプロイしてモニタリングできます。Anthos Config Management(および Anthos 以外のクラスタ用の派生サービスである Config Sync)では、ポリシーと構成が Environ 全体で定義されますが、各メンバー リソースにローカルに適用されます。

  • 複数クラスタ Ingress(Anthos)
    複数クラスタ Ingress は environ を使用して、トラフィックの負荷分散が可能なクラスタとサービス エンドポイントのセットを定義し、低レイテンシで可用性の高いサービスを可能にします。

インフラストラクチャのグループ化

Environ の最初の重要なコンセプトがグループ化です。グループ化とは、関連する Environ-aware リソースのうち、どれを使って Environ を形成するかを選択することです。グループに含めるリソースを判断するには、次の質問に答える必要があります。

  • リソースは相互に関連していますか?
    • サービス間の通信が多いリソースは、Environ 内でまとめて管理することで大きなメリットを得られます。
    • 同じデプロイ環境(本番環境など)のリソースは 1 つの Environ でまとめて管理する必要があります。
  • リソースを管理しているのは誰ですか?
    • Environ の整合性を確保するために重要になるのが、リソースの統合的(または少なくとも相互に信頼できる)な制御です。

わかりやすい例として、複数の事業部門(LOB)がある組織について考えてみます。この場合、LOB の境界を越えてサービス間で通信することはほとんどありません。LOB ごとにサービスの管理方法も異なります(アップグレード サイクルが LOB ごとに異なるなど)。LOB ごとに管理者が異なる場合さえあります。この場合、LOB ごとに Environ があると合理的です。本番環境と非本番環境のサービスを分離するために、各 LOB に複数の Environ を導入することもできます。

Environ の他のコンセプトについては以降のセクションで説明しますが、組織に固有のニーズに合わせて複数の Environ を作成する場合の理由も紹介されています。

同一性

Environ の重要なコンセプトの 1 つが同一性です。同一性とは、異なるコンテキストで同じ名前を持つクラスタなど、一部の Kubernetes オブジェクトが同じものとして扱われることを指します。この正規化は、Environ リソースの管理をやりやすくすることを目的としています。また、名前空間、サービス、ID の設定方法に関する強力なガイダンスにもなります。一方で、Environ をすでに実装している多くの組織のやり方も参考にしています。

名前空間の同一性

Environ における基本的な同一性が名前空間の同一性です。異なるクラスタで同じ名前を持つ名前空間は、多くのコンポーネントで同一と見なされます。このプロパティについては、名前空間のインストールが Environ リソースのサブセットにしか存在しない場合でも、名前空間が Environ 全体で論理的に定義されるという点に注目する必要があります。

次の backend 名前空間の例を考えてみましょう。名前空間はクラスタ A とクラスタ B でのみインスタンス化されますが、名前空間クラスタ C に暗黙的に予約されています(必要に応じて backend サービスをクラスタ C にスケジューリングすることもできます)。つまり、名前空間はクラスタごとではなく、名前空間全体に割り当てられます。したがって、名前空間の同一性では、Environ 全体で一貫した名前空間を所有している必要があります。

Environ 内の名前空間の同一性を示す図
Environ 内の名前空間の同一性

サービスの同一性

Anthos Service Mesh とマルチクラスタ Ingress は、名前空間内のサービスの同一性のコンセプトを使用します。これは、名前空間の同一性と同様、名前空間とサービス名が同じサービスが同一サービスとみなされることを意味します。

Anthos Service Mesh の場合、サービス エンドポイントをメッシュ全体でマージできます。マルチクラスタ Ingress では、MultiClusterService(MCS)リソースによってエンドポイントのより明示的なマージが行われます。命名に関しても同様の方法をおすすめします。このため、同じ名前空間内の名前が同じサービスは実際に同じものにする必要があります。

次の例では、インターネット トラフィックがクラスタ B と C の両方に存在する frontend 名前空間内の同じ名前のサービス全体に負荷分散されています。同様に、Environ 内のサービス メッシュ プロパティを使用して、frontend サービスがクラスタ A と C に存在する auth 名前空間内の同じ名前のサービスにアクセスできます。

Environ 内のサービスの同一性を示す図
Environ 内のサービスの同一性

外部リソースにアクセスする場合の ID の同一性

Environ 内のサービスは、Google Cloud サービス、オブジェクト ストアなどの外部リソースに下り(外向き)のアクセスを行うときに、共通の ID を使用できます。この共通 ID によって、外部リソースへのアクセスを、クラスタ単位ではなくまとめて Environ 内のサービスに付与できます。

この点についてより具体的に理解するため、次の例を考えてみましょう。クラスタ A、B、C は Environ 内で共通の ID に登録されます。backend 名前空間のサービスが Google Cloud リソースにアクセスすると、その ID は back という共通の Google Cloud サービス アカウントにマッピングされます。Google Cloud サービス アカウント back は、Cloud Storage から Cloud SQL まで、任意の数のマネージド サービスで認証できます。クラスタなどの新しい Environ リソースが backend 名前空間に追加されると、自動的にワークロード ID の同一性プロパティが継承されます。

ID の同一性では、Environ 内のすべてのリソースが信用され、厳重に管理されている必要があります。前の例に戻ると、クラスタ C が別の信頼されていないチームによって所有されている場合、このチームでも backend 名前空間を作成し、クラスタ A または B の backend であるかのようにマネージド サービスにアクセスできます。

Environ 外部リソースにアクセスする ID の同一性を表す図
Environ 外部リソースにアクセスする ID の同一性

Environ 内の ID の同一性

Environ 内では、先ほど説明した外部 ID の同一性と同じように ID の同一性が使用されます。Environ サービスは、外部サービスに対して一度認証されると、内部でも認証できます。

以下の例では、Anthos Service Mesh を使用して、frontendbackend にアクセスできるマルチクラスタ サービス メッシュを作成します。Anthos Service Mesh と envrones では、クラスタ B とクラスタ C の frontend がクラスタ A と B の backend にアクセスできるように指定する必要はありません。代わりに、Environ 内の frontend が Environ 内の backend にアクセスできることを指定するだけです。このプロパティは認証を簡素化するだけでなく、リソースの境界も柔軟になります。ワークロードは、認証方法に影響を与えずに、クラスタ間で簡単に移動できるようになります。ワークロード ID の同一性と同様、サービス間通信の整合性を確保するには Environ リソースのガバナンスが不可欠です。

Environ 内の ID の同一性を示す図
Environ 内の ID の同一性

独占性

Environ-aware リソースは、常に 1 つの Environ のメンバーにしかなることができません。これは、Google Cloud のツールとコンポーネントによって適用される制限です。この制限により、クラスタを制御する、信頼できる情報源が 1 つだけになります。独占性がないと、非常に単純なコンポーネントであっても使い方が複雑になり、複数の Environ と複数のコンポーネントの交信方法を組織内で把握し構成しなければならなくなります。

強い信頼関係

サービス、ワークロード ID、メッシュ ID の同一性は、Environ メンバー間の強い信頼関係の原理のもとに構築されます。この信頼により、リソースごとに管理せずに(Kubernetes リソースの場合はクラスタごと)、Environ のリソースの管理を強化でき、最終的にはクラスタの境界が重要ではなくなります。

つまり、Environ 内では、クラスタが影響範囲の懸念や可用性(制御プレーンと基盤となるインフラストラクチャ両方)、ノイズの多いネイバーなどから保護します。ただし、Environ 内のメンバーの管理者が Environ の他のメンバーのサービスの運用に影響を及ぼす可能性があるため、これらはポリシーおよびガバナンスの強力な隔離境界ではありません。

そのため、Environ 管理者が信頼していないリソースは、隔離しておくために専用の Environ に配置することをおすすめします。そうしておけば、必要に応じて個々のサービスを Environ の境界を越えて認証できます。

次のステップ

これらのコンセプトをお使いのシステムに適用する場合は、Environ の要件とベスト プラクティスをご覧ください。