Kong Gateway Enterprise と Amazon EKS Anywhere ベアメタル

Kong Gateway Enterprise と Amazon EKS Anywhere ベアメタルでアプリケーションの近代化と移行を強化
1. Kong Gateway Enterprise の原則
2. Amazon EKS Anywhere ベアメタルと Kong Gateway Enterprise
EKS Anywhere のクラスター展開
Kong Gateway Enterprise のハイブリッド展開
サービスとルートの定義
まとめ

Kong Gateway Enterprise と Amazon EKS Anywhere ベアメタルでアプリケーションの近代化と移行を強化

アプリケーションの近代化プロジェクトで最も重要な要件の 1 つは、複数のプラットフォームで実行されるワークロードをサポートすることです。このようなプロジェクトには、ハイブリッドモデルを使用したワークロードの移行プロセスも当然含まれます。

また、近代化プロジェクトによって生まれた既存のサービスやマイクロサービスは、メインプラットフォームとして Kubernetes を採用することが一般的です。

Kubernetes は、モダンアプリケーションを開発するための新しいプラットフォームとして、デファクトスタンダードとなっています。Kubernetes が提供する膨大な技術リソースの中で最も重要なのは、アプリケーションのライフサイクル全体にわたる標準化された環境と言えるでしょう。つまり、アプリケーションがインストールされるコンテキストに関係なく、またオンプレミスかクラウドコンピューティングかに関係なく、Kubernetes のディストリビューションを利用できます。

これが、Amazon EKS Anywhere (EKS-A) サービスの目的 ― よく知られた Amazon EKS テクノロジを複数の環境にわたって提供する ― です。

Kong Gateway Enterprise の原則

Kong Gateway Enterprise の原則は、EKS Anywhere が提供する柔軟性と完全に一致する次のような機能をネイティブで提供することです。

アーキテクチャの自由度。Kong は、Linux ベースの OS、Docker、Amazon EKS や Amazon EKS Anywhere などの Kubernetes を含むあらゆるプラットフォームでサービスを接続します。
Kubernetes ネイティブ。Kong は、CRD、HPA (「Horizontal Pod Autoscaler」)、Cert-Manager、Knative、Helm Charts、Operators など、プラットフォームが提供するすべての機能を含む Kubernetes を完全にサポートします。
ハイブリッドおよびマルチクラウド。マルチプラットフォームエンジンを提供するだけでは十分ではなく、ハイブリッドやマルチクラウド構成など、あらゆるインフラや展開パターンにおいて、複数のプラットフォームを同時にサポートする必要があります。

Kong Gateway のハイブリッド展開では、コントロールプレーン (CP) とデータプレーン (DP) を完全に分離し、管理タスクを担当するコントロールプレーンと、API コンシューマーが排他的に使用するデータプレーンは、完全に別の環境で実行されます。

つまり、両技術を相乗的に組み合わせることで、重要なアプリケーションを実行するための強力なプラットフォームが誕生するのです。

Amazon EKS Anywhere ベアメタルと Kong Gateway Enterprise

Amazon EKS Anywhere は、プロバイダーの概念に基づいています。各プロバイダーは、特定の環境に EKS クラスターを展開することが可能です。2021 年 9 月にリリースされた最初の Amazon EKS Anywhere バージョンは、ローカル開発クラスター用に Docker を、本番クラスター用に VMware vSphere をサポートしていました。

最新バージョンの Amazon EKS Anywhere は、ベアメタルをサポートする別の展開ターゲットを提供します。

以下の図は、Amazon EKS および Amazon EKS Anywhere プラットフォーム上の Kong Gateway Enterprise のハイブリッド展開を示したものです。

