Amazon VPC Lattice と AWS Gateway API コントローラーのご紹介：Kubernetes Gateway API の実装

イントロダクション

本日、AWS は Amazon Virtual Private Cloud (Amazon VPC) の新機能である Amazon VPC Lattice の一般提供を発表しました。サービス間通信の接続、保護、監視をおこなう一貫した方法が提供されます。Amazon VPC Lattice の提供の一環として、Kubernetes Gateway API の実装である AWS Gateway API コントローラーを紹介します。Gateway API は、表現力、拡張性があり、ロール志向なインタフェースを通じて、Kubernetes アプリケーションネットワーキングを可能にする、オープンソースの標準インタフェースです。AWS Gateway API コントローラーは、Gateway API で定義されたカスタムリソースを拡張し、Kubernetes API を利用して VPC Lattice のリソースを作成できるようにします。

モノリスアプリケーションをマイクロサービスとして構築するお客様が増えてきており、インフラストラクチャのモダナイズと Kubernetes の運用がおこなわれています。このような分離された設計は、俊敏性をもたらし、より頻繁なデプロイを可能にしますが、アプリケーショントラフィックのディスカバリ・セキュリティ・モニタリング・ルーティングといった新しい懸念が生じます。お客様はロードバランサ・サービスディスカバリ・サービスメッシュ・モニタリングエージェントなど複数のツールを組み合わせて、Ingress 全体でこれらの要件を満たしています。Ingress は通常、外部との通信 (North-South とも呼ばれる) とサービス間通信 (East-West とも呼ばれる) として引き合いに出され、通常はアプリケーションネットワーキングのユースケースに分類されます。多くの場合、これらのユースケースではサイドカーパターンを用いてアプリケーションコンテナと一緒にネットワーキングプロキシをデプロイすることによって、Kubernetes 内で実装されています。

Amazon VPC Lattice は、AWS のネットワークインフラストラクチャに直接組み込まれたフルマネージドサービスです。Amazon VPC Lattice では、以下のことが実現できます。

VPC やアカウントをまたいだサービス間のネットワーク接続をシームレスに扱う
複数の Kubernetes クラスターにまたがるサービスを発見する
サービス間通信を保護するために、多層防御戦略を実装する
サービス間のリクエスト及びレスポンスのトラフィックを監視する

説明した機能を実装するために、独自でコードを開発する必要はありませんし、Kubernetes のサイドカープロキシを管理する必要もありません。

この記事では、Gateway API コントローラーをインストールする方法と、コントローラーによって実装される Gateway クラスを使用して Amazon VPC Lattice のサービスネットワークのサンプルを構成する方法を説明します。さらに、Gateway API のリソースと、Amazon VPC Lattice オブジェクトのマッピングを説明します。最後に、Amazon Elastic Kubernetes Service (Amazon EKS) クラスター内部のサービス間で、シンプルなトラフィックルーティングのユースケースを実装します。

Kubernetes Gateway API を Amazon VPC Lattice オブジェクトにマッピングする

Kubernetes Gateway API ドキュメントから引用します。

Gateway API は、Kubernetes のネットワーキングコミュニティによって管理されているオープンソースプロジェクトで、Kubernetes におけるアプリケーションネットワーキングをモデル化するリソースの集合です。Gateway API は、GatewayClass、Gateway、Route などのリソースをサポートしており、多くのベンダーによって実装され、業界での幅広い支持を獲得しています。

Gateway API は、有名な Ingress API の後継として着想されたもので、Transport Layer Security (TLS) のサポートが組み込まれているだけでなく、一般的に使用される多くのネットワークプロトコルを明示的にサポートしています。

AWS では、Amazon VPC Lattice を統合するために Gateway API を実装しています。AWS Gateway API コントローラーは、オープンソースプロジェクトであり、Amazon によって完全にサポートされています。AWS Gateway API コントローラーがクラスターにインストールされると、コントローラーは Gateway や Route などの Gateway API リソースの作成を監視し、上図のように対応する Amazon VPC Lattice オブジェクトを作成します。VPC Lattice のコンポーネントの詳細については、Amazon VPC Lattice のユーザーガイドをご覧ください。

AWS で Gateway API を開始する

