Ingress Controllerの選択ガイド, Part 2 : リスクと将来性

この記事は10部構成の一部です。

1. Reduce Complexity with Production-Grade Kubernetes（英語）
2. 高度なトラフィック管理でKubernetesの耐障害性を向上させる方法
3. Kubernetesの可視性を向上させる方法
4. トラフィック管理ツールを使ってKubernetesを安全にする6つの方法
5. Ingress Controllerの選択ガイド, Part 1: 要件の特定
6. Ingress Controllerの選択ガイド, Part 2 : リスクと将来性（この記事です）
7. Ingress Controllerの選び方ガイド, Part 3：オープンソース / デフォルト / 商用版
8. Ingress Controllerの選択ガイド, Part 4 : NGINX Ingress Controllerのオプション
9. サービスメッシュの選び方
10. Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment（英語）

これらのブログ一式を無料のebookとして下記よりダウンロードいただけます。– Kubernetes のテスト環境から本番環境への移行

Ingress Controllerの選び方ガイドのパート1では、要件の洗い出し方について説明しました。しかし、まだ製品を検証・実装するタイミングではありません。

この記事では、間違ったIngress Controllerが、いかにリリース速度を遅くし、ユーザを失うことになるかを説明します。他のツールと同様に、Ingress Controllerはリスクをもたらし、将来のスケーラビリティに影響を与える可能性があります。良いことよりも悪いことを引き起こすかもしれない選択肢を排除する方法を見ていきましょう。

Ingress Controllerのリスク

Kubernetesのトラフィックを制御するツールを導入する際に考慮すべき具体的なリスクは、「複雑さ」「レイテンシー」「セキュリティ」の3つです。これらの問題はしばしば絡み合っており、1つが存在すると、他の問題も見えてくる可能性があります。それぞれはIngress Controllerによってもたらされる可能性があり、そのリスクを許容できるかどうかは、組織次第です。今日のユーザは、魅力的な機能にもかかわらず、質の悪いデジタル体験を引き起こすものは受け入れがたいかもしれません。

複雑さ – マイクロサービスアーキテクチャの目的を逸脱するのか？

最高のKubernetesのツールは、マイクロサービスアーキテクチャの目標である「軽量でシンプルな設計」を満たすものです。これらの原則に忠実な、非常に機能豊富なIngress Controllerを開発することは可能ですが、それが常に標準というわけではありません。設計者の中には、機能を盛り込みすぎたり、複雑なスクリプトを使用して、基盤となるエンジンのネイティブではない機能を追加したりして、Ingress Controllerを不必要に複雑にしてしまう人がいます。

それでは、なぜ軽量でシンプルな設計であることが重要なのでしょうか？Kubernetesでは、過度に複雑なツールはアプリのパフォーマンスに悪影響を与え、デプロイの水平方向のスケーリング能力を制限する可能性があります。複雑すぎるIngress Controllerは、通常、そのサイズによって見分けることができます。(フットプリントが大きければ大きいほど、ツールはより複雑になります。)

レイテンシー – Ingress Controllerはアプリを遅くするのか？

Ingress Controllerは、リソースの使用、エラー、タイムアウトによってレイテンシーを追加する場合があります。

静的および動的なデプロイメントで追加されるレイテンシーを調べ、内部要件に基づいて許容できないレイテンシーを発生させるオプションは削除してください。再構成がアプリの速度に与える影響の詳細については、弊社ブログの「Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environment」を参照してください。

セキュリティ – Ingress Controllerは攻撃者へ扉を開くか？

今日のインターネットでは、CVE（Common Vulnerabilities and Exposures）が蔓延しており、Ingress ControllerのプロバイダーがCVEパッチを提供するまでの時間が、安全と侵害の分かれ目となる可能性があります。組織のリスク許容度に基づき、パッチの提供に数日以上（長くても数週間）かかるようなソリューションは排除した方がよいかもしれません。

CVEs 以外にも、いくつか Ingress Controllerは、別の潜在的な脆弱性にさらされています。このようなシナリオを考えてみましょう：あなたはオンライン小売業者に勤めていて、オープンソースのIngress Controllerの設定に関するトラブルシューティングを必要としています。商用サポートは利用できないので、あなたはStack Overflowのようなフォーラムに問題を投稿します。誰かが手助けを申し出て、Ingress Controllerや他のKubernetesコンポーネントの設定ファイルやログファイルから問題を探したいと思っています。問題を早く解決しなければならないというプレッシャーを感じながら、あなたはファイルを共有します。

