GKE Enterprise（Anthos）の技術概要

GKE Enterprise は、Google のクラウド中心のコンテナ プラットフォームで、どこでも大規模に最新のアプリを一貫して実行できます。このガイドでは、GKE Enterprise の仕組みと、管理性とスケーラビリティに優れた信頼性の高いアプリケーションを提供する方法の概要について説明します。

GKE Enterprise を選ぶ理由

通常、組織がコンテナやコンテナ オーケストレーション、サービス メッシュなどのクラウドネイティブ テクノロジーを利用していると、単一クラスタを実行しているだけでは不十分になってきます。技術やビジネスの目標を達成するために、組織はさまざまな理由から複数のクラスタをデプロイします。たとえば、本番環境と非本番環境の分離や、層、ロケール、チーム間でサービスの分離を行います。ただし、複数のクラスタを使用すると、構成、セキュリティ、管理の一貫性が損なわれるため、独自の課題とオーバーヘッドが生じます。たとえば、一度に 1 つのクラスタを手動で構成すると破損のリスクがあり、エラーの発生場所を正確に確認するのが難しくなります。

クラスタがすべて 1 か所にまとめられていない場合は、状況はより複雑（かつ高額）になる場合があります。Google Cloud を使用する多くの組織は、独自のデータセンター、工場、小売店、さらにはその他のパブリック クラウドでもワークロードを実行したい、または実行する必要がありますが、これらすべての場所で新しいコンテナ プラットフォームを構築したり、一貫性のない環境、セキュリティと構成ミスのリスク、運用作業などを伴う、コンテナ ワークロードの実行場所に応じた構成、保護、モニタリング、最適化を行う方法を再検討したりすることを望んでいません。

次に例を示します。

  • 金融機関は Google Cloud 上にデジタル バンキング プラットフォームを構築しており、整合性のある構成、強力なセキュリティ ポリシーの適用、複数のアプリの通信方法の詳細な可視化が必要です。最新の e コマース プラットフォームを構築する大手小売企業でも、同じ要件があります。両社は GKE を使用して、Google Cloud の複数リージョンにある複数のクラスタを管理しています。
  • 別の国際的な金融機関は、複雑なリスク管理アプリ、銀行間転送アプリ、その他多くの機密性の高いワークロードを構築しています。その一部は企業のファイアウォールの背後にあり、一部は Google Cloud の GKE にデプロイされています。
  • 大手薬品小売業者は、新しいワクチン接種のスケジュール、顧客メッセージ、デジタル エンゲージメント アプリを作成して、店舗の運営をモダナイズし、高度にカスタマイズされた店舗内エクスペリエンスを実現しています。これらのアプリには、BigQuery や Retail Search などの Google Cloud でホストされているサービスと統合される店舗内のコンテナ プラットフォームが必要です。
  • メディアとエンターテイメント企業は、30 の野球場に一貫したコンテナ環境を必要とします。すべてが Google Cloud から接続、管理され、テラバイト単位のゲーム統計を収集して分析し、球場内および仮想的にファンのエンゲージメントを促進する必要があります。
  • ハードウェア製造会社は、非常に低いレイテンシでデータを分析してほぼリアルタイムで意思決定を行い、同時に Google Cloud にデータを長期的に統合して、工場現場の製品品質と作業者の安全性をテストおよび最適化する必要があります。
  • Software as a Service（SaaS）モデルの統合プラットフォームを提供するソフトウェアおよびインターネット企業は、お客様がネイティブ クラウド サービスに近い場所で実行できるように、複数の主要なパブリック クラウドでプラットフォームを提供する必要があります。この企業は、異なるネイティブ管理ツールを使用して各クラウド環境を管理する運用上のオーバーヘッドを回避するため、1 つの管理プレーンから複数のパブリック クラウドに含まれるコンテナ環境をプロビジョニング、構成、保護、モニタリングするための、一貫性のある統一された方法を必要としています。