Kong Control Plane は、AWS クラウド上の EKS クラスターで動作します。これは、API、ポリシー、API ドキュメントを作成するため管理者のみが使用する安定した環境です。
Kong Data Plane #1 は、ベアメタルに展開されたオンプレミスの EKS Anywhere クラスターで実行されます。アプリケーションサーバー、レガシーシステム、他の EKS Anywhere クラスターなど、すべての環境に展開されるサービスやマイクロサービスを公開します。
Kong Data Plane #2 は、VMware vSphere ベースの別の EKS Anywhere クラスターで実行されます。Kong DP #1 と同様の役割を果たし、ローカルサービスやアプリケーションを公開します。
Kong Data Plane #3 は、Kong Control Plane と同様に AWS クラウド上で動作しますが、別の AWS リージョンで動作します。オンプレミス環境から移行したマイクロサービスやサービス、または ECS や EC2/ASG などのクラウド環境で開発された新しいマイクロサービスをサポートします。
すべてのデータプレーンは、OIDC ベースの認証処理を行う Cognito、ログ処理を行う Opensearch などの AWS サービスを活用し、マイクロサービスやサービスが安全に使用されるようにポリシーを実装しています。
コントロールプレーンとデータプレーン間の通信には、mTLS トンネルを使用しています。コントロールプレーンは、特定のトンネルを使用して、既存のすべてのデータプレーンに API とポリシーを公開します。一方、各データプレーンは、別のトンネルを使用して、API リクエスト処理に関するメトリックをコントロールプレーンにレポートバックします。

EKS Anywhere は、主に 3 つの技術に基づいて構築されています。

EKS Distro (Amazon の Kubernetes 用のオープンソースディストリビューション)
Cluster API プロジェクト: クラスターの作成、設定、管理のための Kubernetes 形式の宣言型 API に注目した Kubernetes プロジェクト。
Tinkerbell: ベアメタルのプロビジョニングと管理のためのプロジェクト。特定の CAPT (Cluster-API-Provider-Tinkerbell) プロバイダーが、EKS Anywhere インフラストラクチャに組み込まれています。

次の図は、Amazon EKS Anywhere ベアメタルと Kong Gateway Enterprise アーキテクチャのトポロジを説明したものです。

ここでは、Control Plane を EKS で、Data Plane を EKS Anywhere で実行するハイブリッドな Kong Gateway Enterprise の導入について、2 つの主要なプロセスを説明します。

EKS Anywhere のクラスター展開
Kong Gateway Enterprise のハイブリッド展開

EKS Anywhere のクラスター展開

EKS Anywhere のクラスター展開プロセスは、管理サーバーノードから開始します。このサーバーには 2 つの主要コンポーネントがあります。

Tinkerbell Stack: iPXE リモートブートおよびオペレーティングシステムのプロビジョニングを含むベアメタルサーバーのプロビジョニングを担当します。
EKS Anywhere ブートストラップクラスター: Cluster API のブートストラップクラスター定義に基づく一時的なクラスターで、両方のベアメタルサーバー上で動作する EKS Anywhere ワークロードクラスター (これも Cluster API 定義に基づく) をプロビジョニングする役割を担います。ワークロードクラスターは、典型的な EKS コントロールプレーンとワーカーノードを含んでいます。

管理サーバーノードで使用される EKS Anywhere CLI は、すべてのコンポーネントを抽象化します。基本コマンドは、2 つの設定ファイルを入力として、ブートストラップクラスターとワークロードクラスターの両方を作成します。以下に例を示します。

eksctl-anywhere create cluster -f ClusterSpec.yml --hardware-csv Hardware.csv

次の 2 つの設定ファイルがあります。

ClusterSpec.yml: ブートストラップクラスターによって EKS Anywhere ワークロードクラスターを作成する方法が記述されています。

Hardware.csv: MAC アドレスを含むベアメタルサーバーの場所が記述されており、Tinkerbell Stack は iPXE リモートブートを使用してプロビジョニングできます。

クラスター作成プロセスでは、EKS Anywhere CLI は管理サーバーノード上にブートストラップ kind クラスターを作成し、Cluster-API (CAPI) および Cluster-API-Provider-Tinkerbell (CAPT) コンポーネントをインストールします。

