どうやって選べばいいですか? API ゲートウェイ vs. Ingress コントローラー vs. サービスメッシュ

2021 年を通じて私たちが配信した Ingress コントローラーとサービス メッシュに関するほぼすべてのウェビナーで、 「このツールは API ゲートウェイとどう違うのか?」や「Kubernetes では API ゲートウェイと Ingress コントローラー (またはサービス メッシュ) の両方が必要なのか?」といったさまざまな質問が寄せられました。

この混乱は、次の 2 つの理由から完全に理解できます。

• Ingress コントローラーとサービス メッシュは、多くの API ゲートウェイのユースケースを満たすことができます。
• 一部のベンダーは、API ゲートウェイ ツールを Ingress コントローラーやサービス メッシュの代替として位置付けています。あるいは、3 つの機能すべてを 1 つのツールにまとめています。

このブログでは、これらのツールの違いと、Kubernetes 固有の API ゲートウェイのユースケースにどのツールを使用するかについて説明します。 デモを含むさらに詳しい情報については、ウェビナー「Kubernetes の API ゲートウェイの使用例」をご覧ください。

定義

本質的に、API ゲートウェイ、Ingress コントローラ、サービス メッシュはそれぞれ一種のプロキシであり、環境内外へのトラフィックの送受信を目的として設計されています。

API ゲートウェイとは何ですか?

API ゲートウェイは、クライアントからの API リクエストを適切なサービスにルーティングします。 しかし、この単純な定義に関する大きな誤解は、API ゲートウェイが独自のテクノロジーであるという考えです。 そうではありません。 むしろ、「API ゲートウェイ」は、さまざまな種類のプロキシ（最も一般的なのは ADC またはロード バランサとリバース プロキシですが、Ingress コントローラやサービス メッシュも増えています）を介して実装できる一連のユース ケースを表します。

API ゲートウェイとして機能するツールに「必須」の機能については、業界内で合意が得られていません。 通常、お客様は次の機能（ユースケースごとにグループ化）を必要としています。

レジリエンスのユースケース

• A/B テスト、カナリア デプロイメント、ブルーグリーン デプロイメント
• プロトコル変換（JSONとXML間など）
• レート制限
• サービス検出

トラフィック管理のユースケース

• メソッドベースのルーティングとマッチング
• リクエスト/レスポンスヘッダーと本文の操作
• レイヤー 7 でのリクエスト ルーティング

セキュリティのユースケース

• API スキーマの強制
• クライアントの認証と承認
• カスタムレスポンス
• きめ細かなアクセス制御
• TLS終了

これらのユースケースのほぼすべては、Kubernetes で一般的に使用されています。 プロトコル変換やリクエスト/レスポンス ヘッダーと本文の操作は、Kubernetes やマイクロサービス環境に適していないレガシー API に一般的に結び付けられているため、あまり一般的ではありません。

API ゲートウェイの使用例の詳細については、弊社のブログの「NGINX を API ゲートウェイとしてデプロイする (パート 1)」をご覧ください。

Ingress コントローラとは何ですか?

Ingress コントローラー(Kubernetes Ingress コントローラーとも呼ばれ、略して KIC とも呼ばれます) は、トラフィックを Kubernetes に送り、サービスに送信し、再び送信する特殊なレイヤー 4 およびレイヤー 7 プロキシです (ingress-egress または north-south トラフィックと呼ばれます)。 Ingress コントローラは、トラフィック管理に加えて、可視性とトラブルシューティング、セキュリティと ID、および最も高度な API ゲートウェイの使用例を除くすべての用途にも使用できます。

Ingress コントローラーを基本的なトラフィック管理以外の用途に使用する方法については、「Ingress コントローラーの選択ガイド、パート 1」を参照してください。 要件を特定する 私たちのブログで。

サービスメッシュとは何ですか?

サービス メッシュは、 Kubernetes サービス間を流れるトラフィック (サービス間トラフィックまたは東西トラフィックと呼ばれる) を処理し、エンドツーエンドの暗号化 (E2EE) を実現するためによく使用されます。 サービス メッシュの採用は小規模ですが、高度な展開を開始したり、E2EE の要件を持つ組織が増えるにつれて増加しています。 サービス メッシュは、サービス メッシュサイドカーによってデータ プレーン レベルで可能になり、アプリに非常に近い分散型 (軽量) API ゲートウェイとして使用できます。

サービス メッシュの詳細と、サービス メッシュを導入する準備が整う時期については、弊社のブログの「サービス メッシュの選択方法」をご覧ください。

Kubernetes 環境で Kubernetes ネイティブ ツールを使用する