GKE Enterprise は、組織が一貫したプラットフォームを提供することで、以下を行えるようにこのような組織のすべてを支援します。

  • アプリケーションとインフラストラクチャをモダナイズする
  • あらゆる場所でコンテナ クラスタを作成、更新、最適化するための、統一されたクラウド運用モデル（一括表示）を作成する
  • 一貫したセキュリティ、構成、サービス管理で、大規模なマルチクラスタ アプリケーションをフリート（同様の環境の論理グループ）としてスケーリングする
  • 統合されたコントロール プレーンから一貫したガバナンスとセキュリティを適用する

コンテナ化されたワークロードを企業規模で管理、管理、運用するのに役立つ独自のツールと機能を使用して、Google でサービスを実行した経験から得られたベスト プラクティスと原則を組織が採用できるようにします。

GKE Enterprise の基本

GKE Enterprise プラットフォームの機能を示す図

GKE Enterprise の機能は、フリート（一緒に管理できる Kubernetes クラスタの論理グループ）という考え方に基づいて構築されています。フリートは、Google Cloud 上の GKE クラスタのみで構成することも、オンプレミスや AWS や Azure などの他のパブリック クラウドで実行されている Google Cloud 外部のクラスタを含めることもできます。

フリートを作成したら、GKE Enterprise のフリート対応機能を使用して、さらに価値を追加し、複数のクラスタやインフラストラクチャ プロバイダでの作業を簡素化できます。

  • 構成ツールとポリシー管理ツールを使用すると、クラスタの場所にかかわらず、フリート全体で同じ構成、機能、セキュリティ ポリシーを一貫して自動的に追加、更新し、大規模環境での作業を容易にするのに役立ちます。
  • フリート全体のネットワーク機能は、複数のクラスタにまたがるアプリケーションのマルチクラスタ Ingress や、サービス メッシュのトラフィック管理機能など、フリート全体のトラフィックを管理するのに役立ちます。
  • ID 管理機能は、フリートのワークロードとユーザーの認証の一貫した構成に役立ちます。
  • オブザーバビリティ機能を使用すると、フリートのクラスタとアプリケーションのモニタリングとトラブルシューティングを行うことができます（健全性、リソース使用率、セキュリティ体制など）。
  • チーム管理ツールを使用すると、ワークロードの実行に必要なインフラストラクチャ リソースにチームがアクセスし、チームにリソースとワークロードのチーム スコープ ビューを提供します。
  • フリートで実行されているマイクロサービス ベースのアプリケーションの場合、Anthos Service Mesh はアプリケーションのセキュリティ、ネットワーキング、メッシュ全体のオブザーバビリティのための強力なツールを提供します。

マルチクラウド機能とハイブリッド クラウド機能を含む使用可能なすべての機能を GKE Enterprise プラットフォーム全体で使用できるようにすることも、Google Cloud でのみフリートを作成し、必要に応じて追加のエンタープライズ機能に対して支払うこともできます。GKE Enterprise は業界標準のオープンソース テクノロジーを使用して、複数のインフラストラクチャ プロバイダをサポートし、ビジネスや組織のニーズに合わせて GKE Enterprise を柔軟に使用できます。

フリートの仕組み

フリートは、GKE Enterprise によって Kubernetes クラスタを論理的にグループ化して正規化し、インフラストラクチャの管理を容易にするものです。フリートを導入することで、組織は、Google Cloud コンソールでフリート全体を 1 つのビューで個々のクラスタからクラスタのグループに管理をレベルアップできます。ただし、フリートは単なるクラスタのグループではありません。フリート内で想定される同一性と信頼の原則により、フリート対応のすべての機能を使用できます。

最初のフリートの原則は同一性です。これは、クラスタのフリート内で、異なるクラスタ内にある Namespace など一部の Kubernetes オブジェクトは、同じ名前を持つ場合に同じものであるかのように扱われることを意味します。この正規化は、多数のクラスタを一度に管理することを簡単にするものであり、GKE Enterprise のフリート対応の機能で使用されます。たとえば、Policy Controller を使用して、名前空間 foo のすべてのフリート サービスに、サービスがどのクラスタにあるかや、クラスタがどこにあるかに関係なくセキュリティ ポリシーを適用できます。

