Kubernetes 用 Ingress コントローラーの概要と比較

特定のアプリケーション用に Kubernetes クラスターを起動するときは、アプリケーション自体、ビジネス、開発者がこのリソースに対してどのような影響を与えるかを理解する必要があります。 この情報を使用して、アーキテクチャの決定、特に、現在すでに多数の Ingress コントローラーが存在する特定の Ingress コントローラーの選択を開始できます。 多くの記事やドキュメントなどを参照することなく、利用可能なオプションの基本的な考え方を理解するために、主要な (実稼働対応の) Ingress コントローラーを含むこの概要を用意しました。

私たちは、これが同僚がアーキテクチャ ソリューションを選択する際に役立つことを願っています。少なくとも、より詳細な情報を取得し、実践的な実験を行うための出発点となるでしょう。 以前、私たちはネット上の他の同様の資料を調査しましたが、奇妙なことに、多かれ少なかれ完全で、最も重要なことである構造化されたレビューは見つかりませんでした。 なので、そのギャップを埋めていきましょう！

基準

原則として、比較を行って有用な結果を得るには、対象分野を理解するだけでなく、研究のベクトルを設定する基準の具体的なリストも用意する必要があります。 Ingress / Kubernetes の使用で考えられるすべてのケースを分析するつもりはありませんが、コントローラーの最も一般的な要件を強調しようとしました。いずれの場合も、すべての詳細と詳細を個別に検討する必要があることを覚悟してください。

ただし、あまりにもよく知られているため、すべてのソリューションに実装されているにもかかわらず考慮されていない特性から始めます。

• サービスの動的検出 (サービス検出)。
• SSL 終端。
• Webソケットを操作します。

次に比較ポイントについて説明します。

サポートされているプロトコル

基本的な選択基準の XNUMX つ。 ソフトウェアが標準の HTTP では動作しない場合や、複数のプロトコルを同時に動作させる必要がある場合があります。 ケースが標準的でない場合は、後でクラスターを再構成する必要がないように、この要素を必ず考慮してください。 すべてのコントローラーで、サポートされるプロトコルのリストは異なります。

核となるソフトウェア

コントローラーのベースとなるアプリケーションにはいくつかのバリエーションがあります。 人気のあるものは、nginx、traefik、haproxy、envoy です。 一般的なケースでは、トラフィックの送受信方法にはあまり影響しないかもしれませんが、「内部」にあるものの潜在的なニュアンスや機能を知ることは常に役立ちます。

トラフィックルーティング

特定のサービスへのトラフィックの方向を決定できるのは何ですか? 通常、これらはホストとパスですが、追加の可能性もあります。

クラスター内の名前空間

名前空間 (名前空間) - Kubernetes でリソースを論理的に分割する機能 (たとえば、ステージ上、本番環境など)。 各名前空間に個別にインストールする必要がある Ingress コントローラーがあります (トラフィックを誘導できます) のみ このスペースのポッドに)。 そして、クラスター全体に対してグローバルに動作するもの (およびその明らかに大部分) があり、それらのトラフィックは、名前空間に関係なく、クラスターの任意のポッドに送信されます。

上流向けサンプル

トラフィックはどのようにしてアプリケーションやサービスの正常なインスタンスに送信されるのでしょうか? アクティブおよびパッシブチェック、再試行、サーキットブレーカーのオプションがあります (詳細については、たとえば、次を参照してください。 Istio に関する記事)、ヘルス チェックの独自の実装 (カスタム ヘルス チェック) など。 可用性と、失敗したサービスをバランスからタイムリーに削除するための高い要件がある場合、非常に重要なパラメータです。

バランスアルゴリズム

多くのオプションがあります: 従来のものから ラウンドロビン エキゾチックなものに rdp-cookie、などの個別の機能だけでなく、 スティッキーセッション.

認証

コントローラはどのような認証スキームをサポートしていますか? Basic、digest、oauth、external-auth - これらのオプションはよく知られていると思います。 これは、Ingress を通じてアクセスされる開発者 (および/または単なるプライベート) ループが多数ある場合に重要な基準です。

トラフィックの分散

コントローラは、カナリア ロールアウト (カナリア)、A/B テスト、トラフィック ミラーリング (ミラーリング/シャドウイング) などの一般的に使用されるトラフィック分散メカニズムをサポートしていますか? これは、生産的なテスト、オフラインでの製品バグのデバッグ (または損失を最小限に抑えた)、トラフィック分析などのために、正確かつ正確なトラフィック管理を必要とするアプリケーションにとって、非常に厄介な問題です。

有料サブスクリプション

高度な機能や技術サポートを利用できるコントローラーの有料オプションはありますか?

グラフィカルユーザーインターフェース（Web UI）

コントローラー構成を管理するための GUI はありますか? 主に「手軽さ」や、Ingress の設定に何らかの変更を加える必要がある人向けですが、「生の」テンプレートを使用するのは不便です。 開発者がトラフィックをオンザフライで実験したい場合に便利です。

JWTの検証