その「良き人」は、あなたの問題解決を手助けしてくれますが、6ヵ月後、顧客記録からクレジットカード番号が盗まれていることが発覚します。あなたが共有したファイルには、あなたのアプリに侵入するために使用された情報が含まれていたことが判明しました。このシナリオは、組織がサポートにお金を払うことを選択する最大の理由の1つである「機密保持の保証」を示しています。

OpenRestyベースのIngress Controllerに関する注意点

OpenRestyはNGINX Open Sourceをベースに構築されたWebプラットフォームで、NGINX Open Sourceの機能を拡張するためにLuaJITやLuaスクリプト、サードパーティのNGINXモジュールなどを組み込んでいます。それに伴い、OpenRestyをベースに構築されたIngress Controllerも複数存在し、NGINX Open SourceやNGINX Plusをベースにした当社のIngress Controllerと比較して、2つのリスクが加わる可能性があると考えています。

• タイムアウト – 前述の通り、OpenRestyはLuaスクリプトを使用して、商用NGINX PlusベースのIngress Controllerのような高度な機能を実装しています。そのような機能の1つに動的な構成変更があり、可用性を低下させるNGINXオープンソースの要件、すなわちサービスのエンドポイントが変更されたときにNGINXの構成を再ロードする必要がないようにします。OpenRestyで動的な構成変更を実現するために、Luaハンドラはどのアップストリームサービスにリクエストをルーティングするかを選択し、それによってNGINXの設定をリロードする必要をなくします。

  しかし、Luaはバックエンドの変更を継続的にチェックする必要があり、リソースを消費してしまいます。また、受信したリクエストの処理に時間がかかり、リクエストの一部が停滞し、タイムアウトの可能性が高くもなります。ユーザやサービスの規模が大きくなると、1秒間に受信するリクエスト数とLuaが処理できる数の差が指数関数的に大きくなりますので、遅延、複雑さ、コスト増が発生します。

  Performance Testing NGINX Ingress Controllers in a Dynamic Kubernetes Cloud Environmentを読んで、Luaがどの程度のレイテンシーを追加できるかを確認してください。

• CVEパッチの遅れ – NGINXのIngress Controllerと比較すると、CVEに対するパッチが、NGINXオープンソースをベースとするOpenRestyのようなツールをベースにしたIngress Controllerに表示されるまで、必然的に時間がかかります。 Mitigating Security Vulnerabilities Quickly and Easily with NGINX Plusで詳しく説明しているように、NGINXのCVEが発見された場合、通常、CVEが公表される前にベンダーである私たちに通知が届きます。そのため、CVEが発表されるとすぐにNGINX Open SourceおよびNGINX Plus用のパッチをリリースすることができます。

  NGINXオープンソースをベースとするテクノロジーは、その時点までCVEについて知らないかもしれませんし、我々の経験では、OpenRestyのパッチは我々のパッチよりかなり遅れています（最近のケースでは4ヶ月）。OpenRestyをベースにしたIngress Controllerのパッチは、必然的にさらに時間がかかり、悪意ある行動をとる者に脆弱性を悪用する十分な機会を与えることになります。

Ingress Controllerの将来性

Kubernetesを使い始めたばかりでも、いつかは本番運用をしたいと考えている人は多いはずです。インフラ、セキュリティ、サポート、マルチテナントという4つの領域が、時間とともにニーズが高まっていく可能性があります。

インフラストラクチャ – ハイブリッドまたはマルチクラウド環境でKubernetesを使用しますか？