また、フリートでは、サービスの同一性（トラフィック管理の目的などで、名前が同じ名前空間にあるすべてのサービスが同じサービスとして扱われること）と、ID の同一性（フリート内のサービスとワークロードが認証と承認に共通の ID を利用できる）を想定しています。フリートの同一性の原則は、多くの組織と Google がベスト プラクティスとしてすでに実装していることに従って、名前空間、サービス、ID を設定する方法に関する強力なガイダンスも提供します。

もう 1 つの重要な原則は信頼です。サービスの同一性、Workload Identity の同一性、メッシュ ID の同一性はすべて、フリート メンバー間の強い信頼関係の原則のもとに構築されます。この信頼により、クラスタごとに管理するのではなく、フリートのリソースの管理をレベルアップでき、最終的にはクラスタの境界が重要ではなくなります。

フリートを整理する方法は、組織と技術のニーズによって異なります。各フリートは、フリート ホスト プロジェクトと呼ばれる特定の Google Cloud プロジェクトに関連付けられています。これは、フリートの管理と表示に使用されますが、他のプロジェクトのクラスタを含めることができます。たとえば、本番、テスト、開発の各環境用に別々のフリートを用意したり、業務の部門ごとに異なるフリートを使用したりできます（インフラストラクチャ上のテナントとしての別々のチームは、スコープを使用してフリート内で処理できます）。サービス間の通信が多いクラスタは、フリート内でまとめて管理することで大きなメリットを得られます。同じ環境（本番環境など）内のクラスタは、同じフリートに存在する必要があります。一般に、サービス間の信頼と同一性を可能にする最大のフリート サイズをおすすめします。ただし、Anthos Service Mesh を使用する場合は、フリート内でよりきめ細かいサービス アクセス制御が可能になることに注意してください。

詳しくはこちらをご覧ください。

場所を問わない Kubernetes クラスタ

Kubernetes は GKE Enterprise の中核であり、フリートをビルドするときにさまざまな Kubernetes クラスタ オプションから選択できます。

  • Google Kubernetes Engine（GKE）は Google が管理する Kubernetes の実装で、GKE Enterprise ユーザーは次のオプションを使用できます。
    • Google Cloud 上 では、GKE にクラウドホスト型のコントロール プレーンと Compute Engine インスタンスで構成されるクラスタがあります。Google Cloud 上の GKE それ自体は、Kubernetes のデプロイ、スケーリング、管理を自動的に行うのに役立ちますが、フリート内の GKE クラスタをグループ化すると、大規模かつ簡単に作業を行えるようになり、GKE ですでに提供されている強力なクラスタ管理機能に加えて GKE Enterprise の機能を使用できます。
    • Google Cloud の外部では、GKE は他のインフラストラクチャ プロバイダとの使用（Azure や AWS など）、および独自のオンプレミス ハードウェア（VMware 上またはベアメタル上）上での使用向けに拡張されています。これらのオプションでは、Google が提供する Kubernetes コントロール プレーンは、クラスタノードとともにデータセンターまたはクラウド プロバイダで実行され、クラスタは Google Cloud のフリートホスト プロジェクトに接続されます。
  • Google Distributed Cloud Edge により、オンプレミスの GKE クラスタをフリートに追加することもできます。今回は、Google が提供および管理するハードウェア上で実行し、GKE Enterprise 機能のサブセットをサポートします。
  • GKE クラスタは唯一の選択肢ではありません。GKE Enterprise では、EKS クラスタや AKS クラスタなど、準拠するサードパーティの Kubernetes クラスタ（接続クラスタ）をフリートに登録することもできます。このオプションでは、既存のワークロードを引き続き実行しながら、GKE Enterprise の機能のサブセットを使用して価値を付加します。GKE Enterprise は、Kubernetes コントロール プレーンまたはノード コンポーネントを管理しません。これらのクラスタで実行される GKE Enterprise サービスのみが管理されます。