エンドアプリケーションに対するユーザーの認可と検証のための JSON Web トークンの組み込み検証の存在。

構成のカスタマイズの可能性

テンプレートの拡張性とは、独自のディレクティブやフラグなどを標準構成テンプレートに追加できるメカニズムを備えているという意味です。

基本的な DDOS 保護メカニズム

シンプルなレート制限アルゴリズム、またはアドレス、ホワイトリスト、国などに基づくより複雑なトラフィック フィルタリング オプション。

リクエストトレース

Ingress から特定のサービス/ポッドへのリクエスト、そして理想的にはサービス/ポッド間のリクエストを監視、追跡、デバッグする機能。

WAF

サポート アプリケーションファイアウォール.

コントローラー

コントローラーのリストは、以下に基づいて作成されました。 Kubernetes の公式ドキュメント и このテーブル。 特異性または有病率が低い（開発の初期段階）ため、それらの一部をレビューから除外しました。 残りについては以下で説明します。 ソリューションの一般的な説明から始めて、概要表に進みましょう。

Kubernetes からの Ingress

ウェブサイト： github.com/kubernetes/ingress-nginx
ライセンス: Apache 2.0

これは Kubernetes の公式コントローラーであり、コミュニティによって開発されています。 名前から明らかなように、これは nginx に基づいており、追加機能の実装に使用される別の Lua プラグインのセットによって補完されています。 nginx 自体の人気と、コントローラーとして使用する場合の変更が最小限であるため、このオプションは平均的なエ​​ンジニア (Web 経験のある) にとって最も簡単で簡単に構成できる可能性があります。

NGINX Inc.によるIngress

ウェブサイト： github.com/nginxinc/kubernetes-ingress
ライセンス: Apache 2.0

nginx 開発者の公式製品。 に基づいた有料版があります NGINX プラス。 主なアイデアは、高レベルの安定性、継続的な下位互換性、無関係なモジュールの欠如、および Lua の拒否により達成される宣言された高速化 (公式コントローラーと比較して) です。

無料版は、公式コントローラーと比較した場合も含めて、大幅にコストが削減されています (同じ Lua モジュールがないため)。 同時に、有料のものには、リアルタイムメトリクス、JWT検証、アクティブヘルスチェックなど、かなり幅広い追加機能があります。 NGINX Ingress に対する重要な利点は、TCP / UDP トラフィックを完全にサポートしていることです (コミュニティ バージョンでも!)。 マイナス - 不在 ただし、トラフィック分散機能は「開発者にとって最優先事項」ですが、実装には時間がかかります。

コングイングレス

ウェブサイト： github.com/Kong/kubernetes-ingress-controller
ライセンス: Apache 2.0

コング社が開発した製品。 商用版と無料版の XNUMX つのバージョンがあります。 nginx をベースにしており、多数の Lua モジュールで拡張されています。

当初は、API リクエストの処理とルーティングに焦点を当てていました。 API ゲートウェイとして機能しますが、現時点では本格的な Ingress コントローラーになっています。 主な利点: インストールと設定が簡単な多くの追加モジュール (サードパーティ開発者によるモジュールを含む) があり、これを利用して幅広い追加機能が実装されます。 ただし、組み込み関数はすでに多くの可能性を提供しています。 ジョブの設定は CRD リソースを使用して行われます。

製品の重要な機能 - (名前空間をまたがるのではなく) 同じ輪郭内で作業することは物議を醸すトピックです。ある人にとってはそれが欠点のように見えます (輪郭ごとにエンティティを生成する必要があります) し、ある人にとってはそれが機能です ( bоより高いレベルの分離XNUMX つのコントローラーが壊れている場合、問題は回路のみに限定されます)。

トレフィク

ウェブサイト： github.com/containous/traefik
ライセンス: MIT

元々は、マイクロサービスとその動的環境のリクエスト ルーティングを処理するために作成されたプロキシ。 したがって、再起動をまったく行わずに構成を更新する、多数のバランス方法のサポート、Web インターフェイス、メトリクス転送、さまざまなプロトコルのサポート、REST API、カナリア リリースなど、多くの便利な機能が含まれています。 もう XNUMX つの優れた機能は、すぐに使用できる Let's Encrypt 証明書のサポートです。 欠点は、高可用性 (HA) を構成するために、コントローラーが独自の KV ストレージをインストールして接続する必要があることです。

ハプロキシ

ウェブサイト： github.com/jcmoraisjr/haproxy-ingress
ライセンス: Apache 2.0

HAProxy は、プロキシおよびトラフィック バランサーとして長い間知られてきました。 Kubernetes クラスターの一部として、「ソフト」構成更新 (トラフィックの損失なし)、DNS に基づくサービス検出、API を使用した動的構成を提供します。 CM を置き換えることによって構成テンプレートを完全にカスタマイズできること、およびその中で Sprig ライブラリ関数を使用できることは魅力的です。 一般に、このソリューションの主な重点は、高速性、その最適化、および消費されるリソースの効率化にあります。 このコントローラーの利点は、記録的な数のさまざまなバランス方法をサポートしていることです。

