Implementation of Kubernetes Ingress Gateway

Kubernetes Ingress の概要

一般的に、Kubernetes クラスター内のネットワーク環境は外部から隔離されており、Kubernetes クラスター外のクライアントはクラスター内のサービスに直接アクセスできません。これは異なるネットワークドメイン間をどのように接続するかという問題です。ネットワークドメイン間のアクセスを解決する従来の方法は、対象クラスターの入口ポイントを導入することです。対象クラスターへのすべての外部リクエストはこの入口ポイントを経由し、入口ポイントが外部リクエストをターゲットノードに転送します。

同様に、Kubernetes コミュニティも入口ポイントの追加によってクラスター内のサービスを公開する方法を解決しています。Kubernetes の一貫したアプローチは、標準を定義することで同種の課題を解決することであり、クラスターへの外部トラフィック管理の問題も例外ではありません。Kubernetes はクラスター入口ポイントをさらに統合的に抽象化し、NodePort、LoadBalancer、Ingress の 3 つのソリューションを提案しました。以下の図は 3 つの方式の比較です：

比較から、Ingress がビジネス利用に最適な方式であり、より複雑なセカンダリルーティング配信に対応でき、現在ユーザーにとって主流の選択肢であることがわかります。

Kubernetes Ingress の現状

Kubernetes はクラスター入口のトラフィック管理方法を標準化・抽象化しましたが、基本的な HTTP/HTTPS トラフィック転送機能のみをカバーしており、クラウドネイティブ分散アプリケーションの大規模かつ複雑なトラフィックガバナンスには対応できません。たとえば、標準 Ingress はトラフィック分流、クロスドメイン、リライト、リダイレクトなどの一般的なトラフィックポリシーをサポートしていません。この問題に対する 2 つの主流ソリューションがあります。1 つは Ingress のアノテーションにキーバリューを定義して拡張する方法、もう 1 つは Kubernetes CRD を使用して新しい受信トラフィックルールを定義する方法です。以下の図に示します：

Kubernetes Ingress のベストプラクティス

このセクションでは、次の 5 つの領域について Kubernetes Ingress のベストプラクティスを解説します。

• トラフィック分離：複数の Ingress プロバイダーをデプロイし、影響範囲を縮小する

• カナリアリリース：Ingress アノテーションを活用したカナリアリリースの方法

• ビジネスドメイン分割：ビジネスドメインに基づいた API 設計の方法

• ゼロトラスト：ゼロトラストとは何か、なぜ必要か、どのように実践するか

• パフォーマンスチューニング：実践的なパフォーマンスチューニング手法

トラフィック分離

実際のビジネスシナリオでは、クラスター内のバックエンドサービスが外部ユーザーまたは他の内部クラスターにサービスを提供する必要があります。一般的に、外部から内部へのトラフィックをノースサウストラフィック、内部サービス間のトラフィックを東西トラフィックと呼びます。マシンコストと運用負荷を削減するため、ノースサウスと東西のトラフィックに同じ Ingress プロバイダーを共有するユーザーもいます。この方法では、外部または内部トラフィックに対するきめ細かいトラフィック管理が不可能であり、障害の影響範囲も拡大するという問題が生じます。ベストプラクティスは、外部ネットワーク用と内部ネットワーク用に Ingress プロバイダーを個別にデプロイし、実際のリクエスト規模に基づいてレプリカ数とハードウェアリソースをコントロールすることで、影響範囲を最小限に抑えつつリソース活用率を最大化することです。

カナリアリリース

ビジネスの継続的な反復開発プロセスにおいて、アプリケーションサービスは頻繁なバージョンアップグレードに直面します。最も原始的でシンプルな方法は、旧バージョンのオンラインサービスを停止してから、新バージョンのサービスをデプロイ・起動することです。すべてのユーザーに新バージョンのサービスを直接提供するこの方法には、2 つの深刻な問題があります。第一に、旧バージョンのサービスを停止してから新バージョンを起動するまでの間、アプリケーションサービスは利用不可となり、トラフィックリクエストの成功率がゼロに低下します。第二に、新バージョンに深刻なプログラムのバグが存在する場合、新バージョンから旧バージョンへのロールバック操作によりサービスが一時的に利用不可となり、ユーザーエクスペリエンスに影響を与えるだけでなく、業務システム全体に多くの不安定要素をもたらします。

では、迅速なビジネス反復の要求を満たしつつ、アップグレードプロセス中のアプリケーションの外部可用性を確保するにはどうすればよいでしょうか？