オンプレミス クラウドとパブリック クラウドを含む GKE ベースのクラスタすべてに対して、GKE Enterprise は、コマンドライン ユーティリティと、一部のクラスタタイプでは Google Cloud コンソールからの管理など、クラスタ ユーティリティとライフサイクル用のツール（作成、更新、削除、アップグレード）を提供します。

クラスタ構成

Config Sync は、クラスタの場所にかかわらず、接続クラスタを含むフリート全体でクラスタ構成を一貫した方法で管理できるようにします。Config Sync では「データとして構成」のアプローチを使用します。環境の目的の状態は宣言的に定義され、バージョン管理下で信頼の唯一の情報源として維持され、繰り返し可能な結果で直接適用されます。Config Sync は構成を含む中央の Git リポジトリをモニタリングし、実行されている場所にかかわらず、指定された対象クラスタに自動的に変更を適用します。kubectl コマンドで適用できる YAML または JSON は、すべて Config Sync で管理でき、どのような Kubernetes クラスタにも適用できます。

移行と VM

モダナイゼーション プロセスの一環としてアプリケーションをコンテナと Kubernetes に移行する組織の場合、GKE Enterprise には Migrate to Containers が含まれており、ツールを使用して VM ベースのワークロードを GKE で実行されるコンテナに変換できます。ベアメタル GKE Enterprise プラットフォーム（GKE on Bare Metal と Distributed Cloud Edge）上で、組織は Google Distributed Cloud で VM ランタイムを使用して、コンテナを実行するのと同じ方法で Kubernetes 上で VM を実行でき、新しいコンテナベースのアプリケーションの開発と実行も行いつつ、既存の VM を引き続き使用できます。準備ができたら、これらの VM ベースのワークロードをコンテナに移行し、同じ GKE Enterprise 管理ツールを引き続き使用できます。

詳しくはこちらをご覧ください。

GKE Enterprise の機能

このガイドの残りの部分では、フリートとフリートで実行されるアプリケーションの管理に役立つ GKE Enterprise の機能について説明します。サポートされている Kubernetes クラスタのタイプごとに利用可能な機能の一覧については、GKE Enterprise のデプロイ オプションをご覧ください。

ネットワーキング、認証、セキュリティ

フリートを構築した後は、GKE Enterprise によって、トラフィックの管理、認証とアクセス制御の管理、フリート全体のセキュリティ ポリシーとコンプライアンス ポリシーの一貫した適用が可能になります。

フリートへの接続

Google では、ハイブリッド クラウドとマルチクラウド フリートへの接続を管理するために、Connect Agent という Kubernetes Deployment を提供しています。フリート登録の一部としてクラスタにインストールすると、エージェントは Google Cloud 外のクラスタと Google Cloud フリート ホスト プロジェクトの間の接続を確立します。これにより、Google からクラスタとワークロードを管理し、Google サービスを使用できます。

オンプレミス環境では、Google Cloud を操作するときに、アプリケーションのレイテンシ、セキュリティ、帯域幅の要件に応じて、公共のインターネット、高可用性 VPN、Public Interconnect、または Dedicated Interconnect を使用して Google に接続できます。

詳しくはこちらをご覧ください。

ロード バランシング

フリート内とトラフィック内でトラフィックを管理するために、GKE Enterprise は次のロード バランシング ソリューションを提供します。

  • Google Cloud 上の GKE クラスタでは、次のオプションを使用できます。
  • オンプレミス GKE クラスタでは、バンドル型 MetalLB ロードバランサや、既存のソリューションを使用するようにロード バランシングを手動で構成するオプションなど、ニーズに合わせてさまざまなロード バランシング モードから選択できる
  • Distributed Cloud Edge には MetalLB ロード バランシングがバンドルされている
  • 他のパブリック クラウド上の GKE クラスタはプラットフォーム ネイティブのロードバランサを使用する

