Comparing Ingress controllers for Kubernetes（ Part 2 )
KubernetesのためのIngress controllerの比較 — (第二章)
Kubernetesのための色々なIngress controllersを比較しました。今回は第2回目で、最終章となります。最後に分かりやすくまとめた表もあるので、ぜひ参照ください。
Voyager
- github.com/appscode/voyager
- Go で実行
- ライセンス: Apache 2.0
While full HTTP/2 and gRPC protocols support has appeared earlier this year (with v9.0.0 release), the support for cert-manage (for Let’s Encrypt certificates) might be the latest prominent feature integrated in Voyager since then.
フルのHTTP/2とgRPCプロトコルサポートが今年の初めに出ました（v9.0.0 のリリースと一緒に）。cert-manage（Let’s Encrypt証明書）へのサポートも最新の機能としてそれ以降Voyagerに統合されています。
Contour
- github.com/heptio/contour
- Goで実装
- ライセンス: Apache 2.0
ContourはEnvoyがベースになっているだけではなく、この人気のプロキシの製作者と共同で開発されました。その機能は、Ingressリリースを特別なCRD (IngressRouteと呼ばれる新しいAPI)を通して管理できるものです。現在一つのクラスターを使うたくさんの開発チームを持つ組織にとって、これは近隣環境におけるセキュアなトラフィックにも役に立ち、Ingressリソースに変化がおきた場合にもエラーから守ってくれる便利なものです。
また、拡張されたバランシングアルゴリズム(ミラーリング、オートリピート、リクエスト率の制限などその他多数)、トラフィックフローと失敗の詳細なモニタリングという機能もあります。おそらく、スティッキーセッションへのサポート不足は重大な欠陥になります（このディレクションについての努力はずっと長い間されてきています）。
Istio Ingress
- istio.io/docs/tasks/traffic-management/ingress
- Goで実装
- ライセンス: Apache 2.0
IstioはIBM, Google, Lyft（Envoyの元々の開発者）のジョイントプロジェクトとして生成されました。Istioは包括的なサービスメッシュソリューションです。すべてのincoming outsideトラフィック(Ingresscontrollerとして)だけを管理するではなく、クラスター内の全てのトラフィックをコントロールます。内部では、IstioはEnvoyをそれぞれのサービスに対するsidecar-proxyとして使用しています。その結果、ほとんど全てのことができる大きなプロセッサーとなるのです。その主考え方は、最大のコントロール、拡張性、セキュリティ、透明性を基調としています。
IstioIngressを使って、トラフィックルーティング、サービス間のアクセス許可、バランシング、モニタリング、カナリアリリースなどを微調整できます。
“Back to microservices with Istio”の記事にはIstioに関する具体的な内容が書かれています。
Ambassador
- github.com/datawire/ambassador
- Pythonで実装
- ライセンス: Apache 2.0
Ambassadorはもう一つのEnvoyベースのソリューションです。無料と商用バージョンの２つのバージョンがあります。Ambassadorは«マイクロサービスためのKubernetesネイティブ API ゲートウェイ»と言われていて、色々なメリットがあります。K8のプリミティブを伴ったタイトな統合などがそうです。Ingress controllerに期待する色々な機能があれば、他のサービスメッシュソリューション（Consul, Linkerd, Istio）とも使用できます。
話は変わりますが、Ambassadorのエンジニアたちが最近Envoy（Ambassador Proのようなもの）、HAProxy 、NGINX（コミュニティからの公式なのKubernetesIngressのようなもの）パフォーマンスの比較するベンチマークの結果を出版しました。
Gloo
- github.com/solo-io/gloo
- Goで実装
- ライセンス: Apache 2.0
Glooは新しいソフトウェア（5月18日に発表されました）で、Envoyに構築されます。「機能ゲートウェイ」と言われていますが、その理由は、開発者が「ゲートウェイはAPIをサービスよりも機能から構築すべき」だと考えているからです。「機能レベルのルーティング」というのは、マイクロサービス、サーバーレス機能、レガシーアプリとして実装されたバックエンドを伴ったハイブリットアプリのためにトラフィックをルーティングするために使用できるという意味です。
接続可能なアーキテクチャーを使って、Glooはあなたが着たいするほぼすべての特徴を持ち合わせています。しかし、それらのうちのいくつかは、商用バージョン（Gloo Enterprise）でのみ使用可能です。Linkerd や Istioなどのサービスメッシュと統合するのがとても簡単です。
Skipper
- github.com/zalando/skipper
- Goで実装
- ライセンス: Apache 2.0
Skipperは HTTPルーターでリバースプロキシです。多くのプロトコル（例えば、gRPCを追加をする予定はなさそうです）には対応していません。技術的には、ポッドへのトラフィックをルートするためにエンドポイントAPI（Kubernetesサービスの代わり）を使っています。その大きなメリットは、あらゆる種類のHTTPデータを生成、アップデート、削除できる豊富なフィルタ―のセットを通した高度なHTTPルーティング機能です。Skipperのルーティングルールは休止時間なくアップデートされます。Skipperの開発者は、「Skipperは、（他のIngressソリューションと比較すると）Skippeにない機能を持つAWS ELBのような他のソリューションとも相性がいい」と述べています。
開発者（Zalando）によって作成されたSkipperと他のKubernetesIngresscontrollersとの比較がこちらにあります。
Other notes
その他のものについてです。TraefikやIstioについては言及したので、Linkerdという人気の高い他のサービスメッシュソリューションについては記述がないことに気づかれた方もいると思います。なぜ掲載しなかったかたという理由をこちらに載せています。
簡単に言えば、Linkerdは自身のIngress controllersを持っていないからです。その代わりLinkerdは選りすぐりのIngresscontrollersと共に機能するように設計されています。
Comparison table
比較した表
こちらに今までのものをまとめたものがこちらの表です：
もっと詳しいレビューはクリックしてもらえると読めます。この表は Google Sheetsフォーマットでも利用可能です。
まとめ
この記事を書いた目的は、それぞれのケースでどういうことができるかということについてもっと理解を深めたかった（といっても完全には網羅できていませんが）からです。それぞれのcontrollersには長所も短所もあります。
公式なKubernetesIngressは簡単に使用でき、開発も進んでいて、ほとんどの場合に対応できる十分な機能を持ち合わせています。高い信頼性と機能の実行性の質を望むのであれば、IngressベースのNGINX Plusの商業バージョンも試してみてください。Kongは最も豊富なプラグインを持ち合わせていて（そしてそのプラグインを提供する機会も多い）、商業バージョンよりももっと多くのプラグインが使用でき、またカスタムリソースをベースとしたダイナミックなコンフィグレーションもあります。
もし、メソッドのバランスと承認が必要であれば、TraefikやHAProxyもいいでしょう。これらはオープンソースプロジェクトで、何年もその実績が認められており、とても安定してアクティブな進化を見せています。
Contourはリリースされて数年ですが、Envoyで構築される基本的な機能のほとんどを持ち合わせています。アプリケーションの前にWAFが必要な場合は、KubernetesまたはHAProxyによる同じ古いIngressに注目してみてください。
Envoyベースの商品は、最もたくさんの機能（特にIstio）を持っています。「ほぼ何でもできる」という複雑なソリューションです。ちなみに、コンフィグレーション、実装、運用するために、より幅広い関連した経験が必要だということを意味しています。他のケース(Gloo)では、その多くの機能は有料バージョンでのみ利用可能となっています。Skipperは、もし自分のアプリケーションが進化した、もしくはより頻繁に変更するHTTPルーティングテーブルが必要な場合には、優れたソリューションになるでしょう。
世界規模のK8sコミュニティが今注目しているものと言えば、IstioとTraefikです。「公式の」KubernetesIngressは、GitHub スター（対応する6000未満に対して25000以上およびほぼ20000）と比べると明らかに流行遅れです。KongIngressと
HAProxyIngressはその反対で、星の数が一番少ないです（1000未満）。
Flantでは、「公式な」KubernetesIngressをスタンダードcontrollersとして選び、今でも使っています。これは80～90％のニーズに対応しています。KubernetesIngressは信頼性が非常に高く、簡単にコンフィギュアでき、拡張性もあります。特定の要望がない場合、大部分のクラスター/アプリケーションとの相性もよいです。Traefik, HAProxyもおすすめの一般的で信頼性の高いシンプルなソリューションです。
その他のおすすめの記事/レビュー
Ingressソリューションを選ぶ際に役立つ他の記事です：
- 『kubedexのIngress』 －分かりやすいNGINX Ingress, Kong, Traefik, HAProxy, Voyager, Contour, Ambassador, Istio Ingress, Gloo Soloを比較した表が載っています（自分たちが実際に選ぶ際にもこの表を参考にしました）
- Layer5による『Service Mesh Landscape』 ―サービスメッシュのたくさんの（約30ほど）選択肢（表が載っています）が多くのパラメータで比較されています。対応するプロトコル、マルチクラスター、マルチテナント機能、Prometheusやトレーシング統合などの観点でも比較されています。
- TFiRによる『自分のKubernetes環境に最適なIngresscontrollersは何？』 (5月19日) ―NGINX Ingressの（コミュニティとNGINX Incの両者から）、Envoy, Kong, Google Cloud and AWS solutions, Citrix Ingressの比較。
- Cayent による『Kubernetes のIngress比較』 (9月’19日) ―Kong, Traefik, HAProxy, Istio Ingress, Nginx, and Ambassadorを短い文章で比較しています。
- ITNEXT による『Kubernetes Ingress Controllers: 最適なものを選ぶ方法: Part 1』－ Nginx Ingress controllersとWS ALB Ingress Controllerを深く掘り下げて比較しています。
Orangesys.ioでは、kuberneteの運用、DevOps、監視のお手伝いをさせていただいています。ぜひ私たちにおまかせください。