以下の核心的な課題に対処する必要があると考えます：

アップグレードの影響をどのように軽減するか？

新バージョンにバグが発生した場合、どのようにして安定したバージョンに素早くロールバックするか？

3. 標準 Ingress がトラフィック分流をサポートしていないという制約をどのように解決するか？

最初の 2 つの課題について、業界の共通認識として、カナリアリリース（グレーリリース）の使用が一般的なアプローチです。カナリアリリースの考え方は、少数のリクエストを新バージョンにリダイレクトすることで、新バージョンのサービスのデプロイにはごく少数のマシンだけで済みます。新バージョンが期待通りであることを検証した後、トラフィックを徐々に調整して旧バージョンから新バージョンへ段階的に移行します。この期間中、新旧バージョン間のトラフィック分布に基づいて新バージョンのサービスをスケールアウトし、旧バージョンのサービスをスケールダウンすることで、基盤リソースの活用率を最大化できます。

Ingress の現状に関するセクションで、Ingress を拡張する 2 つの一般的な方式について触れました。3 つ目の課題は、アノテーションにキーバリューを追加することで解決できます。アノテーションでは、カナリアリリースに必要なポリシー構成を定義できます。たとえば、カナリアトラフィック用のヘッダーとクッキーの構成、対応する値のマッチング方法（完全一致または正規表現マッチング）などです。その後、Ingress プロバイダーが新しく定義されたアノテーションを識別し、自身のルーティングルールとして解析します。つまり、ユーザーが選択した Ingress プロバイダーが多様なルーティング方式をサポートしていることが重要です。

カナリアリリース - ヘッダーベースのカナリアリリース

新バージョンの小流量検証サービスが期待通りかどうかを検証するプロセスにおいて、特定の特性を持つオンライントラフィックを選択的に小流量として扱うことができます。リクエストコンテンツのヘッダーとクッキーはどちらもリクエスト特性と見なせるため、同じ API に対してヘッダーまたはクッキーに基づいてオンライントラフィックをセグメント化できます。実際のトラフィックにヘッダーの差異がない場合は、オンライン環境に基づいてカナリア用ヘッダーを持つトラフィックを手動で作成し、検証を実施できます。さらに、クライアントの重要度に基づいて新バージョンの検証を段階的に実施することもできます。たとえば、一般ユーザーのアクセスリクエストは新バージョンへのアクセスを優先し、検証完了後に VIP ユーザーを徐々に移行させます。一般的に、これらのユーザー情報やクライアント情報はクッキーに保存されています。

Nginx Ingress を例にとると、アノテーションは Ingress トラフィックの分流をサポートしています。ヘッダーベースのカナリアリリースのスキーマ図は以下の通りです：

カナリアリリース - 重み付けベースのカナリアリリース

ヘッダーベースのカナリアリリース方法では、特定のリクエストまたはユーザーに新バージョンのサービスを提供できますが、新バージョンにアクセスするリクエストの規模を適切に評価できず、新バージョンのマシン割り当て時にリソース活用を最大化できない場合があります。重み付けベースのカナリアリリース方法ではトラフィック比率を正確にコントロールできるため、マシンリソースの割り当てが容易になります。初期段階で小流量の検証を通過した後、後期段階でトラフィックの重みを調整することで段階的にバージョンアップグレードを完了します。この方法は操作がシンプルで管理が容易です。ただし、オンライントラフィックは区別なく新バージョンに向けられるため、重要なユーザーのエクスペリエンスに影響する可能性があります。重み付けベースのカナリアリリースのスキーマ図は以下の通りです：

ビジネスドメインの分割

クラウドネイティブアプリケーションの規模拡大に伴い、開発者はモノリシックアーキテクチャを細かく分割し、単一アプリケーション内のサービスモジュールを独立してデプロイ・実行されるマイクロサービスに分割するようになりました。これらのマイクロサービスのライフサイクルは対応するビジネスチームが専任で担当し、モノリシックアーキテクチャの俊敏性と柔軟性の不足を効果的に解決しています。しかし、どのようなアーキテクチャにも万能策はなく、古い課題を解決する一方で新しい課題も必然的に生じます。モノリシックアプリケーションは 4 層 SLB で外部公開を完結できましたが、分散アプリケーションは Ingress に依存して 7 層のトラフィック分散機能を提供する必要があります。ルーティングルールの設計方法が特に重要になります。