詳しくはこちらをご覧ください。

認証とアクセス制御

複数のインフラストラクチャ プロバイダにまたがる複数のクラスタと連携する場合、認証と承認の管理が課題となります。フリートのクラスタに対する認証に対して、GKE Enterprise には、kubectl を使用してコマンドラインから操作する場合や、Google Cloud コンソールからクラスタ操作する場合に、一貫性があり、シンプルで安全な認証のオプションが用意されています。

  • Google ID を使用する: Connect Gateway を使用すると、クラスタが存在する場所にかかわらず、ユーザーとサービス アカウントが Google ID を使用してフリート全体のクラスタに対して認証を行うことができます。この機能を使用して、クラスタに直接接続することも、ビルド パイプラインやその他の DevOps 自動化で使用することもできます。
  • サードパーティの ID を使用する: GKE Enterprise の GKE Identity Service を使用すると、サードパーティの ID プロバイダを使用して認証を構成できます。これにより、チームは、Microsoft AD FS や Okta などのOIDC（およびサポートされている場合は LDAP）プロバイダから取得した既存のユーザー名、パスワード、セキュリティ グループをフリート全体で引き続き使用できます。

クラスタには、サポートされている ID プロバイダを必要な数だけ構成できます。

認証を設定したら、Kubernetes の標準ロールベースのアクセス制御（RBAC）を使用して、認証済みユーザーがクラスタを操作することを承認できます。また、Identity and Access Management を使用して Connect Gateway などの Google サービスへのアクセスを制御することもできます。

クラスタで実行されているワークロードの場合、GKE Enterprise はフリート全体の Workload Identity を提供します。この機能を使用すると、フリート メンバー クラスタのワークロードは、Cloud APIs などの外部サービスに認証する際に、フリート全体の Workload Identity プールの ID を使用できます。これにより、クラスタごとにアクセス クラスタを構成する場合に比べて、サービスに対するアプリケーションのアクセス権の設定がよりシンプルになります。そのため、たとえば、同じフリート内の複数のクラスタにバックエンドがデプロイされたアプリケーションで Google API への認証が必要な場合、その「バックエンド」の Namespace 内のサービスすべてがその API にアクセスできるようにアプリケーションを構成できます。

詳しくはこちらをご覧ください。

ポリシーの管理

複数のクラスタに関する作業では、フリート全体に一貫したセキュリティと規制のコンプライアンス ポリシーを適用することも課題となります。多くの組織には、金融サービス アプリケーションの消費者情報の保護に関する要件など、セキュリティとコンプライアンスに関する厳しい要件があり、これらの要件を大規模な形で満たせるようにする必要があります。

これを実現するため、Policy Controller はすべての Kubernetes API リクエストに対するカスタム ビジネス ロジックを関連するクラスタに適用します。こうしたポリシーは「ガードレール」として機能し、Kubernetes API の構成に対する変更がセキュリティ、運用、コンプライアンスの管理に違反することを防止します。フリート全体で非準拠の API リクエストを積極的にブロックするように、または単にクラスタ構成を監査して違反を報告するように、ポリシーを設定できます。一般的なセキュリティ ルールとコンプライアンス ルールは、Policy Controller の組み込みルール セットを使用して簡単に表現できます。また、オープンソースの Open Policy Agent プロジェクトに基づいて、拡張可能なポリシー言語を使用して独自のルールを作成することもできます。

詳しくはこちらをご覧ください。

アプリケーション レベルのセキュリティ

フリートで実行されているアプリケーションの場合、GKE Enterprise には、以下の多層防御のアクセス制御と認証機能が用意されています。

  • Binary Authorization。信頼できるイメージのみがフリートのクラスタにデプロイされるようにできます。
  • Kubernetes ネットワーク ポリシー。相互通信および他のネットワーク エンドポイントとの通信を許可する Pod を指定できます。
  • Anthos Service Mesh のサービスのアクセス制御。サービス アカウントとリクエストのコンテキストに基づいて、メッシュ サービスの詳細なアクセス制御を構成できます。
  • Anthos Service Mesh 認証局（Mesh CA）。証明書を自動的に生成してローテーションするため、サービス間で相互 TLS 認証（mTLS）を簡単に有効にできます。