CAPI はクラスターノードのリソースを作成し、CAPT はハードウェアをノードにマップし、対応するベアメタルサーバーの電源をオンにします。ベアメタルサーバーは iPXE ブートし、Tinkerbell インフラストラクチャと通信することで OS のプロビジョニングプロセスを実行します。両サーバーとも OS は Ubuntu でプロビジョニングされています。

クラスター管理リソースは、ブートストラップクラスターからターゲットの EKS Anywhere ワークロードクラスターに転送されます。最後に、ローカルのブートストラップ kind クラスターが管理サーバーノードから削除されます。

Kong Gateway Enterprise のハイブリッド展開

eksctl-anywhere create cluster コマンドを実行すると、2 台のベアメタルサーバーに Kong Gateway (正確には Kong Data Plane) を展開する準備が整います。

Control Plane の展開

EKS Anywhere のワーカーノードに Kong Data Plane を展開する前に、Kong Control Plane を処理する必要があります。これは、図に示すように、AWS クラウド上の通常の Amazon EKS クラスターで実行されます。

eksctl CLI を使用することで、新しい Amazon EKS クラスターを利用できます。以下に例を示します。

eksctl create cluster --name kong-control-plane --version 1.21 --nodegroup-name standard-workers --node-type t3.large --nodes 1

そして、Kong Gateway Helm Charts を使用して、Control Plane を展開できます。以下は Helm コマンドの例です。

helm install kong kong/kong -n kong \
--set ingressController.enabled=true \
--set ingressController.installCRDs=false \
--set ingressController.image.repository=kong/kubernetes-ingress-controller \
--set ingressController.image.tag=2.4 \
--set image.repository=kong/kong-gateway \
--set image.tag=2.8.1.1-alpine \
--set env.database=postgres \
--set env.role=control_plane \
--set env.cluster_cert=/etc/secrets/kong-cluster-cert/tls.crt \
--set env.cluster_cert_key=/etc/secrets/kong-cluster-cert/tls.key \
--set cluster.enabled=true \
--set cluster.type=LoadBalancer \
--set cluster.tls.enabled=true \
--set cluster.tls.servicePort=8005 \
--set cluster.tls.containerPort=8005 \
--set clustertelemetry.enabled=true \
--set clustertelemetry.type=LoadBalancer \
--set clustertelemetry.tls.enabled=true \
--set clustertelemetry.tls.servicePort=8006 \
--set clustertelemetry.tls.containerPort=8006 \
--set proxy.enabled=true \
--set proxy.type=ClusterIP \
--set admin.enabled=true \
--set admin.http.enabled=true \
--set admin.type=LoadBalancer \
--set enterprise.enabled=true \
--set portal.enabled=false \
--set portalapi.enabled=false \
--set enterprise.rbac.enabled=false \
--set enterprise.smtp.enabled=false \
--set manager.enabled=true \
--set manager.type=LoadBalancer \
--set secretVolumes[0]=kong-cluster-cert \
--set postgresql.enabled=true \
--set postgresql.postgresqlUsername=kong \
--set postgresql.postgresqlDatabase=kong \
--set postgresql.postgresqlPassword=kong \
--set enterprise.license_secret=kong-enterprise-license

Kong Control Plane の最も重要な設定は次のとおりです。

env.role=control_plane: この Kong Gateway インスタンスを Control Plane として設定します。
cluster.type=LoadBalancer: ロードバランサーを使用して Control Plane を公開します。Data Plane は、これを参照して mTLSベースの暗号化トンネルを取得します。
cluster.tls.servicePort=8005: API とポリシーを公開する mTLS トンネルポートを指定します。
clustertelemetry.type=LoadBalancer: テレメトリエンドポイントを Data Plane に公開します。
clustertelemetry.tls.servicePort=8006: Data Plane が API の使用に関するメトリックを Control Plane にレポートバックするために使用するトンネルポートを指定します。