開始するためには、Amazon EKS クラスターを作成し、Gateway API コントローラーをインストールする必要があります。前提条件となるツールとして、AWS Command Line Interface (AWS CLI)、kubectl、eksctl のインストールが必要です。これらのツールをセットアップした後に、Lattice のドキュメントに記載されている手順に従ってクラスターを作成します。

VPC Lattice のコントロールプレーンからのトラフィックを受信するため、Amazon EKS ワーカーノードのセキュリティグループで許可する必要があります。ドキュメントに記載されている手順に従って、VPC Lattice と通信する全ての Pod が、Amazon マネージドプレフィックスリストからの全てのポートのトラフィックが許可されるよう、セキュリティグループを設定する必要があります。

次に、ドキュメントに従って Amazon VPC Lattice オブジェクトを作成する権限を付与するために、AWS IAM Roles for Service Accounts (IRSA) を用いて必要な AWS Identity and Access Management (AWS IAM) リソースを作成する必要があります。以下のコマンドを使用して、コントローラーをデプロイすることができます。コントローラーは Gateway API の CRD (CustomResourceDefinitions) をインストールします。

kubectl apply -f examples/deploy-v0.0.8.yaml

Gateway API コントローラーがアクティブになり、Lattice コンポーネントを作成する準備ができました。Deployment を用いてサンプルアプリケーションを作成し、アプリケーションネットワーキング機能のデモに使用します。

kubectl apply -f examples/parking.yaml
kubectl apply -f examples/review.yaml
kubectl apply -f examples/inventory-ver1.yaml
kubectl apply -f examples/inventory-ver2.yaml

Amazon VPC Lattice コントローラーの仕組み

GatewayClass

AWS Gateway API コントローラーは amazon-vpc-lattice という新しい GatewayClass を導入しています。これは Kubernetes ユーザーが Amazon VPC Lattice サービスを使用できるようにするものです。GatewayClass はクラスタースコープのリソースで、通常は AWS のようなインフラストラクチャプロバイダーによって定義されます。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: GatewayClass
metadata:
  name: amazon-vpc-lattice
spec:
  controllerName: application-networking.k8s.aws/gateway-api-controller

kubectl apply -f examples/gatewayclass.yaml

Gateway

Gateway は、トラフィックがクラスター内のサービスにマッピングされる方法を指定します。Amazon VPC Lattice では、クラスターの default Namespace に Gateway を作成することを推奨しています。通常、Kubernetes クラスターのオペレーターは、Gateway の作成を担当します。

Gateway API コントローラーは、Gateway を作成して Kubernetes クラスターの VPC をサービスネットワークに関連付ける際に、サービスネットワークが存在しない場合は作成します。サービスネットワークは、サービスディスカバリと接続を自動で実装し、サービスの集合にアクセスとオブザーバビリティのポリシーを適用するための使用される、論理的な境界です。VPC 内の HTTP、HTTPS、gRPC プロトコルでアプリケーション間の接続を提供します。現時点で、コントローラーは HTTP と HTTPS をサポートしています。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: my-hotel
spec:
  gatewayClassName: amazon-vpc-lattice
  listeners:
    - name: http
      protocol: HTTP
      port: 80

kubectl apply -f examples/my-hotel-gateway.yaml

一度サービスネットワークで VPC が有効になると、VPC 内のクライアントは DNS を通じてサービスネットワーク内のサービスを発見することができ、すべてのアプリケーション間トラフィックを Amazon VPC Lattice 経由に誘導することができます。

HTTPRoute

アプリケーションの開発者またはサービスオーナーは、バックエンドサービスへのトラフィックのルーティング方法を定義する HTTPRoute を作成します。HTTPRoute をクラスターに適用すると、Gateway API コントローラーが 1 つまたは複数のリスナーを持つサービスを構成します。Amazon VPC Lattice では、サービスは任意の VPC またはアカウントに存在しうる論理的なコンポーネントです。リスナーは、サービスがトラフィックの受信を期待しているポート及びプロトコルを定義します。コントローラーは、Kubernetes Service (バックエンドへの参照を定義) をターゲットグループとして登録し、Pod をターゲットとして登録します。

