Kubernetes用のイングレスコントローラーの概要と比較

特定のアプリケーションに対してKubernetesクラスターを起動する場合、アプリケーション自体、ビジネス、および開発者がこのリソースに対してどのような要件を提示するかを理解する必要があります。 この情報があれば、アーキテクチャ上の決定を下すことができます。特に、特定のイングレスコントローラーを選択することができます。イングレスコントローラーの多くは今日すでに存在しています。 多くの記事/ドキュメントなどを勉強することなく利用可能なオプションの基本的なアイデアを得るために、メイン（生産準備完了）Ingressコントローラーを含めることでこのレビューを準備しました。



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

基準

原則として、比較を行い、有用な結果を得るためには、対象分野だけでなく、研究ベクトルを決定する基準の特定のリストも理解する必要があります。 Ingress / Kubernetesを使用する可能性のあるすべてのケースを分析するふりをせずに、コントローラーの最も一般的な要件を強調しようとしました-いずれの場合でも、すべての詳細および詳細を個別に調査する必要があることに注意してください。



しかし、すべてのソリューションで実装されており、考慮されていないほど馴染みのある特徴から始めます。

• サービスの動的発見（サービス発見）;
• SSL終了;
• Websocketで動作します。

次に比較ポイントについて：

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

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

ソフトウェアベース

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

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

特定のサービスへのトラフィックの方向について、何に基づいて判断できますか？ これは通常、ホストとパスですが、追加の機能があります。

クラスター名前空間

ネームスペース（ネームスペース）-Kubernetesでリソースを論理的に分割する機能（ステージ、プロダクションなど）。 各ネームスペースに個別に設定する必要があるIngressコントローラーがあります（そして、このスペースのポッドにのみトラフィックを誘導できます）。 また、クラスター全体でグローバルに機能する一部（およびその圧倒的多数）があります。これらのトラフィックは、名前空間に関係なく、クラスターの任意のポッドに向けられます。

アップストリームのサンプル

トラフィックはアプリケーション、サービスの正常なインスタンスにどのように送られますか？ アクティブおよびパッシブチェック、再試行、サーキットブレーカー（詳細については、たとえばIstioに関する記事を参照 ） 、カスタムヘルスチェックの実装などのオプションがあります。 アクセシビリティとバランスから失敗したサービスをタイムリーに撤回するための高い要件がある場合、非常に重要なパラメーター。

バランシングアルゴリズム

多くのオプションがあります：従来のラウンドロビンからrdp-cookiesのようなエキゾチックなもの、 そして スティッキーセッションのようないくつかの機能です。

認証

コントローラはどの認可スキームをサポートしていますか？ Basic、digest、oauth、external-auth-これらのオプションはおなじみのはずだと思います。 これは、Ingressを介してアクセスする開発者（および/または単に閉じたもの）に多くの回路を使用する場合の重要な基準です。

トラフィック分布

コントローラーは、カナリアのロールアウト、A / Bテスト、トラフィックのミラーリング（ミラーリング/シャドーイング）などのトラフィック分散によく使用されるメカニズムをサポートしていますか？ これは、生産的なテスト、戦闘中ではない（または最小限の損失で）製品エラーのデバッグ、トラフィック分析などのために正確で正確なトラフィック制御を必要とするアプリケーションにとっては本当に痛いテーマです。

有料サブスクリプション

高度な機能や技術サポートを備えたコントローラーの有料オプションはありますか？

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

コントローラーの構成を制御するためのグラフィカルインターフェイスはありますか？ 基本的に、「便利」および/またはIngressの設定を変更する必要がある人にとっては、「生の」テンプレートでの作業は不便です。 開発者がトラフィックを使用した実験をオンザフライで実行する場合に役立ちます。

JWT検証

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

構成のカスタマイズの機能

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

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

単純なレート制限アルゴリズム、またはアドレス、ホワイトリスト、国などに基づいてトラフィックをフィルタリングするためのより複雑なオプション

要求トレース

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

WAF

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

入力コントローラー

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

Kubernetesによるイングレス

ウェブサイト： github.com/kubernetes/ingress-nginx

ライセンス：Apache 2.0



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

NGINX Incによるイングレス

ウェブサイト： github.com/nginxinc/kubernetes-ingress

ライセンス：Apache 2.0