Kong Gateway Enterprise のハイブリッド展開の詳細は、AWS Portal で公開されている Kong Workshop をご確認ください。

Kong Gateway は Helm Charts だけでなく、YAML 宣言やオペレーターなど、通常の Kubernetes のメカニズムを利用して展開できます。また、これらのツールを IaC (Infrastructure as Code) 技術と組み合わせることで、展開プロセスの自動化に非常に役立ちます。たとえば、AWS CloudFormation と AWS CDK (Cloud Development Kit) は、EKS だけでなく ECS や EC2/ASG など、複数のプラットフォームで Kong Gateway をプロビジョニングするための素晴らしいサービスです。詳細は、Kong と CDK のチュートリアル、Kong 向けの CDK Construct Library をご確認ください。

Helm コマンドを送信すると、管理者が Control Plane を利用できるようになります。Control Plane は、いくつかのメカニズムを利用して、新しい API やポリシーを設定できます。

REST Admin API: すべての管理者タスクは、広範な Admin API を使用して実行できます。
decK: 管理者は、宣言的な方法で Kong Gateway の設定を管理できます。
CRD: Kubernetes に基づいた特定の宣言。
Kong Manager: 公式の Kong Gateway Admin GUI。Kong Manager のスクリーンショットを以下に示します。

Data Plane の展開

Control Plane が利用できるようになったので、次に EKS Anywhere ワークロードクラスター上のワーカーノードに Kong Data Plane を展開します。以下に Helm コマンドを示します。

helm install kong kong/kong -n kong \

--set ingressController.enabled=false \

--set image.repository=kong/kong-gateway \

--set image.tag=2.8.1.1-alpine \

--set env.database=off \

--set env.role=data_plane \

--set env.cluster_cert=/etc/secrets/kong-cluster-cert/tls.crt \

--set env.cluster_cert_key=/etc/secrets/kong-cluster-cert/tls.key \

--set env.lua_ssl_trusted_certificate=/etc/secrets/kong-cluster-cert/tls.crt \

--set env.cluster_control_plane=<Control_Plane_Cluster_LoadBalancer>:8005 \

--set env.cluster_telemetry_endpoint=<Control_Plane_ClusterTelemetry_LoadBalancer>:8006 \

--set proxy.enabled=true \

--set proxy.type=NodePort \

--set enterprise.enabled=true \

--set enterprise.portal.enabled=false \

--set enterprise.rbac.enabled=false \

--set enterprise.smtp.enabled=false \

--set manager.enabled=false \

--set portal.enabled=false \

--set portalapi.enabled=false \

--set env.status_listen=0.0.0.0:8100 \

--set secretVolumes[0]=kong-cluster-cert \

--set enterprise.license_secret=kong-enterprise-license

ここで、最も重要な設定は次のとおりです。

env.role=data_plane: この Kong Gateway インスタンスを Data Plane として設定します。
env.database=off: Control Plane とは異なり、メタデータを保存するためのデータベースを必要とせず、代わりに Control Plane で構築した特定の mTLS トンネルを使用して、すべての API とポリシー定義を取得します。
env.cluster_control_plane=<Control_Plane_Cluster_LoadBalancer>:8005: 公開された Control Plane の IP とポートを参照します。
env.cluster_telemetry_endpoint=<Control_Plane_ClusterTelemetry_LoadBalancer>:8006: 2 番目の Control Plane の IP とポートを参照します。
proxy.type=NodePort: API コンシューマーに Data Plane を公開する方法を定義します。

Data Plane は NodePort サービスとして公開されるため、EKS Anywhere クラスターの前にある外部ロードバランサーを展開できます。Amazon EKS Anywhere クラスターで Kube-VIP または MetalLB を使用する方法については、ドキュメントを確認してください。

Kong Control Plane から Kong Data Plane を確認する