企業が1つのタイプの環境に完全かつ永続的にコミットすることは稀です。一般的には、オンプレミスとクラウドが混在しており、プライベートクラウド、パブリッククラウド、ハイブリッドクラウド、マルチクラウドなどがあります。(これらの環境の違いについては、「マルチクラウドとハイブリッドクラウドの違いとは」をご覧ください）。

本連載のPart 1で述べたように、各環境にデフォルトで付属しているツールを選びたくなりますが、デフォルトのIngress Controllerには特有の問題が多数存在します。このシリーズのPart 3ですべての短所を取り上げますが、将来的な対策に最も関連する問題は、ベンダーロックインです – クラウド固有のIngress Controllerをすべての環境で使用することはできません。クラウドに特化したデフォルトのツールを使うと、2つの魅力的でない選択肢が残ることになり、拡張性に影響を及ぼします。

1. 既存のクラウドをすべてのニーズに対応させるようにする
2. ロードバランシングだけでなく、セキュリティの設定もすべて書き換える- 新しい環境ごとにIngress Controllerの設定を書き換える

前者はビジネス上の理由で実行できないことが多いのですが、後者はツールが乱立し、セキュリティ上の脆弱性が生じ、従業員に急な学習カーブを強いるため、厄介です。

3つ目の最も効率的な方法は、インフラに依存しないIngress Controllerを最初から選択することです。これにより、すべての環境で同じツールを使用することができます。

インフラに関しては、もう一つ考慮すべき要素があります。それは、認定です。 Red Hat OpenShift Container Platform (OCP) を例にとって説明しましょう。

OCPユーザであれば、Red Hat MarketplaceがNGINX Ingress Operatorを含むOCP用の認定オペレーターを提供していることはすでにご存じでしょう。Red Hat の認定基準は、ツールがあなたのデプロイメントで動作し、Red Hat とベンダーの共同サポートが含まれることもあるという安心感を得ることができることを意味します。多くの組織が、セキュリティと安定性の理由から認定ツールの使用を要求しています。したがって、たとえ今はテスト段階であっても、本番環境に対する企業の要求を念頭に置いておくことが重要です。

セキュリティ – Kubernetesを内部からどのように保護するのか？

境界のセキュリティだけで、アプリケーションと顧客の安全を確保できた時代は終わりを告げました。Kubernetesアプリケーションは、認証と認可を含むセキュリティがアプリケーションの近くにある場合に、最もよく保護されます。そして、エンドツーエンドの暗号化を義務付け、Kubernetesにゼロトラストネットワークモデルを採用する組織が増える中、サービスメッシュはあなたの未来にあるのかもしれません。

これがIngress Controllerとどう関係があるのでしょうか？

セキュリティ（認証、認可、DoS防御、Webアプリケーションファイアウォール）をIngressの時点で一元化することは、コストと効率の両方の観点から非常に理にかなっています。そして、ほとんどのサービスメッシュはほとんどのIngress Controllerと統合することができますが、どのように統合するかは非常に重要です。セキュリティ戦略に沿った Ingress Controllerは、アプリ開発の過程で大きな頭痛の種を防ぐことができます。

クラウドネイティブアプリ配信のリスクについて詳しくは「Secure Cloud‑Native Apps Without Losing Speed」を、セキュリティツールの最適な配置を決める要因については「Deploying Application Services in Kubernetes, Part 2」をお読みください。

サポート – どの程度 “On Your Own “になれるか？

チームがKubernetesを実験的に使用している段階では、コミュニティであれ企業であれ、サポートは最優先事項ではないことがよくあります。これは、チームが独自のソリューションや回避策を考え出すのに多くの時間がある場合は問題ありませんが、本番環境に移行したときに持続可能ではありません。今はサポートが必要なくても、将来的にサポートを追加できる、あるいは規模に応じてアップグレードできる安価なサポート階層を持つIngress Controllerを選択することは賢明な選択と言えます。

マルチテナント – 複数のチームやアプリが安全かつセキュアにコンテナ環境を共有するには？

最初は、1つのチームと1つのアプリがあった…どんな物語もそうやって始まるのではないでしょうか？その1つのチームが1つのKubernetesアプリの開発に成功し、組織がKubernetes上でより多くのサービスを実行するようになる、というストーリーが続くことが多いのです。そしてもちろん、より多くのサービス = より多くのチーム = より多くの複雑さです。

最大限の効率を達成するために、組織はマルチテナントを採用し、ビジネスプロセスによって義務付けられたアクセスと分離をサポートしながら、オペレーターが必要とする健全性と制御を提供するKubernetesモデルを採用します。いくつかのIngress Controllerは、複数のIngress、クラス、名前空間、およびロールベースのアクセス制御（RBAC）の設定をサポートするスコープ付きリソースなど、多くの機能と概念を通じて、それらのクラスタを切り分けるのを助けることができます。

次のステップ：選択肢を絞り込む

要件、リスク許容度、将来性などについて考えたところで、非常に広い分野のIngress Controllerを絞り込むのに十分な情報が得られました。この分野をカテゴリー別に分類することで、このステップを迅速に行うことができます。このシリーズのパート3では、Ingress Controllerの3つのカテゴリーについて、それぞれの長所と短所を含めて説明します。