Ingress コントローラーの選択ガイド、パート 2: リスクと将来への備え

編集者– この投稿は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 コントローラーの選択ガイドのパート 1 では、要件を特定する方法について説明しました。 しかし、まだ製品をテストする時期ではありません! この投稿では、不適切な Ingress コントローラーによってリリース速度が遅くなり、顧客を失う可能性もあることを説明します。 他のツールと同様に、Ingress コントローラーはリスクをもたらし、将来のスケーラビリティに影響を与える可能性があります。 利益よりも害をもたらす可能性のある選択を排除する方法を見てみましょう。

イングレスコントローラのリスク

Kubernetes のトラフィック管理ツールを導入する際には、複雑さ、レイテンシ、セキュリティという 3 つの特定のリスクを考慮する必要があります。 これらの問題はしばしば絡み合っており、1 つの問題が存在すると、他の問題も発生する可能性が高くなります。 それぞれは Ingress コントローラーによって導入される可能性があり、リスクが許容できるかどうかを判断するのは組織次第です。 今日の消費者は気まぐれであり、魅力的な機能セットがあっても、デジタル体験の質を低下させるものは受け入れられない可能性があります。

複雑さ – マイクロサービス アーキテクチャの目的に反しますか?

最適な Kubernetes ツールは、マイクロサービス アーキテクチャの目標である軽量かつシンプルな設計を満たすツールです。 これらの原則に従った非常に機能豊富な Ingress コントローラーを開発することは可能ですが、それが常に標準であるとは限りません。 一部の設計者は、基盤となるエンジンにネイティブではない機能を追加するために、関数を過剰に含めたり、複雑なスクリプトを使用したりして、不必要に複雑な Ingress コントローラーを作成しています。

そして、それがなぜ重要なのでしょうか? Kubernetes では、過度に複雑なツールはアプリのパフォーマンスに悪影響を及ぼし、デプロイメントを水平方向に拡張する能力を制限する可能性があります。 通常、Ingress コントローラーが過度に複雑かどうかは、そのサイズで判断できます。フットプリントが大きいほど、ツールが複雑になります。

レイテンシ – Ingress コントローラーはアプリの速度を低下させますか?

Ingress コントローラーは、リソースの使用、エラー、タイムアウトにより遅延が発生する可能性があります。 静的展開と動的展開の両方で追加されるレイテンシを確認し、社内の要件に基づいて許容できないレイテンシをもたらすオプションを排除します。 再構成がアプリの速度にどのような影響を与えるかの詳細については、ブログの「動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト」を参照してください。

セキュリティ – Ingress コントローラーはハッカーに門戸を開いてしまうのでしょうか?

今日のインターネットでは共通脆弱性識別子 (CVE) が蔓延しており、Ingress コントローラー プロバイダーが CVE パッチを提供するのにかかる時間が、安全性と侵害の違いを生む可能性があります。 組織のリスク許容度に基づいて、パッチの提供に数日以上 (または最大で数週間) かかるソリューションを排除することをお勧めします。

CVE 以外にも、一部の Ingress コントローラーは別の潜在的な脆弱性にさらされます。 次のシナリオを考えてみましょう。あなたはオンライン小売業者に勤務しており、オープンソースの Ingress コントローラーの構成のトラブルシューティングに支援が必要です。 商用サポートは利用できないため、Stack Overflow などのフォーラムに問題を投稿します。 誰かが協力を申し出て、Ingress コントローラーとその他の Kubernetes コンポーネントの構成ファイルとログ ファイルの問題を調べたいと考えています。 問題を早く解決しなければならないというプレッシャーを感じて、ファイルを共有します。

「善良なサマリア人」があなたの問題解決を手伝ってくれますが、6 か月後に侵害が見つかります。顧客記録からクレジットカード番号が盗まれたのです。 おっと。 共有したファイルには、アプリへの侵入に使用された情報が含まれていたことが判明しました。このシナリオは、組織がサポートに料金を支払うことを選択する主な理由の 1 つである、機密性が保証されることを示しています。

OpenResty ベースの Ingress コントローラに関する注意事項

OpenResty は、NGINX Open Source 上に構築された Web プラットフォームであり、LuaJIT、Lua スクリプト、サードパーティの NGINX モジュールを組み込んで NGINX Open Source の機能を拡張します。 一方、OpenResty 上に構築された Ingress コントローラーはいくつかありますが、NGINX Open Source と NGINX Plus に基づく Ingress コントローラーと比較して、次の 2 つのリスクが潜在的に加わる可能性があると考えています。

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

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

  Lua によってどの程度のレイテンシが追加されるかを確認するには、 「動的 Kubernetes クラウド環境での NGINX Ingress コントローラーのパフォーマンス テスト」をお読みください。

• CVE パッチ適用の遅延– NGINX の Ingress コントローラーと比較すると、NGINX オープンソースに基づく OpenResty などのツールに基づく Ingress コントローラーでは、CVE のパッチが表示されるまでに必然的に時間がかかります。 「NGINX Plus を使用してセキュリティ脆弱性を迅速かつ簡単に軽減する」で詳しく説明しているように、NGINX で CVE が発見された場合、通常、CVE が公開される前にベンダーである私たちに通知されます。 これにより、CVE が発表されるとすぐに、NGINX Open Source と NGINX Plus のパッチをリリースできるようになります。

  NGINX オープンソースに基づくテクノロジーは、その時点まで CVE について認識しない可能性があり、私たちの経験では、OpenResty のパッチは私たちのパッチよりも大幅に遅れています (最近の 1 つのケースでは 4 か月遅れ) 。 OpenResty に基づく Ingress コントローラーのパッチには必然的にさらに時間がかかり、悪意のある人物が脆弱性を悪用する十分な機会を与えてしまいます。

