Ingress コントローラーの選択ガイド、パート 1: 要件を特定する

編集者– この投稿は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」としてダウンロードすることもできます。

組織が初めて Kubernetes の実験を開始するときは、 Ingress コントローラーの選択についてあまり考慮しないことがよくあります。 すべての Ingress コントローラーは同じであると考えるかもしれません。すぐに起動して実行するために、選択した Kubernetes フレームワークのデフォルトの Ingress コントローラーを使用するのが最も簡単です。 そして、テスト環境や小規模な本番環境では、ほぼすべての Ingress コントローラが問題なく使用できるのは事実です。 しかし、規模が大きくなるにつれて、Ingress コントローラーの選択がより重要になります。 これは、Ingress コントローラが、トラフィックをポイント A からポイント B に移動する基本的な機能よりもはるかに多くの機能を提供できるためです。

高度なトラフィック管理から可視性、組み込みセキュリティまで、Ingress コントローラーは Kubernetes スタックで最も強力なツールの 1 つになります。 実際、F5 NGINX では、これをあらゆる本番環境レベルの Kubernetes展開の基盤であると考えています。 しかし、多くの開発者やプラットフォーム運用チームは、Ingress コントローラーの真価を理解しておらず、拡張できないコントローラーを選択した場合の結果も理解していません。 適切に拡張できない、または複雑な環境を保護しない Ingress コントローラーを選択すると、Kubernetes をテストから本番環境に移行できなくなる可能性があります。 このブログ シリーズでは、Ingress コントローラーの基礎と、現在および将来に必要な機能とセキュリティを実現する賢明な選択を行う方法について学習することを目的としています。

Ingress コントローラーとは何ですか?

Ingress コントローラは、Kubernetes クラスターに入るレイヤー 4 および 7 のトラフィック、および場合によってはクラスターから出るトラフィックを管理する特殊なロード バランサです。 全員が同じ認識を持つように、NGINX で使用する用語を以下に示します (業界全体でほぼ同じです)。

• イングレストラフィック– Kubernetes クラスターに入るトラフィック
• 出力トラフィック– Kubernetes クラスターから出るトラフィック
• North-South トラフィック– Kubernetes クラスターに出入りするトラフィック (イングレス-エグレストラフィックとも呼ばれます)
• East-West トラフィック– Kubernetes クラスター内のサービス間を移動するトラフィック (サービス間トラフィックとも呼ばれます)
• サービスメッシュ–サービス間のトラフィックをルーティングおよび保護するためのトラフィック管理ツール

Ingress コントローラーが必要な理由

デフォルトでは、Kubernetes ポッド (コンテナ) で実行されているアプリケーションは外部ネットワークからはアクセスできず、Kubernetes クラスター内の他のポッドからのみアクセスできます。 Kubernetes には、 Ingressと呼ばれる HTTP ロード バランシング用の組み込み構成オブジェクトがあり、Kubernetes クラスターの外部のエンティティが 1 つ以上の Kubernetes サービスによって表されるポッドに接続する方法を定義します。

Kubernetes サービスへの外部アクセスを提供する必要がある場合は、 Ingress リソースを作成して、URI パス、バッキング サービス名、その他の情報を含む接続ルールを定義します。 ただし、Ingress リソースだけでは何も実行されません。 Ingress リソースで定義されたルールを実装するには、Ingress コントローラー アプリケーション (Kubernetes API を使用) をデプロイして構成する必要があります。

Ingress コントローラーは何をするのですか?

• Kubernetes 環境の外部からのトラフィックを受け入れ、それを変更 (シェーピング) し、環境内で実行されているポッドに配布します。 Ingress コントローラーは、デフォルトのkube-proxyトラフィック分散モデルを置き換え、Kubernetes 以外の環境でアプリケーション配信コントローラー (ADC) やリバース プロキシが提供するような追加の制御を提供します。
• サービスの個々のポッドを監視し、インテリジェントなルーティングを保証し、リクエストが「ブラックホール化」されるのを防ぎます。
• 相互 TLS (mTLS) によるセキュリティを強化したり、特定のポッドから特定の外部サービスへの送信トラフィックを制限したりするための出力ルールを実装します。

Ingress コントローラーを選択するときは、機能リストから始めたくなるかもしれませんが、素晴らしい機能を備えていてもビジネス ニーズを満たさない Ingress コントローラーを選択してしまう可能性があります。 代わりに、Ingress コントローラーがチームとアプリでどれだけうまく機能するかに影響する 2 つの要素、つまりユースケース (どのような問題を解決するか) とリソース (どのように「支払う」か) を必ず検討してください。 このブログの残りの部分では、これら 2 つのトピックについて説明します。

