GKE Enterprise（Anthos）の技術概要

GKE Enterprise は、最新のアプリを一貫して大規模に実行するための、Google のクラウドを中心としたコンテナ プラットフォームこのガイドでは、GKE Enterprise の仕組みと、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 クラスタのみで構成することも、Google Cloud 外部のクラスタ（オンプレミス、AWS や Azure などのパブリック クラウド）を含めることもできます。

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

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

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

フリートの仕組み

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

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

また、フリートでは、サービスの同一性（トラフィック管理の目的などで、名前が同じ Namespace にあるすべてのサービスが同じサービスとして扱われること）と、ID の同一性（フリート内のサービスとワークロードが認証と承認に共通の ID を利用できる）を想定しています。フリートの同一性の原則は、多くの組織と Google がベスト プラクティスとしてすでに実装していることに従って、Namespace、サービス、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 への接続を管理するために、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 がフリート全体の 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 コンソールのページにエンタープライズ機能とフリート全体の構造化ビューが表示され、アプリケーションとリソースを一元管理できる統合インターフェースが提供されます。ダッシュボード ページでは、概要を確認できるほか、ドリルダウンして問題を特定することもできます。

  • 概要: トップレベルの概要には、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 Namespace と gke-connect Namespace のワークロードなど）のロギングとモニタリング情報を Cloud Monitoring と Cloud Logging に送信します。Cloud Monitoring と Cloud Logging をさらに構成すると、独自のアプリケーション ワークロードに関する情報を取得したり、複数のタイプの指標を含むダッシュボードを作成したり、アラートを作成したりできます。

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

詳細:

サービス管理

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

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

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

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

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

詳細:

次のステップ