NGINX Sprint 2.0 のKubernetes とアプリケーション ネットワーキングの将来に関する基調講演で Mark Church 氏が述べたように、「API ゲートウェイ、ロード バランサ、サービス メッシュは、互いにますます類似し、同様の機能を提供し続けることになるでしょう」。 私たちはこの意見に全面的に賛成しており、さらに、どこで（どのように）使用するかに基づいて、仕事に適したツールを選択することが重要であると付け加えます。 結局のところ、マチェーテもバターナイフも切るために使われますが、おそらくマチェーテを朝のトーストに使うことはないでしょう。

では、どのツールが自分に適しているかをどのように判断すればよいのでしょうか? 簡単に言えば、Kubernetes 内で API ゲートウェイ機能が必要な場合は、通常、YAML などのネイティブ Kubernetes 構成ツールを使用して構成できるツールを選択するのが最適です。 通常、それは Ingress コントローラーまたはサービス メッシュです。 しかし、「API ゲートウェイ ツールには Ingress コントローラー (またはサービス メッシュ) よりも多くの機能がありますが、見逃しているのではないでしょうか?」という声も聞こえてきます。 いいえ！ 機能が多いほどツールが良くなるわけではありません。特に、ツールの複雑さが致命的となる可能性がある Kubernetes ではそれが当てはまります。

注記： Kubernetes ネイティブ( Knativeとは異なります) は、Kubernetes 用に設計および構築されたツールを指します。 通常、Kubernetes CLI で動作し、Helm を使用してインストールでき、Kubernetes 機能と統合されます。

ほとんどの Kubernetes ユーザーは、開発や GitOps エクスペリエンスの変更を回避できるため、Kubernetes ネイティブの方法で構成できるツールを好みます。 YAML 対応ツールには、主に 3 つの利点があります。

• YAML は Kubernetes チームにとって馴染みのある言語であるため、API ゲートウェイ機能に既存の Kubernetes ツールを使用している場合、学習曲線は小さく、あるいはまったくありません。 これにより、チームは、たまにしか使用しない可能性のある新しいツールの構成方法を学習する必要なく、既存のスキルセット内で作業できるようになります。
• 他の Kubernetes ツールと同じ方法で、YAML 対応ツールを自動化できます。 ワークフローにうまく適合するものはチームに人気があり、使用される可能性が高まります。
• Ingress コントローラー、サービス メッシュ、またはその両方を使用して、Kubernetes トラフィック管理ツール スタックを縮小できます。 結局のところ、すべての追加ホップは重要であり、不必要な遅延や単一障害点を追加する理由はありません。 もちろん、Kubernetes 内に導入されるテクノロジーの数を減らすことは、予算と全体的なセキュリティにとっても良いことです。

North-South API ゲートウェイの使用例: イングレスコントローラを使用する

Ingress コントローラは、多くの API ゲートウェイのユースケースを可能にする可能性があります。 定義で概説されているものに加えて、組織が最も重視するのは、次のものを実装できる Ingress コントローラーです。

• 認証と承認のオフロード
• 認証ベースのルーティング
• レイヤー 7 レベルのルーティングとマッチング (HTTP、HTTP/S、ヘッダー、Cookie、メソッド)
• プロトコルの互換性 (HTTP、HTTP/2、WebSocket、gRPC)
• レート制限

サンプルシナリオ: メソッドレベルのルーティング

Ingress コントローラを使用して API リクエスト内のPOSTメソッドを拒否し、メソッド レベルのマッチングとルーティングを実装します。

一部の攻撃者は、API 定義に準拠していないリクエスト タイプを送信することで、API の脆弱性を探します。たとえば、 GETリクエストのみを受け入れるように定義されている API にPOSTリクエストを送信します。 Web アプリケーション ファイアウォール (WAF) では、このような種類の攻撃を検出できません。WAF は、攻撃のリクエスト文字列と本文のみを検査します。そのため、不正なリクエストをブロックするには、Ingress レイヤーで API ゲートウェイを使用するのがベスト プラクティスです。

たとえば、新しい API /coffee/{coffee-store}/brand がクラスターに追加されたとします。 最初のステップは、NGINX Ingress Controller を使用して API を公開することです。API をアップストリームフィールドに追加するだけです。

apiバージョン: k8s.nginx.org/v1kind: VirtualServer
メタデータ:
名前: cafe
仕様:
ホスト: cafe.example.com
tls:
シークレット: cafe-secret
アップストリーム:
-name: tea
サービス: tea-svc
ポート: 80
-name: coffee
サービス: coffee-svc
ポート: 80

メソッド レベルのマッチングを有効にするには、ルートフィールドに/coffee/{coffee-store}/brandパスを追加し、 $request_method変数を使用してGET リクエストとPOSTリクエストを区別する 2 つの条件を追加します。 HTTP GETメソッドを使用するトラフィックはすべて自動的にコーヒーサービスに渡されます。 POSTメソッドを使用するトラフィックは、 「拒否されました」というメッセージを含むエラー ページに送信されます。 これで、新しい API を不要なPOSTトラフィックから保護できました。