Ingress コントローラーで解決したい問題は何ですか?

Ingress コントローラの中心的なユースケースはトラフィック管理であるため、Ingress コントローラで次の一般的なユースケースの 1 つ以上を処理することが必要な場合があります。

• 負荷分散 (HTTP2、HTTP/HTTPS、SSL/TLS 終端、TCP/UDP、WebSocket、gRPC)
• トラフィック制御（レート制限、サーキットブレーキング、アクティブヘルスチェック）
• トラフィック分割（デバッグルーティング、A/B テスト、カナリアデプロイメント、ブルーグリーンデプロイメント）

しかし、「一芸に秀でた」ものに満足する必要はありません。ほとんどの Ingress コントローラーは、トラフィックの管理以上の機能を備えています。 Ingress コントローラーを使用して複数の問題を解決することで、スタックのサイズと複雑さが軽減されるだけでなく、非機能要件をアプリから Ingress コントローラーにオフロードすることもできます。 リソースをより効率的に使用しながら、Kubernetes デプロイメントのセキュリティ、俊敏性、スケーラビリティを高めるのに役立つ、従来とは異なる Ingress コントローラーのユースケースを 4 つ見てみましょう。

監視と可視性

Kubernetes クラスターの可視性の欠如は、本番環境における最大の課題の 1 つであり、トラブルシューティングと回復力の困難につながります。 Ingress コントローラーは Kubernetes クラスターのエッジで動作し、あらゆるトラフィックに関係するため、Kubernetes クラスターまたはプラットフォームでのアプリの速度低下とリソース枯渇という 2 つの一般的な問題のトラブルシューティング (さらには回避) に役立つデータを提供するのに適しています。 Ingress コントローラの可視性を向上させるには、次のことが必要です。

• リアルタイムで指標を提供し、「今」何が起こっているかを診断できるようにします
• PrometheusやGrafanaなどの一般的な可視化ツールに指標をエクスポートして、時間の経過に伴う値をプロットし、トラフィックの急増やその他の傾向を予測できるようにします。

APIゲートウェイ

Kubernetes でリクエストとレスポンスの操作を実行する予定がない限り、Ingress コントローラーが API ゲートウェイとしても機能する可能性が非常に高くなります。 Ingress コントローラは、その機能セットに応じて、TLS 終了、クライアント認証、レート制限、きめ細かいアクセス制御、レイヤー 4 から 7 でのリクエスト ルーティングなどのコア API ゲートウェイ機能を提供できる場合があります。

認証とシングルサインオン

ログイン資格情報の認証を Kubernetes サービスから Ingress コントローラーにオフロードすると、2 つの問題を解決できます。

• OpenID Connect (OIDC) を使用したシングル サインオン (SSO) を実装することで、ユーザーが単一の認証情報セットで複数のアプリにログインできるようになります。
• 各アプリケーションに認証機能を組み込む必要がなくなり、開発者はアプリのビジネス ロジックに集中できるようになります。

Web アプリケーション ファイアウォールの統合

Ingress コントローラが Web アプリケーション ファイアウォール (WAF) として機能できるわけではなく、WAF を Ingress コントローラと統合できるということです。 WAF は Kubernetes の内外のさまざまな場所にデプロイできますが、ほとんどの組織にとって最も効率的で効果的な場所は Ingress コントローラーと同じポッド内です。 このユースケースは、セキュリティ ポリシーが SecOps または DevSecOps の指示下にあり、きめ細かいサービスごとまたは URI ごとのアプローチが必要な場合に最適です。 つまり、Kubernetes API を使用してポリシーを定義し、それをサービスに関連付けることができます。 さらに、Ingress コントローラのロールベースのアクセス制御 (RBAC) 機能により、SecOps はリスナーごとにポリシーを適用し、DevOps ユーザーは Ingress リソースごとにポリシーを設定できます。

Ingress コントローラーにリソースをどのように割り当てる予定ですか?

すべての Ingress コントローラーにはコストがかかります...無料かつオープン ソースのものであってもです (「子犬のように自由」というフレーズを聞いたことがあるかもしれません)。 一部のコストは予算の明細項目として予測可能な金額を割り当てることができますが、その他のコストは、選択した Ingress コントローラーの結果 (複雑さの増大、移植性の欠如など) に対処するためにチームが費やす必要がある時間によって異なります。 Ingress コントローラーの予算を立てる際に考慮すべきコスト（時間とお金の両方）について見てみましょう。時間とお金です。

時間コストの予算化

