Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル

編集者– この投稿は10 部構成のシリーズの一部です。

1. プロダクショングレードのKubernetesで複雑さを軽減
2. 高度なトラフィック管理で Kubernetes の回復力を向上させる方法
3. Kubernetes の可視性を向上させる方法
4. トラフィック管理ツールを使用して Kubernetes を保護する 6 つの方法
5. Ingress コントローラーの選択ガイド、パート 1: 要件を特定する
6. Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え
7. Ingress コントローラーの選択ガイド、パート 3: オープンソース vs. デフォルト vs. コマーシャル（この投稿）
8. Ingress コントローラーの選択ガイド、パート 4: NGINX Ingress コントローラー オプション
9. サービスメッシュの選択方法
10. 動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト

また、ブログの完全セットを無料の電子書籍「 Taking Kubernetes from Test to Production」としてダウンロードすることもできます。

おめでとう！ Ingress コントローラーの選択ガイドの最初の 2 つの部分を読んだら、コントローラーを選択する準備がほぼ整います。 これまでの経緯を振り返ってみましょう:

• パート 1では、パフォーマンス、予算、ユースケース、アーキテクチャ、所有権などの要件を特定する方法について説明します。
• パート 2では、間違った Ingress コントローラを選択することで発生する可能性のあるリスクについて説明し、将来を見据えた選択を行うための重要な領域について説明します。

Ingress コントローラーは、オープン ソース、デフォルト、商用の 3 つのカテゴリに分類されます。 それぞれに使用例があり、選択する前に短期的および長期的なニーズを明確にすることが重要です。 このブログでは、各カテゴリーの長所と短所について説明します。

オープンソースのイングレス コントローラ

多くのオープンソース Ingress コントローラーは、ユーザーとボランティア開発者のコミュニティによって保守されていますが、専用のエンジニアリング チームを持つコントローラーもあります。 最も人気のあるオープンソース Ingress コントローラーのうち 2 つは NGINX をベースにしています。1 つは Kubernetes コミュニティによって保守されており、もう 1 つはコア NGINX エンジニアリング チームが主導してオープンソース化されています。 NGINXベースのIngressコントローラのさらなる比較については、パート4を参照してください。私たちのシリーズの。

• 長所:
  • 無料かつコミュニティ主導– 多くの人や組織がオープンソース プロジェクトを選択するのは、価格が圧倒的に安い (無料!) からという理由だけでなく、コミュニティで開発された技術を好むからです。
  • 機能の速度– これらの Ingress コントローラーは、機能の革新の最先端にいる可能性が高くなります。
• 短所（オープンソース プロジェクト全般に共通） :
  • コスト (時間) - 簡単にセットアップして拡張できる「すぐに使える」ツールがないため、特定のニーズに合わせたカスタマイズや回避策に時間を費やすことになります。
  • リスクあり– 安定性、セキュリティ、信頼性に問題が生じる可能性があります (機能の速度を重視し、貢献者がボランティアであるため)。 共通脆弱性識別子 (CVE) のパッチは、決して提供されないか、CVE が公開されてから数か月後に提供される可能性があり、ハッカーに Ingress コントローラーを攻撃する十分な時間を与えることになります。
  • サポートは最小限、またはまったくありません。ほとんどは「自己解決」です。あなたとドキュメントだけです。 自分で解決できない問題に遭遇した場合、助けを得るのは困難 (または不可能) です。唯一の選択肢は、コミュニティ フォーラムに問題を投稿し、コミュニティの他のメンバーが (a) 応答し、(b) 解決策を知っていることを期待することです。
• まとめ： 組織が初めて Kubernetes の実験を開始するときは、利便性のため、またはドキュメントで無料ですぐに起動して実行できることが約束されているため、オープンソースの Ingress コントローラーを選択することがよくあります。 これは、開始時、テスト時、または少量生産の実行時に非常に効果的です。

デフォルトのイングレス コントローラ

デフォルトの Ingress コントローラーの多くはオープンソース テクノロジに基づいていますが、完全な Kubernetes プラットフォーム (多くの場合、その管理サポートも) を提供する企業によって開発および保守されているため、別々に分類しています。 このカテゴリの例には、パブリック クラウド Ingress コントローラー、Rancher、Red Hat OpenShift ルーターなどがあります。

• 長所:
  • 無料または低コスト- 低価格はこれらの製品を使用する説得力のある理由です。 これらはすでにプラットフォームに統合されているため、初めて使用する場合、確実に時間を節約できます。
  • 信頼性が高く、サポートされています- 専任のエンジニアリング チームによって保守されているため、コミュニティによって保守される Ingress コントローラーよりも信頼性が高い可能性があります。 通常、商用サポートは含まれているか、追加料金で利用できます。