オブザーバビリティ

クラスタの運用と管理を大規模に行う際の重要な部分は、フリートのクラスタとアプリケーション（健全性、リソース使用率、セキュリティ体制など）を簡単にモニタリングできることです。

Google Cloud コンソールの GKE Enterprise

Google Cloud コンソールは、プロジェクトとリソースの管理に使用できる Google Cloud のウェブ インターフェースです。GKE Enterprise では、フリート全体のエンタープライズ機能と構造化されたビューが GKE Google Cloud コンソール ページに組み込まれ、アプリケーションやリソースをすべて 1 か所で管理できる統合インターフェースが提供されます。ダッシュボード ページでは、概要を確認できるほか、問題をドリルダウンして問題を特定することができます。

  • 概要: トップレベルの概要には、Cloud Monitoring で提供される情報に基づいてフリートのリソース使用量の概要が表示されます。ここには、フリートとクラスタ別に集計された CPU、メモリ、ディスク使用率、およびフリート全体の Policy Controller と Config Sync のカバレッジが表示されます。
  • クラスタ管理: GKE Enterprise の クラスタ ビューには、クラスタの状態を含むすべてのプロジェクトとフリートのクラスタの状態を表示し、クラスタをフリートに登録し、フリートの新しいクラスタを作成する（Google Cloud のみ）ための安全なコンソールが提供されます。特定のクラスタの詳細については、このビューからドリルダウンするか、他の GKE ダッシュボードにアクセスして、クラスタノードとワークロードの詳細を取得できます。
  • チームの概要: フリートにチームを設定している場合、チームの概要には、チームごとに集計されたリソース使用率、エラー率、その他の指標が表示されます。これにより、管理者やチームメンバーがエラーを簡単に表示、トラブルシューティングできるようになります。
  • 機能管理: 機能管理ビューでは、フリート クラスタの GKE Enterprise 機能の状態を確認できます。
  • サービス メッシュ: Google Cloud で Anthos Service Mesh を使用している場合、サービス メッシュ ビューはサービスの健全性とパフォーマンスのオブザーバビリティを提供します。Anthos Service Mesh は、各サービスのリクエストとレスポンスに関するデータを収集して集計します。つまり、テレメトリー データを収集するためのコードをインストルメント化する、ダッシュボードやチャートを手動で設定する必要はありません。Anthos Service Mesh は、クラスタ内のすべてのトラフィックに対して、指標とログを Cloud Monitoring と Cloud Logging に自動的にアップロードします。この詳細なテレメトリーにより、運用担当者はサービスの挙動を監視でき、アプリケーションのトラブルシューティング、メンテナンス、最適化を行うのに役立ちます。
  • セキュリティ対策: セキュリティ対策ビューには、フリートのセキュリティ体制を改善するための独自の実行可能な推奨事項が表示されます。
  • 構成管理: 構成ビューでは、Config Sync が有効になっているすべてのフリート クラスタの構成状態を一目で確認できます。また、まだ設定されていないクラスタに機能をすばやく追加できます。構成の変更を簡単に追跡し、各クラスタに適用されたブランチと commit タグを確認できます。柔軟なフィルタを使用すると、クラスタ、ブランチ、タグごとに構成のロールアウト ステータスを簡単に表示できます。
  • ポリシー管理: ポリシー ビューは Policy Controller が有効になっているフリートの数を表示し、コンプライアンス違反の概要を示し、フリート クラスタに機能を追加できます。

ロギングとモニタリング