将来を見据えたIngressコントローラの構築

Kubernetes をまだ使い始めたばかりの場合でも、いつかは本番環境に導入したいと考える可能性は十分にあります。 時間の経過とともにニーズが拡大する可能性のある主な領域は、インフラストラクチャ、セキュリティ、サポート、マルチテナントの 4 つです。

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

組織が 1 つのタイプの環境に完全かつ永続的にコミットすることはまれです。 より一般的には、組織はオンプレミスとクラウドを混在させており、これにはプライベート、パブリック、ハイブリッド クラウド、マルチクラウドが含まれます。 (これらの環境の違いについて詳しくは、 「マルチクラウドとハイブリッドクラウドの違いは何ですか? 」をお読みください。)

このシリーズのパート 1で述べたように、各環境にデフォルトで付属するツールを選択しがちですが、デフォルトの Ingress コントローラーに固有の問題が多数あります。 シリーズのパート 3 ではすべての欠点について説明しますが、将来性に関して最も関連のある問題はベンダー ロックインです。つまり、クラウド固有の Ingress コントローラーをすべての環境で使用することはできないということです。 デフォルトのクラウド固有のツールを使用すると、魅力のない選択肢が 2 つしか残らないため、スケーリング能力に影響します。

1. 既存のクラウドをあらゆるニーズに対応できるようにしましょう
2. 新しい環境ごとに、Ingress コントローラーのすべての構成（負荷分散だけでなくセキュリティも含む）を書き換えます。

最初の選択肢はビジネス上の理由から実行できないことがよくありますが、2 番目の選択肢も、ツールの無秩序な増加、新たなセキュリティの脆弱性の発生、従業員の急激な学習曲線の克服が必要になるため、扱いが難しいです。 3 番目で最も効率的な代替案は、最初からインフラストラクチャに依存しない Ingress コントローラーを選択して、すべての環境で同じツールを使用できるようにすることです。

インフラストラクチャに関しては、考慮すべきもう 1 つの要素として認証があります。 Red Hat OpenShift Container Platform (OCP) の例を使用しましょう。 OCP ユーザーであれば、Red Hat Marketplace がNGINX Ingress Operatorを含む OCP の認定オペレーターを提供していることをすでにご存知でしょう。 Red Hat の認定基準により、ツールがデプロイメントで機能し、Red Hat とベンダーの共同サポートも受けられることがわかり、安心できます。 多くの組織では、セキュリティと安定性の理由から認定ツールの使用が求められています。そのため、現在はテスト段階のみであっても、運用環境に対する会社の要件を念頭に置いておくことが重要です。

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

境界セキュリティだけでアプリと顧客を安全に保つことができた時代は終わりました。 Kubernetes アプリは、認証や承認などのセキュリティがアプリの近くにある場合に最も効果的に保護されます。 また、組織がエンドツーエンドの暗号化を義務付け、Kubernetes 内でゼロトラスト ネットワーク モデルを採用するケースが増えているため、将来的にはサービス メッシュが主流になるかもしれません。

これらすべては Ingress コントローラーとどのような関係があるのでしょうか? たくさん！ Ingress ポイントでセキュリティ (認証、承認、DoS 保護、Web アプリケーション ファイアウォール) を集中管理することは、コストと効率の両方の観点から非常に理にかなっています。 ほとんどのサービス メッシュはほとんどの Ingress コントローラーと統合できますが、どのように統合するかが非常に重要です。 セキュリティ戦略に適合した Ingress コントローラーを使用すると、アプリ開発プロセス全体にわたって大きな問題を防ぐことができます。

クラウド ネイティブ アプリ配信のリスクの詳細については、「速度を落とさずにクラウド ネイティブ アプリを保護する」を、セキュリティ ツールの最適な配置を決定する要因の詳細については、「Kubernetes でのアプリケーション サービスのデプロイ、パート 2」をお読みください。

サポート – どれくらい「独力で」対応できますか?

チームが Kubernetes を試しているだけの場合、コミュニティからのサポートでも企業からのサポートでも、サポートは最優先事項ではないことがよくあります。 チームが独自の解決策や回避策を考え出す時間が十分にある場合は問題ありませんが、本番環境に移行すると持続可能ではありません。 現在サポートが必要ない場合でも、将来的にサポートを追加できる Ingress コントローラー、または規模に応じてアップグレードできる安価なサポート層を備えた Ingress コントローラーを選択するのが賢明です。

マルチテナント – 複数のチームとアプリがコンテナ環境を安全かつ確実に共有するにはどうすればよいでしょうか?

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

最大限の効率を実現するために、組織はマルチテナントを採用し、ビジネス プロセスで義務付けられているアクセスと分離をサポートすると同時に、オペレーターが必要とする健全性と制御も提供する Kubernetes モデルを採用しています。 一部の Ingress コントローラは、複数の Ingress、クラス、名前空間、ロールベースのアクセス制御 (RBAC) の設定をサポートするスコープ付きリソースなど、さまざまな機能と概念を通じて、これらのクラスターを分割するのに役立ちます。

次のステップ: オプションを絞り込む

要件、リスク許容度、将来性について検討したので、Ingress コントローラーの非常に幅広い選択肢を絞り込むのに十分な情報が得られました。 そのフィールドをカテゴリ別に分類すると、このステップを迅速に実行できるようになります。 このシリーズのパート 3 では、Ingress コントローラーの 3 つの異なるカテゴリについて、それぞれの長所と短所を含めて説明します。