ボイジャー

ウェブサイト： github.com/appscode/voyager
ライセンス: Apache 2.0

HAproxy コントローラーをベースにしており、多数のプロバイダーの幅広い機能をサポートするユニバーサル ソリューションとして位置付けられています。 L7 と L4 のトラフィックをバランスさせる機会が提供され、全体として TCP L4 トラフィックのバランスをとることが、ソリューションの重要な機能の XNUMX つと言えます。

輪郭

ウェブサイト： github.com/heptio/contour
ライセンス: Apache 2.0

このソリューションは Envoy に基づいているだけではなく、によって開発されました。 一緒に この人気のあるプロキシの作成者と。 重要な機能は、IngressRoute CRD リソースを使用して Ingress リソースの制御を分離できることです。 同じクラスターを使用する多くの開発チームがいる組織にとって、これは、隣接するループでトラフィックを処理する際のセキュリティを最大化し、Ingress リソースを変更する際のエラーからチームを保護するのに役立ちます。

また、一連の拡張されたバランシング方法 (リクエストのミラーリング、自動繰り返し、リクエストのレート制限など)、トラフィック フローと障害の詳細な監視も提供します。 おそらく誰かにとっては、スティッキーセッションのサポートがないことが重大な欠点になるでしょう（ただし、作業は すでに進行中).

Istio Ingress

ウェブサイト： istio.io/docs/tasks/traffic-management/ingress
ライセンス: Apache 2.0

外部からの受信トラフィックを管理する Ingress コントローラーであるだけでなく、クラスター内のすべてのトラフィックも制御する包括的なサービス メッシュ ソリューション。 内部では、Envoy は各サービスのサイドカー プロキシとして使用されます。 本質的に、これは「何でもできる」大きなコンバインであり、その主な考え方は最大限の管理性、拡張性、セキュリティ、透明性です。 これを使用すると、トラフィック ルーティング、サービス間のアクセス認証、バランシング、モニタリング、カナリア リリースなどを微調整できます。 Istio について詳しくは、一連の記事をご覧ください。Istio によるマイクロサービスへの回帰'。

大使

ウェブサイト： github.com/datawire/ambassador
ライセンス: Apache 2.0

Envoy に基づく別のソリューション。 無料版と商用版があります。 これは「Kubernetes に完全にネイティブ」として位置付けられており、それに応じた利点 (K8s クラスターのメソッドおよびエンティティとの緊密な統合) をもたらします。

比較表

この記事の集大成は、次の巨大な表です。

クリックすると詳細を表示でき、次の形式でも利用できます。 Googleスプレッドシート.

まとめる

この記事の目的は、特定のケースでどのような選択をすべきかについて、より完全な理解を提供することです (ただし、決して網羅的なものではありません)。 いつものことですが、各コントローラーにはそれぞれ長所と短所があります…

Kubernetes の古典的な Ingress は、可用性と実績があり、機能が十分に豊富であるという点で優れています。一般的には、「見た目には十分」であるはずです。 ただし、安定性、機能、開発のレベルに対する要件が高まる場合は、NGINX Plus と有料サブスクリプションを備えた Ingress に注意を払う必要があります。 Kong には最も豊富なプラグイン セット (および、それに応じてプラグインが提供する機会) があり、有料バージョンではさらに多くのプラグインが提供されます。 API ゲートウェイ、CRD リソースに基づく動的構成、および基本的な Kubernetes サービスとして機能する機会が豊富にあります。

バランスと認証方法の要件が増加しているため、Traefik と HAProxy を検討してください。 これらはオープンソース プロジェクトであり、長年にわたって実績があり、非常に安定しており、活発に開発されています。 Contour はリリースされてから数年経ちますが、まだ見た目が若すぎて、Envoy に基本的な機能しか追加されていません。 アプリケーションの前に WAF の存在/埋め込みに関する要件がある場合は、Kubernetes または HAProxy からの同じ Ingress に注意を払う必要があります。

そして、機能の点で最も豊富なのは、Envoy、特に Istio 上に構築された製品です。 「何でもできる」包括的なソリューションのように見えますが、構成/起動/管理の敷居が他のソリューションに比べて非常に高いことも意味します。

私たちは、ニーズの 80 ～ 90% をカバーする標準コントローラーとして、Kubernetes の Ingress を選択し、現在も使用しています。 非常に信頼性が高く、構成と拡張が簡単です。 一般に、特定の要件がなければ、ほとんどのクラスター/アプリケーションに適合します。 同じ汎用的で比較的シンプルな製品では、Traefik と HAProxy が推奨できます。

PS

私たちのブログもお読みください:

• 「Istio でマイクロサービスに戻る」: パート 1 (主な機能の紹介), パート 2 (ルーティング、トラフィック制御), パート 3 (認証と認可);
• «Kubernetes のヒントとテクニック: NGINX Ingress のカスタム エラー ページ";
• «Kubernetes のヒントとテクニック: 開発サイトへのアクセス'。

出所： habr.com