Azure Kubernetes Service の Application Gateway イングレス コントローラー

2019年12月2日 に投稿済み

Principal Software Engineer

Azure Kubernetes Service (AKS) と Application Gateway を組み合わせた新しいソリューションを提供できることを嬉しく思います。この新しいソリューションは、Kubernetes 用のオープン ソース Application Gateway イングレス コントローラー (AGIC) を提供します。これにより、AKS のお客様は、Application Gateway を活用して、クラウド ソフトウェアをインターネットに公開できます。

お客様から最も要望が多かったのは、高度な Kubernetes 環境を簡単に操作するためのマネージド Kubernetes サービスである Azure Kubernetes Service と、ネイティブかつスケーラブルで可用性の高い L7 ロード バランサーである Azure Application Gateway のメリットを 1 つにまとめることです。

移行手順

Application Gateway イングレス コントローラーは、お客様の AKS の独自のポッドで実行されます。イングレス コントローラーでは、Kubernetes リソースのサブセットに変更がないかを監視します。AKS クラスターの状態は Application Gateway の特定の構成に変換され、Azure Resource Manager に適用されます。Application Gateway を継続的に再構成することによって、AKS サービスへのトラフィックのフローが中断されないようにします。下の図は、Application Gateway イングレス コントローラーを使用した Kubernetes API から Resource Manager、次いで Application Gateway への状態と構成変更のフローを示しています。

最もよく利用されている Kubernetes イングレス コントローラーと同じように、Application Gateway イングレス コントローラーでは Azure のネイティブ Application Gateway L7 ロード バランサーを活用する機能がいくつか提供されます。以下にいくつか例を挙げます。

  • URL ルーティング
  • Cookie ベースのアフィニティ
  • Secure Sockets Layer (SSL) 終了
  • エンド ツー エンド SSL
  • パブリック、プライベート、ハイブリッド Web サイトのサポート
  • Web アプリケーション ファイアウォールを統合

agic2

Application Gateway イングレス コントローラーのアーキテクチャは、クラスター L7 ロード バランサーの場合とは異なります。アーキテクチャの違いを、次の図に示します。

clip_image003

  • クラスター内のロード バランサーでは、Kubernetes クラスターのコンピューティング リソースを活用して、すべてのデータ パス操作を実行します。これは、隣接するビジネス アプリとリソースについて競合します。クラスター内のイングレス コントローラーは Kubernetes Service リソースを作成し、ネットワーク トラフィックに kubenet を活用します。イングレス コントローラーと比較して、トラフィック フローでは余分なホップを経由します。
  • イングレス コントローラーは AKS の高度なネットワークを活用することにより、Application Gateway と共有されているサブネットから、各ポッドの IP アドレスを割り当てます。Application Gateway は、すべての Kubernetes ポッドに直接アクセスできます。これにより、データが kubenet を通過する必要がなくなります。このトピックの詳細については、記事「Azure Kubernetes Service 内のアプリケーションに関するネットワーク概念」の「ネットワーク モデルの比較」セクションをご覧ください。

ソリューションのパフォーマンス

Application Gateway は Kubernetes ポッドに直接接続しているため、Application Gateway イングレス コントローラーでは、クラスター内のイングレス コントローラーに比べてネットワーク待ち時間が最大 50 % 短縮されます。Application Gateway は、Azure 仮想マシン スケール セットによってサポートされているマネージド サービスです。その結果、Application Gateway では、データ パスの処理に AKS コンピューティング リソースを使用しません。Kubernetes デプロイに割り当てられているリソースを共有したり、干渉したりすることはありません。クラスター内のイングレスとは異なり、ピーク時に Application Gateway の自動スケーリングが行われるため、アプリのポッドの迅速なスケールアップが妨げられることはありません。また、当然のことながら、クラスター内 L7 イングレスから Application Gateway に切り替えると、AKS で使用されるコンピューティング負荷が直ちに減少します。

ノードあたり 22 ポッドを実行する簡単な Web アプリを使用し、3 つのノードの AKS クラスター上におけるクラスター内のイングレス コントローラーと Application Gateway イングレス コントローラーのパフォーマンスを比較しました。合計 66 個の Web アプリ ポッドによって、3 つのクラスター内のイングレス (ノードごとに 1 つずつ) とリソースが共有されました。インスタンス数を 2 に設定して、Application Gateway を構成しました。Apache Bench を使用し、コンカレンシーを 3,000 要求に設定して合計 100,000 要求を作成しました。Apache Bench を 2 回起動しました。1 回目は、クラスター内のイングレス コントローラーの隣接する SLB を指定し、2 回目は Application Gateway のパブリック IP に接続しました。この処理数の多い AKS クラスターで、要求全体の平均待ち時間を記録しました。

  • Application Gateway:要求あたり 480 ミリ秒
  • クラスター内のイングレス:要求あたり 710 ミリ秒

上で収集されたデータで実証されているように、負荷が大きい場合、クラスター内のイングレス コントローラーは、Application Gateway イングレスと比べて、要求あたりの待ち時間が約 48 % 長くなります。同じクラスターで同じベンチマークを実行する際、ノードごとに 2 個の Web アプリ ポッド (合計 6 ポッド) を使用すると、クラスター内のイングレス コントローラーのパフォーマンスで Application Gateway と比べて待ち時間が 17 % 長くなることが確認されました。

次のステップ

Application Gateway イングレス コントローラーでは、安定性が向上し、運用環境で使用できるようになりました。このプロジェクトは急速に熟成しており、Microsoft では新機能の追加に積極的に取り組んでいます。Microsoft は、Application Gateway、相互 TLS 認証、gRPC、HTTP/2 に格納されている証明書の使用など、お客様からご要望のあった機能を追加することにより、製品の向上に取り組んでいます。AKS 用の新しい Application Gateway イングレス コントローラーをお試しになり、進歩した機能をご確認ください。また最も重要なお願いですが、GitHub でフィードバックをお寄せください。