• 短所:
  • インフラストラクチャのロックイン- デフォルトのイングレス コントローラはインフラストラクチャに依存しないため、それらや構成をクラウド間で移行することはできません。 つまり、デプロイメント環境ごとに異なる Ingress コントローラーが必要になるため、ツールが乱立し、チームの学習曲線が長くなり、Ingress コントローラーのセキュリティ保護が難しくなります。
  • 基本機能- 通常、大規模な展開に必要な高度なトラフィック管理機能とセキュリティ機能が欠けています。
  • 予測不可能なコスト (時間とお金) - 初期コストはゼロか低いですが、アプリケーションの拡大に伴って大幅に予測不能に増加する可能性があります。 これは、Ingress コントローラーの最小限の機能セットに欠けている機能をアプリに組み込むために必要な時間という形で表れることがあります。そしてもちろん、アプリを更新するたびにその機能を回帰テストする必要があります。一部のデフォルト ツールのもう 1 つの欠点は、最初は無害に見えるスループット料金が原因で、アプリの人気が高まるにつれてクラウド料金が大幅に上昇することです。
• まとめ： デフォルトの Ingress コントローラーは、Kubernetes を初めて使用し、Amazon Elastic Kubernetes Service (EKS)、 Google Kubernetes Engine (GKE)、Microsoft Azure Kubernetes Service (AKS)、 Rancher 、 Red Hat OpenShift Container Platformなどのマネージド プラットフォームを使用しているチームによく選ばれています。 アプリが成熟し、チームが拡大するにつれて、組織はデフォルトのツールを置き換えるのではなく、エンタープライズ グレードの Ingress コントローラーをスタックに追加することを選択することがよくあります。

商用イングレスコントローラ

これらの Ingress コントローラは、大規模な本番環境の展開をサポートするように設計されたライセンス製品です。 一例として、 NGINX Plus ベースのF5 NGINX Ingress Controllerバージョンが挙げられます。これについては、パート 4 で詳しく説明します。

• 長所:
  • 大規模な機能セット- 商用 Ingress コントローラには、大規模な展開のための高度なトラフィック管理とスケーラビリティをサポートする強力な機能セットが含まれています。 WAF やサービス メッシュなど、他の本番環境レベルの製品との統合が行われる場合もあります。
  • スケーラブル– カスタマイズや回避策を必要としない「すぐに使える」機能を備えている傾向があるため、組織ではこれらのオプションが時間の節約になると考えることが多いです。 自動化パイプラインに簡単に追加できるため、必要に応じてインフラストラクチャを拡張できます。
  • 信頼性とサポート– 商用製品の主な利点の 1 つは、安定していることです。つまり、リリースごとに徹底的にテストされ、必要に応じて定期的なソフトウェア更新とセキュリティ パッチが提供されます。 通常、完全な商用サポートはさまざまなレベルで提供されるため、重大な問題が発生してから数分または数時間以内に機密性の高いサポートを受けることができます。
• 短所:
  • 開発が遅い– 商用の Ingress コントローラーでは安定性が重要なため、機能の速度はオープンソースのコントローラーに比べて少し遅れる可能性があります。
  • コスト (お金) - 商用製品にはお金がかかるというのが現実です。 現金よりも開発サイクルが多い組織の場合、状況が変化するまでコストが取引の障害となる可能性があります。
• まとめ： 組織の規模が大きくなるにつれて、チームとアプリの複雑さに基づいて Ingress コントローラーの選択がより重要になります。 組織が高度な複雑さに達すると、管理の複雑さを軽減し、新しい製品機能の市場投入までの時間を短縮できるため、商用 Ingress コントローラーが適しています。

次のステップ: オプションを評価する

旅のこの段階では、ニーズを満たせないオプションを排除して、試す Ingress コントローラーをいくつか絞り込む準備ができています。 高レベルの機能比較を始めるのに最適な場所の 1 つはlearnk8sです。これは、評価した Ingress コントローラーの無料比較表を提供しています。

Ingress コントローラーを調べていくと、多くのオプションが NGINX に基づいていることに気付くでしょう。NGINX ベースの選択肢の概要については、このシリーズの最後のブログ「Ingress コントローラーの選択ガイド、パート 4」をご覧ください。 NGINX Ingress コントローラー オプションは近日公開予定です。