人員の予算編成は、特に馴染みのない分野でプロジェクトにリソースを割り当てようとする場合、固定費項目の予算編成よりもはるかに困難になる可能性があります。 次のような質問をする必要があります。

• Ingress コントローラーを構成および管理するのは誰ですか? それは彼らのフルタイムの仕事の一部ですか（たとえば、プラットフォーム運用チームのメンバーとして）、それとも追加の責任として引き受けていますか（開発者として）。
• 従業員が正式な研修を受ける時間を作ることはできますか? それとも、ツールは仕事中に素早く簡単に習得できるほどシンプルでなければなりませんか?
• 新しい機能が必要なときに従業員に調整させたり、問題が発生したときにトラブルシューティングに長い時間を費やさせたりすることに備えていますか? それとも、他のビジネス価値を提供する必要がありますか?

Kubernetes ツールの所有権に関する注意

業界では、ツールと所有権を NetOps チームの管轄下に統合する傾向が見られます。 これはスタックの簡素化とセキュリティの向上に大いに役立ちますが、私たちはチームの目標に基づいてツールを慎重に複製することを推奨します。 NetOps チームはより広範なプラットフォームに重点を置いているため、境界ツール (外部ロード バランサーなど) を管理させるのは理にかなっています。しかし、DevOps チームは、アプリ コードの近くに展開されたサービスに最も重点を置き、NetOps ツールから得られるよりも俊敏性ときめ細かい制御を必要としています。 Ingress コントローラーを含む Kubernetes ツールは、DevOps によって選択された場合に成功する可能性が最も高くなります。 ただし、開発者にツールの選択の完全な自由を与えなければならないというわけではありません。 Kubernetes内でのツールの厳格な標準化は、依然としてベスト プラクティスです。

資本コストの予算編成

組織が初めて Kubernetes を試す場合、ツールやサポートにあまり予算を割り当てないことがよくあります。 もっと「手助け」が必要な Ingress コントローラーを本当にサポートできる人的リソースがある場合は、最初は金銭的な予算は不要です。 しかし、Kubernetes への投資が増えるにつれて、ツールの機能によって制限されることに気付いたり、チームを他の優先事項に専念させたいと考えるようになるかもしれません。 そうなると、エンタープライズ機能とサポートを備えた、より使いやすく安定したツールにお金を払う傾向が強まります。

Ingress コントローラーの料金を支払う準備ができたら、ライセンス モデルが重要であることに注意してください。 Kubernetes 外部の従来の価格モデルに基づくと、Ingress コントローラーの価格設定は多くの場合「インスタンスごと」または「Ingress プロキシごと」になります。 Kubernetes ではこれがまだ意味をなすユースケースもありますが、Ingress コントローラーのライセンスを「クラスターごと」に付与すると、「プロキシの数」ではなくアプリケーションのテナントに基づいて支払うことになります。

さまざまなシナリオに対する推奨事項は次のとおりです。

• Kubernetes は初めてですか? クラスターごとのライセンスを選択します。
  Kubernetes の経験がない場合、必要な Ingress コントローラー インスタンスの数を正確に予測することは非常に困難です。 インスタンスの数を強制的に選択すると、過小評価して目標を達成するのが難しくなったり、過大評価して Kubernetes プロジェクトの他の部分に費やした方がよい資金を無駄にしたりする可能性があります。 「小さなクラスター」に対して比較的低い固定価格を交渉すると、成功する可能性が高まります。
• Kubernetes をスケーリングしますか? クラスターごとのライセンスを選択します。
  Kubernetes リソースをどの程度、どのくらいの頻度でスケールアップおよびスケールダウン（バーストと縮小）する必要があるかを予測することはほぼ不可能です。 インスタンスごとの価格設定により、チームはライセンス上限内に収めるために任意のしきい値を強制的に設定する必要があります。 クラスターごとのライセンスでは、個々の Ingress コンテナを追跡する必要はありません。また、ベンダー (NGINX など) によっては、追加料金なしでバーストが含まれる場合もあります。
• 高度な展開か静的な展開か? インスタンスごとのライセンスを選択します。
  Kubernetes に精通していて Ingress コントローラーの使用方法を正確に把握しており、クラスターごとに少数の Ingress プロキシを使用する予定で、ツールに付属するバンドル サービスが必要ない場合は、インスタンスごとの価格設定が最適な選択肢となります。

次のステップ: リスク許容度と将来性

要件を把握できたので、次のステップは、Ingress コントローラーがもたらす可能性のあるリスクに対する許容度をチームとして決定し、Kubernetes デプロイメントの拡大に合わせて Ingress コントローラーをどのように拡張する必要があるかを把握することです。 パート2ではそれらのトピックを取り上げます。