一般的に、サービスはビジネスまたは機能ドメインに基づいて分割されるため、Ingress でサービスを公開する際もこの原則に従うことができます。マイクロサービスの外部 API を設計する際、元のパスに代表的なビジネスプレフィックスを追加できます。リクエストのルーティングマッチング完了後、バックエンドサービスへの転送前に、Ingress プロバイダーがパスのリライトによってビジネスプレフィックスを削除する作業を完了します。ワークフロー図は以下の通りです：

この API 設計原則は、公開されたサービスコレクションの管理を容易にし、サービスプレフィックスに基づいたきめ細かい認証を実現し、各ビジネスドメインにわたるサービスの統合的な可観測性構築を支援します。

ゼロトラスト

セキュリティの問題は常にビジネスアプリケーションにとって最大の課題であり、ビジネス開発の全ライフサイクルに影響します。さらに、外部インターネット環境はますます複雑化し、内部ビジネスアーキテクチャも大規模化しています。デプロイメント構成はパブリッククラウド、プライベートクラウド、ハイブリッドクラウドなど複数の形態にまたがり、セキュリティ問題はますます深刻になっています。ゼロトラストはセキュリティ分野の新しい設計モデルとして、アプリケーションネットワーク内外のすべてのユーザーとサービスが信頼できないという前提に立ち、リクエストの送信と処理前に必ず ID 認証を行うことを要求します。すべての認可操作は最小権限の原則に従います。簡単に言えば、誰も信用せず、すべてを検証するということです。

以下の図は、外部ユーザー → Ingress プロバイダー → バックエンドサービス全体のエンドツーエンドのゼロトラスト概念のアーキテクチャ図です：

• 外部ユーザーと Ingress プロバイダー。外部ユーザーは Ingress プロバイダーが権威ある認証局に提供した証明書を検証することで ID 認証を完了します。Ingress プロバイダーは外部ユーザーに JWT 資格情報を提供することで認証を完了します。

• Ingress プロバイダーとバックエンドサービス。Ingress プロバイダーはバックエンドサービスが内部プライベート認証局に提供した証明書を検証することで ID 認証を完了します。バックエンドサービスは Ingress プロバイダーが内部プライベート証明書に提供した証明書を検証することで ID 認証を完了します。同時に、バックエンドサービスは呼び出し元の ID に基づいて認可サービスへの認証操作を実行できます。

パフォーマンスチューニング

すべての外部トラフィックはまず Ingress プロバイダーを通過する必要があるため、主なパフォーマンスボトルネックは Ingress プロバイダーにあり、高い同時実行性とパフォーマンスが求められます。各 Ingress プロバイダー間のパフォーマンス差に関わらず、カーネルパラメータの調整によりさらなるパフォーマンスの解放が可能です。Alibaba のクラスターアクセス層での長年の実践経験から、以下のカーネルパラメータを適切に調整できます：

1. TCP 接続キューの容量拡大：net.core.somaxconn

2. 利用可能なポート範囲の拡大：net.ipv4.ip_local_port_range

3. TCP 接続の多重利用：net.ipv4.tcp_tw_reuse

もう 1 つの最適化の観点は、ハードウェアの性能を十分に引き出し、基盤ハードウェアの計算パワーを解放することでアプリケーション層のパフォーマンスをさらに向上させることです。現在、HTTPS はパブリックネットワークリクエストの主流となっています。HTTPS を全面的に使用すると、TLS ハンドシェイクが必要になるため、HTTP と比べて大幅なパフォーマンス低下が避けられません。現在、CPU パフォーマンスの大幅な向上に伴い、CPU の SIMD メカニズムを活用して TLS のパフォーマンスを効果的に高速化できます。この最適化スキームはマシンハードウェアのサポートと Ingress プロバイダーの内部実装に依存します。

現在、Istio-Envoy アーキテクチャに基づく MSE Cloud Native Gateway と Alibaba Cloud の第 7 世代 ECS の組み合わせにより、TLS ハードウェアアクセラレーションをいち早く実現し、ユーザーのリソースコストを増やすことなく HTTPS パフォーマンスを大幅に向上させています。

Ingress プロバイダーの新選択肢 - MSE Cloud Native Gateway

クラウドネイティブ技術の継続的な進化とクラウドネイティブアプリケーションのマイクロサービス化の深化に伴い、Nginx Ingress は複雑なルーティングルール設定、複数のアプリケーション層プロトコル（Dubbo、QUIC など）のサポート、サービスアクセスのセキュリティ、トラフィックの可観測性といった課題に対応するのが難しくなっています。さらに、Nginx Ingress は再読み込み方式で構成更新を処理するため、大規模なロングコネクション環境では瞬断が発生する可能性があり、頻繁な構成変更がビジネストラフィックの損失を招く恐れがあります。