nginx開発者の公式製品。 NGINX Plusに基づいた有料版があります。 主なアイデアは、高レベルの安定性、一定の後方互換性、無関係なモジュールの欠如、およびLuaの拒否により達成された（公式コントローラーと比較した）宣言された速度の向上です。



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

Kong Ingress

ウェブサイト： github.com/Kong/kubernetes-ingress-controller

ライセンス：Apache 2.0



Kong Inc.が開発した製品 商用版と無料版の2つのバージョンがあります。 これはnginxに基づいており、その機能はLua上の多数のモジュールによって拡張されています。



当初は、APIリクエストの処理とルーティング、つまり API Gatewayに似ていますが、現時点では本格的なIngressコントローラーになっています。 主な利点：インストールと構成が簡単で、さまざまな追加機能が実装されている多くの追加モジュール（サードパーティの開発者を含む）。 ただし、組み込み機能はすでに多くの機能を提供しています。 作業構成は、CRDリソースを使用して行われます。



製品の重要な機能-クロスネームスペースの代わりに同じ回路内で動作することは議論の余地のあるトピックです。一部の人にとっては欠点（各回路のエンティティを作成する必要がある）と思われます。 1つのコントローラーが故障した場合、問題は1つの回路のみに限定されます。

トレフィク

ウェブサイト： github.com/containous/traefik

ライセンス：MIT



マイクロサービスとその動的環境に対する要求のルーティングを処理するために最初に作成されたプロキシ。 したがって、多くの便利な機能：再起動せずに構成を完全に更新し、多数のバランシングメソッド、Webインターフェイス、転送メトリックをサポートし、さまざまなプロトコル、REST API、カナリアリリースなどをサポートします。 また、すぐに使用できる証明書の暗号化もサポートされています。 欠点は、高可用性（HA）の組織では、コントローラーが独自のKVストレージをインストールして接続する必要があることです。

HAProxy

ウェブサイト： github.com/jcmoraisjr/haproxy-ingress

ライセンス：Apache 2.0



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

ボイジャー

ウェブサイト： github.com/appscode/voyager

ライセンス：Apache 2.0



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

輪郭

ウェブサイト： github.com/heptio/contour

ライセンス：Apache 2.0



Envoyはこのソリューションの基礎を築いただけでなく、この人気のあるプロキシの作成者と共同で開発されました。 重要な機能は、IngressRoute CRDリソースを使用してIngressリソース管理を分割する機能です。 単一のクラスターを使用する多くの開発チームを持つ組織の場合、これにより、近隣の回路のトラフィックの安全性を最大化し、イングレスリソースを変更する際のエラーから保護することができます。



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

イスティオイングレス

ウェブサイト： istio.io/docs/tasks/traffic-management/ingress

ライセンス：Apache 2.0



包括的なサービスメッシュソリューション。外部からの着信トラフィックを制御するだけでなく、クラスター内のすべてのトラフィックも制御する入力コントローラーです。 内部では、Envoyは各サービスのサイドカープロキシとして使用されます。 本質的に、これは「何でもできる」大規模な組み合わせであり、その主なアイデアは、最大限の管理性、拡張性、セキュリティ、および透明性です。 これにより、トラフィックのルーティング、サービス間のアクセスの許可、バランス、監視、カナリアリリースなどを微調整できます。 Istioシリーズの記事に戻るマイクロサービスに戻るで Istioの詳細を読んでください。

大使

ウェブサイト： github.com/datawire/ambassador

ライセンス：Apache 2.0



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

比較表

したがって、記事のクライマックスはこの巨大な表です。







より詳細に表示するにはクリックしてください。また、 Googleスプレッドシート形式でも利用できます。

まとめると

この記事の目的は、特定のケースでどのような選択を行うかについて、より完全な理解を提供することです（ただし、完全に網羅しているわけではありません！）。 いつものように、各コントローラーには長所と短所があります...



古典的なKubernetes Ingressは、そのアクセシビリティと実績に優れており、機能が非常に豊富です。一般に、「目を引く」必要があります。 ただし、安定性、機能レベル、および開発の要件が増加している場合は、NGINX Plusと有料サブスクリプションを使用したIngressに注意する価値があります。 Kongには豊富なプラグインセット（および、それに応じて提供する機能）があり、有料版にはさらに多くのプラグインがあります。 API Gateway、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のヒントとコツ：開発サイトへのアクセス 。