この記事は10部構成の一部です。
- Reduce Complexity with Production-Grade Kubernetes（英語）
- 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法
- Kubernetesの可視性を向上させる方法
- トラフィック管理ツールを使ってKubernetesを安全にする6つの方法
- Ingress Controllerの選択ガイド, Part 1: 要件の特定
- Ingress Controllerの選択ガイド, Part 2 : リスクと将来性
- Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版（この記事です）
- Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
- サービスメッシュの選び方
- Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）
これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。– Kubernetes のテスト環境から本番環境への移行
Ingress controllerの選び方ガイドの最初の2つのパートをすでに読んでいただいた方は、必要なものを選ぶ準備ができてきていることと思います。
- パート1では、性能、予算、ユースケース、アーキテクチャ、ツールの管理など、必要となる要件を明確にする方法について説明しました。
- パート2では、誤ったIngress Controllerを選択することで生じる可能性のあるリスクについて説明し、その選択が将来にわたって保証されたものとなる主な要素について説明しました。
Ingress Controllerはオープンソース、デフォルト、商用の3つのカテゴリに分類されます。それぞれにユースケースがあり、短期的、長期的なニーズを明確にした上で選択することが重要になります。このブログでは、それぞれのカテゴリの長所と短所を取り上げます。
オープンソースIngress Controller
オープンソースのIngress Controllerの多くは、ユーザーやボランティアの開発者のコミュニティによってメンテナンスされていますが、中には専門のエンジニアリングチームを持っているものもあります。最も人気のあるオープンソースのIngress Controllerの2つはNGINXをベースにしています。1つはKubernetesコミュニティによってメンテナンスされ、もう1つはNGINXのコアエンジニアリングチームが主導してオープンソース化されたものです。NGINXベースのIngress Controllerのさらなる比較については、本連載の第4回をご覧ください。
- メリット
- 無料とコミュニティ主導 – 多くの人々や組織がオープンソースプロジェクトを選ぶ理由は、破格の値段（無料！）だけでなく、コミュニティが開発した技術を好むからです。
- 機能開発の速さ – これらの Ingress Controllerは、機能革新の最先端にある可能性が高いです。
- デメリット(オープンソースプロジェクト全般と共通）
- コスト（時間） – セットアップやスケーラビリティを簡単にするための「すぐに使える」ツールがないため、結局は特定のニーズに合わせたカスタマイズや回避策に時間を費やすことになります。
- リスク – 安定性、セキュリティ、信頼性に問題がある可能性があります（機能の速さに重点を置いていることと、貢献者がボランティアであることが原因）。Common Vulnerabilities and Exposures (CVEs)のパッチが来ないかもしれないし、CVEが公開されてから何ヶ月も経ってから来るかもしれないので、ハッカーにあなたのIngress Controllerを攻撃する時間をたっぷり与えてしまいます。
- 最小限のサポート、もしくはサポートがない – 多くの問題については「自己解決」、つまりあなた自身やドキュメントが問題を解決します。もし自分で解決できない問題にぶつかったら、助けを得るのは難しい（もしくは不可能）です。ほぼ唯一の選択肢は、コミュニティフォーラムに問題を投稿し、コミュニティの他のメンバーが（a）わざわざ反応してくれて、（b）解決法を知っていることを祈ることです。
- まとめ:組織が初めてKubernetesの検証を始めるとき、しばしばオープンソースのIngress Controllerを選択します。それは便利で、無料で手に入れ、即座に利用を開始できるとドキュメントに書かれているからです。これは、スタート時、テスト時、または小規模な環境を実行する場合には、素晴らしいものとして利用できます。
デフォルトのIngress Controller
(プラットフォームに予め組み込まれた)デフォルトのIngress Controllerの多くはオープンソース技術をベースにしていますが、Kubernetesのプラットフォームを提供する企業によって開発・保守されている（そしてその管理の中でサポートを提供する）ため、ここでは別のカテゴリとして分類しています。このカテゴリの例としては、パブリッククラウドの Ingress Controller、Rancher、Red Hat OpenShift ルーターなどがあります。
- メリット
- 無料または低価格 – 低価格であることは、これらの製品を使用するための説得力のある理由です。すでにプラットフォームに統合されているため、使い始めのころは時間の節約になります。
- 信頼性とサポート – 専任のエンジニアリングチームによってメンテナンスされているため、コミュニティでメンテナンスされている Ingress Controllerよりも信頼性が高いかもしれません。商用サポートは一般的に含まれているか、追加費用で利用可能です。
- デメリット
- インフラストラクチャのロックイン – デフォルトのIngress Controllerはインフラストラクチャに依存するので、クラウド間でコントローラーや設定を移行することはできません。つまり、デプロイ環境ごとに異なるIngress Controllerが必要となり、ツールの乱立を招き、チームの学習曲線が長くなり、Ingress Controllerのセキュリティを維持することがより困難になります。
- 基本的な機能 – 通常、大規模なデプロイメントに必要な高度なトラフィック管理やセキュリティの機能は備えていません。
- 予測不可能なコスト（時間とお金） – 初期コストはゼロか低いものの、アプリケーションが成長するにつれて劇的に、そして予測不可能にコストが増加する可能性があります。これは、Ingress Controllerの最小限の機能セットに欠けている機能をアプリで実装する時間が必要になるということです。もちろん、アプリを更新するたびにこの追加した機能についても漏れることなく動作することをテストする必要があります。また、いくつかのデフォルトのツールで発生する別の問題が、クラウドの請求額を大きく跳ね上げることです。あなたのアプリケーションが人気になるについて、はじめは影響しなかったスループットの料金を大きくするのです。
- まとめ:Amazon Elastic Kubernetes Service (EKS)、 Google Kubernetes Engine (GKE)、Microsoft Azure Kubernetes Service (AKS)、 Rancher、Red Hat OpenShift Container Platformなどの管理されたプラットフォームを使用している場合、Kubernetesを使い始めたばかりのチームはデフォルトのIngress Controllerを選ぶことが多くなります。アプリが成熟し、チームが成長するにつれ、組織ではデフォルトのツールを置き換えるのではなく、エンタープライズグレードのIngress Controllerを環境に追加することが多く見られるのです。
商用のIngress Controllers
これらのIngress Controllerは、大規模な実稼働環境に対応するために設計されたライセンス製品です。その一例がNGINX PlusをベースとしたF5 NGINX Ingress Controllerで、これについては第4回で詳しく説明します。
- メリット
- 充実した機能郡 – 商用のIngress Controllerは、高度なトラフィック管理と大規模なデプロイのためのスケーラビリティをサポートする堅牢な機能を備えています。また、WAFやサービスメッシュなど、他のプロダクショングレード製品との統合が可能な場合もあります。
- スケーラブル – カスタマイズや回避策を必要とせず「すぐに使える」機能が数多くあるため、時間を無駄にすることなく機能を利用することができます。また、自動化やパイプラインの実行で簡単に利用できるため、必要に応じたインフラの拡張が可能です。
- 信頼性とサポート – 商用製品の主な利点の1つは、安定していることです。つまり、リリースごとに広範囲にテストされ、必要に応じて定期的にソフトウェアアップデートとセキュリティパッチが適用されます。商用のフルサポートは通常、さまざまな階層で提供されるため、重大な問題が発生した場合、数分から数時間以内にお客様に最適なサポートを受けられることがよくあります。
- デメリット
- 開発のスピード – 商用Ingress Controllerは安定性が重要であるため、その機能の速度はオープンソースのものに比べて少し遅れるかもしれません。
- コスト（お金） – 商用製品とは、実際お金が必要となります。資金よりも充実した開発者をもつ組織では、その状況である限り、（キャッシュアウトが求められる）コストは契約違反になる可能性があります。
- まとめ： 組織の規模が大きくなると、チームやアプリの複雑さに応じてIngress Controllerの選択がより重要になります。組織が大きく成長し複雑になった、商用のIngress Controllerは、管理面の複雑さを軽減し、自社の新機能を市場に投入するまでの時間を短縮できるため、有効な選択肢となります
次のステップ：選択肢を評価する
この段階では、あなたのニーズを満たすことができない選択肢を排除し、試すべきIngress Controllerを絞り込む準備ができています。ハイレベルな機能比較を始めるのに最適な場所の一つが learnk8s で、彼らは評価した Ingress Controllerの比較表を無償で提供しています。
Ingress Controllerを調べているうちに、多くのオプションが NGINX をベースにしていることに気づくでしょう。NGINX ベースの選択肢の概要については、このシリーズの最後のブログ、Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション をご覧ください。