大規模トラフィックガバナンスに対するユーザーの強い需要に応えるため、MSE Cloud Native Gateway が登場しました。これは Alibaba Cloud が提供する Ingress 標準に準拠した次世代ゲートウェイで、低コスト、安全、高度な統合、高可用性の製品特長を備えています。従来の WAF ゲートウェイ、トラフィックゲートウェイ、マイクロサービスゲートウェイを統合し、リソースコストを 50% 削減しながら、きめ細かいトラフィックガバナンス機能を提供します。ACK コンテナサービス、Nacos、Eureka、固定アドレス、FaaS など複数のサービス検出方式をサポートし、複数の認証・ログイン方式に対応してセキュリティ防御線を迅速に構築できます。メトリックモニタリング、ログ分析、分散トレーシングなど包括的で多角的なモニタリングシステムを提供し、単一および複数の Kubernetes クラスターモードで標準 Ingress リソースの解析をサポートすることで、クラウドネイティブアプリケーション環境での宣言的な統合トラフィックガバナンスを実現します。さらに、WASM プラグインマーケットプレイスを導入し、ユーザーのカスタマイズニーズに対応しています。

Nginx Ingress と MSE Cloud Native Gateway の比較

以下は Nginx Ingress と MSE Cloud Native Gateway の比較まとめです：

スムーズな移行

MSE Cloud Native Gateway は Alibaba Cloud のマネージドサービスで、運用保守不要、コスト削減、豊富な機能を備え、Alibaba Cloud の周辺製品と深く統合されています。以下の図は Nginx Ingress から MSE Cloud Native Gateway へのシームレスな移行方法を示しています。他の Ingress プロバイダーもこの方法を参考にできます。

ハンズオン

次に、Alibaba Cloud Container Service ACK を基盤とする Ingress プロバイダー、MSE Cloud Native Gateway の実践操作を行います。MSE Ingress Controller を通じてクラスターの入口トラフィックを管理する方法を学びます。

操作ドキュメントのアドレス：

https://help.aliyun.com/document_detail/426544.html

前提条件

MSE Ingress Controller のインストール

Alibaba Cloud Container Service のアプリケーションマーケットプレイスで ack-mse-ingress-controller を検索し、コンポーネント以下の操作ドキュメントに従ってインストールを完了します。

CRD を通じた MSE クラウドネイティブゲートウェイの作成

MseIngressConfig は MSE Ingress Controller が提供する CRD リソースで、MSE クラウドネイティブゲートウェイインスタンスのライフサイクルを管理します。1 つの MseIngressConfig が 1 つの MSE クラウドネイティブゲートウェイインスタンスに対応します。複数の MSE クラウドネイティブゲートウェイインスタンスを使用する場合は、複数の MseIngressConfig 設定を作成する必要があります。簡単なデモのため、最小限の構成でゲートウェイを作成します。

Kubernetes 標準の IngressClass を設定して MseIngressConfig と関連付けます。関連付けが完了すると、クラウドネイティブゲートウェイはクラスター内の IngressClass に関連する Ingress リソースのリッスンを開始します。

MseIngressConfig のステータスを確認することで現在の状態を把握できます。MseIngressConfig は Pending → Running → Listening の順序で状態が変化します。各ステータスの説明は以下の通りです：

• Pending：クラウドネイティブゲートウェイが作成中であることを示します。約 3 分待つ必要があります。

• Running：クラウドネイティブゲートウェイが正常に作成され、実行中であることを示します。

• Listening：クラウドネイティブゲートウェイが実行中で、クラスター内の Ingress リソースをリッスンしていることを示します。

• Failed：クラウドネイティブゲートウェイが不正な状態にあることを示します。Status フィールドの Message を確認して原因を特定できます。

カナリアリリースの実践

クラスター内に httpbin というバックエンドサービスがあり、バージョンアップ時にヘッダーに基づくカナリア検証を行いたいとします。図に示す通りです：

まず httpbin の v1 と v2 をデプロイし、以下のリソースを ACK クラスターに適用します。

以上が Ingress アノテーションを使用して標準 Ingress の高度なトラフィックガバナンス機能を拡張し、カナリアリリースをサポートする方法です。