ここでは、Kubernetes ユーザーが HTTPRoute を使用して、同一クラスター上で動作する異なるバージョンのサービス間で、トラフィックを均等にルーティングするという要件を設定する例を紹介します。

apiVersion: gateway.networking.k8s.io/v1beta1
kind: HTTPRoute
metadata:
  name: inventory
spec:
  parentRefs:
  - name: my-hotel
    sectionName: http
  rules:
  - backendRefs:
    - name: inventory-ver1
      kind: Service
      port: 8090
      weight: 50
    - name: inventory-ver2
      kind: Service
      port: 8090
      weight: 50

以下のコマンドで HTTPRoute を作成すると、Amazon VPC Lattice はサービスに DNS 名を割り当てて、コントローラーはリソースに DNS 名の Annotations を付与します。

kubectl apply -f examples/rate-route-path.yaml
kubectl apply -f examples/inventory-route-bluegreen-single-cluster.yaml

DNS 名は、以下のコマンドで確認できます。

kubectl get httproute -n default inventory -o jsonpath='{.metadata.annotations.application-networking\.k8s\.aws/lattice-assigned-domain-name}{"\n"}'

両方が同じサービスネットワークに所属しているため、parking 内から inventory サービスにアクセスできるはずです。parking と inventory サービス間のトラフィックを確認することができます。

parking Pod 内から、inventory サービスに接続することができます。

kubectl exec -ti <parking-pod> -- sh

for ((i=1;i<=30;i++)); do curl "<inventory-service-dns-name-noted-above>"; done

inventory-ver1 と inventory-ver2 のサービス間で、トラフィックが均等に分散されていることが確認できます。

Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod 
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver2 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod 
Requesting to Pod(inventory-ver2-6dc74b45d8-rlnlt): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver2-6dc74b45d8-95rsr): Inventory-ver1 handler pod
Requesting to Pod(inventory-ver1-74fc59977-wg8br): Inventory-ver1 handler pod....

クリーンアップ

予期せぬ課金が発生しないように、この記事の演習の一部として作成された全てのリソースを削除するようにしていください。Amazon EKS クラスターを削除する前に、Kubernetes API を使用して HTTPRoute と Gateway のリソースを削除しておくことを強くお勧めします。Amazon VPC コンソールにログインして、リソースが削除されたことを確認します。

結論

この記事では、Amazon VPC Lattice のための AWS Gateway API コントローラーが、アプリケーションネットワーキングを可能にするために Kubernetes Gateway API をどのようにサポートするかについて示しました。また、Gateway API と Amazon VPC Lattice リソースのマッピングを説明しました。Kubernetes API を使用して、Amazon VPC Lattice サービスネットワークの作成、サービスの関連付け、ターゲットの登録、リスナーの設定を行うことができます。また、サービスディスカバリと HTTP アプリケーション間のクラスター内通信という、基本的なユースケースを説明しました。AWS Gateway API コントローラーのドキュメントには、インストール手順と追加のユースケースを実装するための情報が含まれています。

AWS Gateway コントローラーは、追加費用なしで利用できます。ただし、Amazon VPC Lattice で生成されたコンポーネントや、Lattice を経由して転送されるデータについては料金が発生します。具体的な内容や料金については、Amazon VPC Lattice の料金ページを参照してください。

次のブログでは、コントローラーがクラスター間の通信をどのように実現するかを説明します。また、セキュリティ・認証・認可の詳細と、サービスのカスタムドメイン名のサポートについても説明します。さらに、AWS Gateway API コントローラーは、クラスター間で Kubernetes サービスの公開を可能にする Multi-cluster Service API を
実装しています。HTTPRoute 下で後方参照としてインポートされたサービスを使用するための詳細については、こちらの例を参照してください。

次のアクション

AWS Gateway API コントローラーは、Apache License 2.0 ライセンスのオープンソースプロジェクトです。試して頂いて、興味がある機能については私たちに教えてください。バグレポート、新機能、修正、ドキュメントの追加など、あらゆる貢献を歓迎します。

Amazon VPC Lattice の詳細については、AWS re:Invent 2022 のデモビデオとドキュメントを参照してください

翻訳はソリューションアーキテクトの後藤が担当しました。原文はこちらです。

Amazon Web Services ブログ