Anthos Service Mesh によるマルチクラスタ Ingress の一元化

※この投稿は米国時間 2022 年 12 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

ツールをきっかけとしてオープンソース プロダクトが普及するという Kubernetes で見られたような現象は、これまでには見られなかったものです。Kubernetes が安全かつ確実にサービスを実行する事実上のコンテナ オーケストレーターとなっているのは、こうした構成要素があるためです。Kubernetes は単独で実行されるわけではなく、多くの場合、Kubernetes がネイティブには解決できないビジネス上の現実課題を解決できるよう、その他のツールとともにデプロイされます。Google は、そうしたプロダクトのマネージド コレクションを Anthos 傘下で提供しています。

本記事では、Anthos を活用し、マルチクラスタ Ingress（MCI）と Anthos Service Mesh（ASM）でインターネット トラフィックの管理を一元化する方法について説明します。

問題提起

大規模な組織にとって、責務の分離は大きな懸念事項です。クラウド基盤の設計も、この懸念によって決まることになります。プロジェクトは、Google Cloud Platform が提供するリソースの大半に対して最小権限戦略を策定する際の境界線となるものです。よって、チームが違えばワークロードを実行するプロジェクトも分かれていると言っていいでしょう。

こうした責務の分離は、ネットワーキングの管理にも当てはまります。共有 VPC は、チームがネットワーキングを一元的に管理するためのツールの一つです。これを使うと、複数のプロジェクトで同じ VPC を共有できます。VPC が同じであることは、Anthos の提供する一部の機能の要件にもなっています。

Kubernetes で実行されるアプリケーションは、時としてインターネットに公開する必要があります。アプリケーションの公開には、ロードバランサを使用できます。ロードバランサのライフサイクルと構成の管理は、アノテーションとカスタム リソース定義（CRD）によって行われます。MCI は、Kubernetes 上で実行されているサービスをインターネットに公開するうえで Google Cloud グローバル ロードバランサ（GLBC）のライフサイクルを管理するマネージド コントローラです。残念ながら、GLBC はクロス プロジェクトのバックエンドには対応していません。最小権限戦略を導入するうえでの基盤はプロジェクトです。よって、1 つの解決策として、プロジェクトごとに GLBC をデプロイするという方法が考えられます。ただ、この方法の場合、ネットワーク チームやセキュリティ チームに相当の管理上のオーバーヘッドがかかります。もう 1 つの解決策は、MCI を使って 1 つの GLBC をデプロイし、ASM を使いクロス プロジェクトでトラフィックをルーティングするというものです。この方法ならば、セキュリティ チームも、混乱や偶発的な構成エラーの発生を最小限に抑えつつ、責任をシームレスに分離して、必要な責務の分離を実現できます。

ここまでで、解決しようとしている問題の内容と使用するツールについて説明してきました。続いて、解決方法について詳しく見ていきましょう。

アーキテクチャの図

このアーキテクチャは、マルチ プロジェクト設定で MCI をサポートする場合の推奨ソリューションです。フリート プロジェクトとサービス プロジェクトが同じ VPC を共有しています。共有 VPC ホスト プロジェクトはこの図には描かれていませんが、別個のプロジェクトとなっています。フリート プロジェクトとは、Fleet API が有効になっているプロジェクトのことです。同じフリートに属するすべてのクラスタは、属するメッシュも同じになります。MCI の構成をホストしているのはフリート GKE クラスタの片方ですが、構成を両方のフリート GKE クラスタにデプロイすることで高可用性を実現しています。両方のクラスタに同じ構成をデプロイすることで、構成クラスタの入れ替えを簡単に行えるようにしています。

一方、サービス プロジェクトはワークロードをホストしています。開発チームは、管理するサービスをデプロイする際、Namespace にアクセスすることになります。

このソリューションの導入方法

このソリューションを導入するうえで重要なのは、トラフィックの流れについて詳細に把握することです。以下の手順では、すべてが正常に動作していることを確認するためのプロセスを説明します。作業を始める前に、以下を実施します。

• MCI がセットアップされていることを確認します。

• マネージド ASM が有効であることを確認します。

• Ingress ゲートウェイなどのリソース用の Namespace を作成します。

• Ingress の Namespace で、Ingress Deployment と Ingress ゲートウェイを作成します。なお、これをデプロイするのは、フリート GKE クラスタだけです。

• マルチクラスタ サービス リソースをデプロイし、デプロイした Ingress コントローラにセレクタを使用してトラフィックを送信します。クラスタの spec のリンクは、ASM の Ingress リソースがデプロイされているフリート GKE クラスタのみとします。マルチクラスタ サービス リソースでネットワーク エンドポイント グループ（NEG）を作成します。

• GLBC を作成するには、マルチクラスタ Ingress リソースをデプロイする必要があります。
  

• サービスの Namespace を作成します。次の構成を、すべてのクラスタに適用する必要があります。その際、Anthos Config Management（ACM）を利用できます。

• MCI 用にデプロイされたゲートウェイをリッスンする仮想サービスを作成します。ゲートウェイの属性は、Namespace と使用するゲートウェイの名前を組み合わせたものです。この仮想サービスは、フリート GKE クラスタに作成する必要があります。
  

• 2 つめの仮想サービスは、ワークロードが実行されているクラスタに作成する必要があります。最初の仮想サービスとの違いは、こちらの場合に使用するゲートウェイは、Ingress ゲートウェイが別のプロジェクトにデプロイされているため、メッシュである必要があるという点です。

• サービス GKE クラスタにワークロードをデプロイします。
  

• フリート GKE クラスタとサービス クラスタの両方に、Deployment 用のサービスをデプロイします。これは、サービス ディスカバリのために必要となるものです。
  

• 最後に、サービスが応答するかどうかをテストします。これには curl を利用できます。たとえば次のとおりです。
  

まとめ

本ブログ投稿では、MCI は異なるプロジェクトのバックエンドには対応していないものの、ASM を使えばこの制約を克服できるということを説明しました。これら 2 つのプロダクトを組み合わせれば、トラフィック管理を一元化したり、異なるプロジェクトで実行されているワークロードに同じ GLBC を使いまわしたりといったことを簡単に実行できます。GKE Ingress のその他の例については、GKE ネットワーク レシピのリポジトリをご覧ください。