Data Plane を展開したら、Data Plane はすでに Kong Control Plane に接続されているはずです。Control Plane が公開する /clustering/status エンドポイントに REST Admin リクエストを送信することでこれを確認できます。以下に例を示します。

$ http <Control_Plane_LoadBalancer>:8001/clustering/status
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 178
Content-Type: application/json; charset=utf-8
Date: Fri, 10 Jun 2022 13:55:27 GMT
Deprecation: true
Server: kong/2.8.1.1-enterprise-edition
X-Kong-Admin-Latency: 11
X-Kong-Admin-Request-ID: HBtaUpGJFMKSA5Mqaj0BUxT8yLsWa21I
vary: Origin

{
    "9e3e77e4-1787-48c5-b891-e64d05ba2eb1": {
        "config_hash": "6085b343870b77813c810834abf70216",
        "hostname": "kong-dp-kong-69d9486f9d-464xf",
        "ip": "192.168.81.32",
        "last_seen": 1624024517
    }
}

HTTPie の結果は、Data Plane が Control Plane に正常に接続されていることを示しています。

サービスとルートの定義

Kong Control Plane と Kong Data Plane の両方が実行されている状態で、最初の API を作成してみましょう。Kong API は、2 つのコンストラクトをベースにしています。

Kong Service: 外部のアップストリーム API またはマイクロサービスを表します。
Kong Route: 外部のコンシューマーに Kong Service を公開します。

Kong Service の作成

次の Kong Service は、外部で公開されている HTTPbin サービスに基づいています。

http <Control_Plane_LoadBalancer>:8001/services name=httpservice url='http://httpbin.org''

Kong Route の作成

次の Kong Route は、先に作成した Kong Service を /httpbin パスで公開します。

http <Control_Plane_LoadBalancer>:8001/services/httpservice/routes name='httpbinroute' paths:='["/httpbin"]'

Kong Route の使用

Kong Service や Kong Route など、定義されたすべてのコンストラクトを Kong Data Plane に公開するのは Kong Control Plane の責任です。そのため、どちらも使用できるようにする必要があります。

$ http <DataPlane_PublicIP>:8000/httpbin/get
HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 434
Content-Type: application/json
Date: Sat, 10 Jun 2022 21:13:51 GMT
Server: gunicorn/19.9.0
Via: kong/2.8.1.1-enterprise-edition
X-Kong-Proxy-Latency: 59
X-Kong-Upstream-Latency: 182

{
    "args": {},
    "headers": {
        "Accept": "*/*",
        "Accept-Encoding": "gzip, deflate",
        "Host": "httpbin.org",
        "User-Agent": "HTTPie/2.4.0",
        "X-Amzn-Trace-Id": "Root=1-60a0398f-3b2c25473810111760cd655b",
        "X-Forwarded-Host": "3.124.242.23",
        "X-Forwarded-Path": "/httpbin/get",
        "X-Forwarded-Prefix": "/httpbin"
    },
    "origin": "186.204.145.204, 3.124.242.23",
    "url": "http://3.124.242.23/get"
}

まとめ

Kong Gateway Enterprise と Amazon EKS Anywhere は、複数のプラットフォームにまたがるハイブリッドな展開でサービスを簡単に実行し、オンプレミスとクラウドのワークロードをサポートします。本ブログで紹介した製品の詳細は、公式ドキュメント「Amazon Elastic Kubernetes Services」と「Kong Gateway Enterprise」を参照してください。

また、AWS ElastiCache for Redis によるキャッシュ、AWS Opensearch Services によるログ処理、AWS Cognito による OIDC ベースの認証、カナリア、GraphQL 統合など、Kong Gateway Enterprise が提供する幅広いプラグインを利用して、自由に API ポリシーを適用し実験してください。

Kong Enterprise の概要、価格、およびライセンス体系などの詳細は、こちらを参照してください。

Kong Gateway Enterprise と Amazon EKS Anywhere ベア メタルでアプリケーションの近代化と移行を強化