クラスタとそのワークロードの詳細については、Cloud Logging と Cloud Monitoring を使用できます。Cloud Logging は、ログデータの保存と分析のための統合された場所を提供します。Cloud Monitoring はパフォーマンス データを自動的に収集して保存し、データの可視化と分析ツールを提供します。GKE Enterprise クラスタ タイプの大部分は、システム コンポーネント（kube-system 名前空間と gke-connect 名前空間のワークロードなど）のロギングとモニタリング情報を Cloud Monitoring と Cloud Logging に送信します。Cloud Monitoring と Cloud Logging をさらに構成して、独自のアプリケーション ワークロードに関する情報の取得、複数の種類の指標を含むダッシュボードの構築、アラートの作成などを行えます。

組織やプロジェクトのニーズに応じて、GKE ではオープンソースの Prometheus や Grafana などの他のオブザーバビリティ ツール、Elastic や Splunk などのサードパーティ ツールとの統合もサポートしています。

詳しくはこちらをご覧ください。

サービス管理

Kubernetes では、Service は、トラフィックに単一の DNS アドレスを使用して、ネットワーク サービスとして一連の Pod で実行されているアプリケーションをワークロードに公開するための抽象的な方法です。最新のマイクロサービス アーキテクチャでは、単一のアプリケーションが多数のサービスで構成され、各サービスに複数のバージョンが同時にデプロイされることがあります。この種のアーキテクチャでのサービス間通信はネットワーク経由で行われるため、サービスでネットワークの特異性やその他の基盤となるインフラストラクチャの問題に対処できるようにする必要があります。

フリート内のサービスを管理しやすくするために、Anthos Service Mesh を使用できます。Anthos Service Mesh は、サービス メッシュ インフラストラクチャ レイヤのオープンソース実装である Istio をベースにしています。サービス メッシュでは、モニタリング、ネットワーキング、セキュリティなどのサービスの実行についての共通の懸念を整合性のある強力なツールで分析するため、サービス デベロッパーやオペレーターはアプリケーションの作成と管理に集中できます。Anthos Service Mesh では、これらの機能がアプリケーションのプライマリ コンテナと分離されて抽象化され、同じ Pod 内に別のコンテナとして提供される、共通のプロセス外プロキシに実装されます。このパターンにより、アプリケーション ロジックまたはビジネス ロジックがネットワーク機能から切り離されるため、デベロッパーはビジネスに必要な機能に集中できます。また、サービス メッシュを使用すると、運用チームと開発チームはお互いの作業を分離できます。

Anthos Service Mesh は、Istio のすべての機能ともに多くの機能を提供します。

  • メッシュのクラスタ内のすべてのトラフィックに関して、サービスの指標とログが自動的に Google Cloud に取り込まれます。
  • 自動的に生成されたダッシュボードには、Anthos Service Mesh ダッシュボードに詳細なテレメトリーが表示されます。指標とログを深く掘り下げることができ、さまざまな属性に基づいてデータをフィルタ、スライスできます。
  • サービス同士の関係をひと目で把握: サービスの接続関係、依存関係を理解します。
  • サービス間トラフィックの保護: Anthos Service Mesh 認証局（Mesh CA）は証明書を自動的に生成してローテーションするため、Istio ポリシーを使用して相互 TLS 認証（mTLS）を簡単に有効にできます。
  • 自分のサービスだけでなく、他のサービスとの関係のコミュニケーション セキュリティの分析情報もすばやく確認できます。
  • Cloud Monitoring を使用して、サービス指標を詳しく分析し、他の Google Cloud 指標と組み合わせます。
  • サービスレベル目標（SLO）でサービスの状態を明確かつシンプルに把握し、サービスの状態についての基準の定義とそれに基づいたアラートを簡単に行えるようにします。

Anthos Service Mesh では、Google Cloud のフルマネージド サービス メッシュ コントロール プレーン（Google Cloud 上のフリート メンバー クラスタで実行されているメッシュのみ）、またはユーザーがインストールするクラスタ内コントロール プレーンを選択できます。各オプションで使用できる機能の詳細については、Anthos Service Mesh のドキュメントをご覧ください。

詳しくはこちらをご覧ください。

次のステップ