ルート: - パス: /coffee/{coffee-store}/brand
一致:
- 条件:
- 変数: $request_method
値: POST
アクション:
戻り値:
コード: 403
タイプ: text/plain
本文: 「拒否されました！」
- 条件:
- 変数: $request_method
値: GET
アクション:
パス: コーヒー
- パス: /tea
アクション:
パス:tea

メソッドレベルのルーティングとエラーページのマッチングの使用方法の詳細については、 NGINX Ingress Controller のドキュメントを参照してください。 API ゲートウェイ機能に Ingress コントローラーを使用するセキュリティ関連の例については、ブログの「Okta と NGINX Ingress コントローラーを使用した Kubernetes の OpenID Connect 認証の実装」をお読みください。

East-West API ゲートウェイのユースケース: サービスメッシュを使用する

ほとんどの API ゲートウェイのユースケースでは、サービス メッシュは必須ではなく、最初から役立つわけでもありません。これは、達成したいことのほとんどが Ingress レイヤーで実行でき、また実行する必要があるためです。 しかし、アーキテクチャの複雑さが増すにつれて、サービス メッシュを使用することで価値を得られる可能性が高くなります。 私たちが最も有益だと考えるユースケースは、A/B テスト、カナリア デプロイメント、ブルーグリーン デプロイメントなど、E2EE とトラフィック分割に関連するものです。

サンプルシナリオ: カナリアデプロイメント

HTTP/S 基準に基づく条件付きルーティングを使用して、サービス間のカナリア展開を設定します。

利点は、本番環境のトラフィックのほとんどに影響を与えることなく、新しい機能やバージョンなどの API の変更を段階的に展開できることです。

現在、NGINX Ingress Controller は、NGINX Service Mesh によって管理される 2 つのサービス間でトラフィックをルーティングします。 Coffee.frontdoor.svcとTea.frontdoor.svc 。 これらのサービスは、NGINX Ingress Controller からトラフィックを受信し、それをTea.cream1.svcなどの適切なアプリ関数にルーティングします。 Tea.cream1.svcをリファクタリングして、新しいバージョンをTea.cream2.svcと呼ぶことにしました。 ベータ テスターに新しい機能に関するフィードバックを提供してもらいたいので、ベータ テスターの一意のセッション Cookie に基づいてカナリア トラフィック分割を構成し、通常のユーザーがTea.cream1.svcのみを体験できるようにします。

NGINX Service Mesh を使用して、まずTea.frontdoor.svcを先頭とするすべてのサービス ( Tea.cream1.svcとTea.cream2.svcを含む) 間でトラフィック分割を作成します。 条件付きルーティングを有効にするには、 HTTPRouteGroupリソース ( tea-hrgという名前) を作成し、それをトラフィック分割に関連付けます。その結果、ベータ ユーザーからのリクエスト (セッション クッキーがversion=betaに設定されたリクエスト) のみがTea.frontdoor.svcからTea.cream2.svcにルーティングされるようになります。 通常のユーザーは、 Tea.frontdoor.svc の背後にあるバージョン 1 のサービスのみを引き続き利用できます。

apiバージョン: split.smi-spec.io/v1alpha3kind: TrafficSplit
メタデータ:
名前: tea-svc
仕様:
サービス: tea.1
バックエンド:
- サービス: tea.1
重み: 0
- サービス: ティー.2
重量: 100
一致:
- 種類: HTTPRouteGroup
名前: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
種類: HTTPRouteGroup
メタデータ:
名前: tea-hrg
名前空間: default
仕様:
一致:
-名前: beta-session-cookie
ヘッダー:
-cookie: "version=beta"

この例では、0 ～ 100 の分割でカナリア デプロイメントを開始します。つまり、すべてのベータ テスターがTea.cream2.svc を体験することになりますが、もちろん、ベータ テスト戦略に合わせて任意の比率で開始することもできます。 ベータ テストが完了したら、シンプルなカナリア デプロイメント (Cookie ルーティングなし) を使用して、 Tea.cream2.svcの耐障害性をテストできます。

NGINX Service Mesh によるトラフィック分割の詳細については、ドキュメントをご覧ください。 上記のトラフィック分割構成は、ルート サービスもバックエンド サービスとしてリストされているため、自己参照的です。 この構成は現在、サービス メッシュ インターフェース仕様( smi-spec ) ではサポートされていません。ただし、仕様は現在アルファ版であり、変更される可能性があります。

Kubernetes アプリに API ゲートウェイ ツールを使用するタイミング (および方法)

Kubernetes の API ゲートウェイの使用例のほとんどは Ingress コントローラーまたはサービス メッシュで対処できます (対処する必要があります) が、NGINX Plus などの API ゲートウェイ ツールが適している特殊な状況もあります。

