Comparing Ingress controllers for Kubernetes（ Part 1 )
KubernetesのためのIngress controllersの比較 第一章
Kubernetesのための色々なIngress controllersを比較しました。今回は第一回目です。二回に分けて投稿します。
Kubernetesクラスターを特定のアプリケーションにデプロイする場合、アプリケーションそれ自体、ビジネス面、また開発者からの要望を理解する必要があります。こういう要望を理解した上で、アーキテクチャーの選択をし、K8sに適切なIngress controllerを選ぶことになります。私たちは、市場で何が有効なのかというヒントになればと思いこの記事を書きました。そして、すべての注目すべき、生産準備の整ったIngress controllersについて言及しているので、ご自身の研究時間を節約できます。-少なくとも、ご自身で実際に研究する際のきっかけになればと思います。
Criteria
判断基準についてです。より高い基準で比較するために、そして役に立つ結果を得るために、主題をよく理解してください。しかし、それだけではありません。リサーチのベクトルを設定する特定の一連の判断基準も必要です。Kubernetes Ingress/API gateways/Service Meshのユースケース全てを分析するふりをするのではなく、controllerのための最も一般的な必要条件を見つけ出そうとしているのです。それぞれのケースで成功するには、各ケースの詳細と特殊性をすべて検討する必要があります。
ソリューションすべての中で既に実装されているとても一般的な機能からスタートしましょう。
- オープンソース （K8s スタックのこのレベルでの他のオプションはありません);
- ダイナミックなサービスディスカバリー;
- SSL ターミネーション;
- WebSocketsへの対応
は考慮されません。
それでは、比較に入りましょう。
Supported protocols
対応しているプロトコルについてです。これはご自身が選択する上で、基本的なパラメータです。通常のHTTPプロキシは自分のソフトウェアに合っていますか？もしくは、gRPCやHTTP/2.0を通して機能していますか？TCP（SNIを伴う）、もしくはUDPも必要ですか？ケースが非標準の場合は、後でクラスターを再構成する必要がないように、徹底的に検討をするようにしてください。 各controllerには、対応するプロトコルの独自のセットがあります。
Based on (underlying software)
基本的なソフトウェアについてです。
controllerのコアにあるアプリケーションにはいくつかのタイプが存在します。人気なのは、NGINX, Traefik, HAProxy, Envoyです。一般的なケースでは、この選択肢が、どのようにトラフィックが加工されるかに大きく影響を及ぼすことはありません。ただ、潜在的な機能を知り、詳しい中身を知ることはどんな時でも役に立つので、知っておくと損にはなりません。
Traffic routing
トラフィックルーティングについてです。
特定のサービスへのトラフィックのルーティングに関することを決める場合の根拠は何ですか？ 通常、ホストとパスを使用できますが、追加の可能性もあります。 これらの値の一致は、RegEx（正規表現）にも対応していますか？
Namespace limitations
ネームスペース制限についてです。ネームスペースはKubernetes上（例えば、自分のプロダクション感、ステージングなど）の論理的にリソースを別々にする方法を提供してくれます。それぞれのネームスペースに別々に（それらは、ネームスペースに属するポッドへのトラフィックのみを許可します）インストールされるべきIngress controllersが存在します。そして、全体のクラスターのためにグローバルに運用するもの（実際には、過半数）このケースでは、トラフィックはネームスペースに関係なく、どのポッドにでも行くことができます。
Upstream probes
アップストリームプローブについてです。どのようにトラフィックをアプリケーションのヘルシーなインスタンスに誘導しますか？そのサービスですか？アクティブチェック、パッシブチェック、リトライ、サーキットブレーカー、カスタムヘルスチェックなどのソリューションがあります。可用性性に厳しい要件があり、障害が発生したサービスをロードバランスから迅速に削除する場合、これは非常に重要なパラメーターになります。
Load balancing algorithms
ロードバランスアルゴリズムについてです。こちらに関してはたくさんの選択肢があります。従来のround-robin（ラウンド・ロビン）からより 、少し趣向の違う rdp-cookieのようなものまであります。Sticky sessions（スティッキーセッション）はこの分野ではとても一般的なものです。
Authentication
Authentication（認証）についてです。controllerはどの認証スキームに対応しているのでしょうか？ベーシック、ダイジェスト、OAuth、外部認証…など、もうみなさんもご存じだと思います。多くの環境（ティアー）をデベロッパーやIngressを通してアクセスされる単純なプライベートティアーを使っている場合、これは重要なパラメータになります。
Traffic distribution
トラフィックのディストリビューション（割り当て）についてです。controllerはカナリアデプロイメント、A/Bテスト、ミラーリング/シャドーイングのようなトラフィックのディストリビューション（割り当て）のよく使用されるメカニズムに対応していますか？これは意味のあるテストや、最低限の影響を伴うプロダクションエラーのデバッグ、トラフィック分析などの正確なトラフィックマネジメントが必要なアプリケーションにとっては、とても繊細な問題です。
Paid subscription
有料サービスについてです。拡張機能やテクニカルサポートのついているバージョンの有料のcontrollerのサービスはありますか？
Graphical user interface (Web UI)
グラフィカルユーザーインターフェースについてです。controllerコンフィグレーションに対してのグラフィカルインターフェースはありますか？便利さを追求する人や、「未加工の」テンプレートを使用しないようにIngressの設定を変更する必要がある場合にはとても重要なことです。「事前の準備なくその場で」トラフィックの実験をしたいデベロッパーにもとても便利です。
JWT validation
JWTのバリデーションについてです。認証とユーザーのエンドアプリケーションへのバリデーションのためのJSON Webトークンのビルドインバリデーションはあるでしょうか？
Customization of configuration
コンフィグレーションのカスタマイズについてです。自分のディレクティブ、フラグなどをスタンダードなコンフィグレーションテンプレートに追加できるようにするメカニズムを持つというようなテンプレートの拡張性。
Basic DDOS protection mechanisms
基本的なDDOS防御メカニズムについてです。
基本的なrate limitアルゴリズム、もしくはアドレス、whitelists、コンテナなどをベースにしたトラフィックフィルターのもっと洗練されたvariantsなど。
Requests tracing
リクエストのトレーシングについてです。
オープントレーシングや他のものを通しての、モニター、トレース、Ingressからの特定のサービス/ポッド（そして理想としては、サービスとポッド間）へのデバッグリクエストをする機能。
WAF
ウェブアプリケーション ファイヤーウォールに対応しています。
Ingress Controllers
Ingresscontrollerについてです。controllerのリストは公式の Kubernetes ドキュメンテーションから始まりました。 そして、その他の有名なオプションと共に拡張していきました。しかし、それらのうちのいくつかはある機能や、人気の低さ、そしてまだまだ開発が進んでいない事が原因で外されました。残ったものがテストされました。まずは概要から初めて、最後にまとめをしたいと思います。
Kubernetes Ingress Controller
- github.com/kubernetes/ingress-nginx
- Go/Lua (nginx は Cで書かれる)で実装
- ライセンス: Apache 2.0
「公式な」Kubernetes controllerです（NGINXのものと間違わないようにこう呼んでいます）。コミュニティが開発しました。その名前からも分かるように、nginxウェブサーバーをベースにしていて、その他の機能を実行するために使われるLuaプラグインのセットを補っています。
NGINXや有名であることと、controllerとして使う場合の少しの修正で大丈夫であったというおかげで、K8sを扱う一般的なエンジニアにとって最もシンプルで明確なオプションとなります。
NGINX Ingress Controller
- github.com/nginxinc/kubernetes-ingress
- Go/Python で実装
- ライセンス: Apache 2.0
これはNGINXの開発者が開発した公式な製品で、 NGINX Plusをベースにした商用バージョンもあります。NGINX controllerは高い安定性を保ち、継続的なbackward compatibility（旧製品との互換性）もあり、サードパーティーのモジュールなしという特徴もあります。Luaコードがないために、ハイスピード（公式のcontrollerと比較しても）であることも実現できています。
フリーウェアバージョンはものすごく制限があり、公式なcontrollerと比較しても制限があります(上記のLuaモジュールがないため)。それと同時に、有料バージョンはかなり多くの追加機能があります。リアルタイムメトリック、JWTバリデーション、アクティブなヘルスチェックなどです。NGINXIngressの重要なメリットはTCP/UDP-トラフィックに完全に対応していること（そしてコミュニティバージョンにも対応しています！）です。そして主なデメリットは、トラフィックの割り当ての不足していることです。この作業は、まだまだ進行中のよう ですが。
Kong Ingress
- github.com/Kong/kubernetes-ingress-controller
- Go で実装
- ライセンス: Apache 2.0
KongIngressは、Kong Incが開発し、2つのバージョンがあります。商用ものと無料のものです。KongIngressはNGINXで構築され、機能を拡張したLuaモジュールを追加しています。
当初、APIリクエストのルーティングとプロセスにフォーカスされていて、 APIゲートウェイとして機能していました。しかし、今では本格的なIngresscontrollerとして機能しています。その主なメリットは、かなりたくさんの追加モジュール/プラグイン（サードパーティーデベロッパーからのものを含む）です。それらはインストールとコンフィグレーションが簡単です。その他の幅広い追加機能への突破口となりました。ちなみに、そのビルドイン機能は既に、たくさんの可能性を秘めています。コンフィグレーションはCRDを使って運用されます。
Kongの重要な機能は、一つの環境のみで実行できるというところです（クロスネームスペースをサポートする代わりに）。実はこれは物議をかもしているトピックです。ある人は、この機能がデメリット（それぞれの環境でインスタンスを生成しないといけない）という人もいれば、特別な機能である（より高いレベルで独立しており、一つのcontrollerへの不具合という影響がその環境で制限される）という人もいるのです。
Traefik
- github.com/containous/traefik
- Go 上で実装
- ライセンス: MIT
元々は、そのプロキシはマイクロサービスと、そのダイナミックな環境、のためのリクエストのルーティングのために生成されたので、その役に立つ機能の多くは、コンフィグレーションの継続的なアップデート（再スタートなし）、たくさんのロードバランスアルゴリズムへの対応、ウェブUI、メトリックエクスポート、色々なプロトコルへの対応、REST API、カナリアのリリースなどです。すぐに使えるLet’s Encrypt証明書のサポートもとてもいい機能です。主なデメリットは、それ自身のKV-storageにインストールし接続しないといけないcontrollerの高可用性を整理しないとけない点です。
多くの優れた新しい機能（SNIを伴ったTCP/SSL、カナリアデプロイメントやトラフィックミラーリング/シャドーイング、改良されたWeb UI)が新しくリリースされる（9月19日にリリース） Traefik v2.0 が付いています。他の機能（WAF サポートのような機能）はまだ議論中です。
9月1９日に、同じデベロッパーが開発した他のサービスメッシュソリューションが登場しました。 Maeshという名前のもので、Traefik上に構築できます。
HAProxy Ingress
- github.com/jcmoraisjr/haproxy-ingress
- Go (HAProxyは Cで書かれる)上で実装
- ライセンス: Apache 2.0
HAProxyは、プロキシサーバーやロードバランサーとして有名です。Kubernetesクラスターの一部として、「ソフトな」コンフィグレーションのアップデート(トラフィックのロスなしで)、DNSベースのサービス検出、APIを通してのダイナミックなコンフィグレーションを実現します。HAProxyはまた、完全なコンフィグファイル テンプレート（コンフィグマップの置き換えを通して）をカスタマイズに対応しており、Spring Boot機能も使います。一般的には、デベロッパーたちは高速である点、最適化、使われたリソース上の効率などを強調しています。HAProxyのメリットの一つには、数多くのバランスアルゴリズムがあります。
最近リリースされたv2.0 releaseにはたくさんの新しい機能がついています。そして、今後登場するv2.1にももっと多くの機能（OpenTracingサポートなど）が搭載されていることが期待されています。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