ビジネス要件

複数のチームまたはプロジェクトで Ingress コントローラーのセットを共有したり、Ingress コントローラーを環境ごとに特化したりできますが、既存の Ingress コントローラーを活用するのではなく、Kubernetes 内に専用の API ゲートウェイをデプロイすることを選択する理由がいくつかあります。 Kubernetes 内で Ingress コントローラーと API ゲートウェイの両方を使用すると、組織はビジネス要件を柔軟に達成できるようになります。 いくつかのシナリオは次のとおりです:

• API ゲートウェイ チームは Kubernetes に精通しておらず、YAML を使用していません。 たとえば、NGINX の設定に慣れている場合は、Kubernetes で API ゲートウェイとして NGINX Plus をデプロイすると、摩擦が軽減され、学習曲線が短くなります。
• プラットフォーム運用チームは、Ingress コントローラーをアプリのトラフィック管理専用にすることを希望しています。
• クラスター内のサービスの 1 つにのみ適用される API ゲートウェイのユースケースがあります。 Ingress コントローラを使用してすべての North-South トラフィックにポリシーを適用するのではなく、API ゲートウェイをデプロイして、必要な場所にのみポリシーを適用できます。

API を Kubernetes 環境に移行する

既存の API を Kubernetes 環境に移行する場合、それらの API を Kubernetes の外部にデプロイされた API ゲートウェイ ツールに公開できます。 このシナリオでは、API トラフィックは通常、外部ロード バランサー (クラスター間の負荷分散用) を経由してルーティングされ、次に API ゲートウェイとして機能するように構成されたロード バランサーにルーティングされ、最後に Kubernetes クラスター内の Ingress コントローラーにルーティングされます。

Kubernetes での SOAP API のサポート

最新の API のほとんどは REST を使用して作成されていますが (RESTful または gRPC サービスと API は Kubernetes プラットフォームを最大限に活用できるため)、再設計されていない SOAP API がまだ残っている可能性があります。 SOAP API はマイクロサービス向けに最適化されていないため Kubernetes には推奨されませんが、再設計できるようになるまで Kubernetes に SOAP API をデプロイする必要がある場合もあります。 API は REST ベースの API クライアントと通信する必要がある可能性が高いため、その場合は SOAP プロトコルと REST プロトコル間の変換を行う方法が必要になります。 この機能は Ingress コントローラーで実行できますが、大量のリソースを消費するためお勧めしません。 代わりに、SOAP と REST 間の変換を行うために、ポッドごとまたはサービスごとのプロキシとして API ゲートウェイ ツールをデプロイすることをお勧めします。

Kubernetes の内外における API トラフィック管理

Kubernetes 環境の内外にまたがる API の管理に関心を持つお客様は比較的少数です。 API 管理戦略が Kubernetes ネイティブ ツールの選択よりも優先される場合は、Kubernetes にデプロイされた「Kubernetes 対応」の API ゲートウェイ (API 管理ソリューションと統合可能) が適切な選択肢となる可能性があります。

注記： Kubernetes ネイティブ ツールとは異なり、 Kubernetes 対応ツール ( Kubernetes 対応ツールとも呼ばれる) は Kubernetes 用に設計されておらず、Kubernetes 構成を使用して管理することはできません。ただし、これらは機敏で軽量であるため、大幅な遅延を追加したり、大規模な回避策を必要としたりすることなく、Kubernetes で実行できます。

NGINXを使い始める

NGINX は、3 種類のデプロイメント シナリオすべてにオプションを提供します。

Kubernetes ネイティブ ツール:

• NGINX Ingress コントローラー– 高度なトラフィック制御とシェーピング、監視と可視性、認証とシングルサインオン (SSO)を処理する、Kubernetes 用のNGINX Plus ベースのIngress コントローラー。
• NGINX サービス メッシュ– エンタープライズ サイドカーとして NGINX Plus を搭載した、軽量でターンキー、開発者向けのサービス メッシュ。

まずは、NGINX App Protect WAF および DoS を備えた NGINX Ingress Controller の30 日間無料トライアルをリクエストし、常時無料の NGINX Service Meshをダウンロードしてください。

Kubernetes 環境の内外における Kubernetes 対応の API ゲートウェイの場合:

• NGINX Plus – 高可用性、アクティブ ヘルス チェック、DNS システム検出、セッション永続性、RESTful API などのエンタープライズ グレードの機能を備えたオールインワンのロード バランサー、リバース プロキシ、Web サーバー、API ゲートウェイ。NGINX コントローラー[現在はF5 NGINX Management Suite ]と統合して、完全な API ライフサイクル ソリューションを実現します。

NGINX Plus を API ゲートウェイとして使用する方法の詳細については、 30 日間の無料トライアルをリクエストし、 「NGINX を API ゲートウェイとしてデプロイする」を参照してください。