Ingress Controllerの選択ガイド, Part 1: 要件の特定

3年 ago

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

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

組織で初めてKubernetesの利用を開始するとき、どのIngressコントローラーを使うか、あまり考慮しないことがみられます。Ingressコントローラーはどれも似たようなものであり、素早く稼働させるためには、選択したKubernetesフレームワークのデフォルトIngressコントローラーにそのまま使うのが一番簡単だ、と考えるかもしれません。テストや小規模な本番環境では、どのようなIngressコントローラーでも良いというのは事実です。

しかし、規模が大きくなるにつれて、Ingressコントローラーの選択はより重要になります。それは、Ingress コントローラーはトラフィックを A 地点から B 地点に移動させるという基本的な機能以上のものを提供できるからです。

高度なトラフィック管理から、組み込みのセキュリティの可視化まで、IngressコントローラーはKubernetesスタックの中で最も強力なツールの1つになり得ます。実際、F5 NGINXでは、IngressコントローラーはプロダクショングレードのKubernetes デプロイメントの基礎であると考えています。

しかし、多くの開発者とプラットフォームの運用チームは、Ingressコントローラーのフルパワー、言うなれば、スケールできないものを選択した際に遭遇する結果に気づいていません。

うまくスケールできない、あるいは、複雑な環境を保護できないIngressコントローラーを選択した場合、Kubernetesをテストから本番に移行することができなくなる可能性があります。このブログシリーズでは、Ingressコントローラーの基礎と、今後必要となる機能やセキュリティを提供する賢い選択方法について学ぶことを目的としています。

Ingressコントローラーとは？

Ingressコントローラーとは、Kubernetesクラスタに入るレイヤー4からレイヤー7 のトラフィック、クラスタから出ていく潜在的なトラフィックを管理する特徴をもつロードバランサーのことです。私たちが同じ理解を持てるように、NGINXで使用している用語を以下に示します（これらの用語は業界全体でほぼ同じです）。

Ingressトラフィック – Kubernetesクラスタに入るトラフィック
Egressトラフィック – Kubernetesクラスタから出るトラフィック
North-southトラフィック – Kubernetesクラスタに出入りするトラフィック（ingress‑egressトラフィックとも呼ばれます）
East-westトラフィック – Kubernetesクラスタ内のサービス間を移動するトラフィック（service-to-serviceトラフィックとも呼ばれます）
サービスメッシュ – service-to-serviceトラフィックをルーティングし、安全性を確保するためのトラフィック制御ツール

なぜIngressコントローラーが必要なのか？

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

Kubernetesサービスに外部からのアクセスを提供する必要がある場合、Ingressリソースを作成して、URIパスや後段のサービス名などの接続ルールを定義します。しかし、Ingressリソース単体では何もできません。Ingressリソースで定義したルールを実装するために、Ingressコントローラーアプリケーションを（Kubernetes APIを使用して）デプロイし、設定する必要があります。

Ingressコントローラーの役割とは？

Kubernetes環境の外からトラフィックを受け入れ、潜在的にそれを修正（成形）し、環境内で動作するポッドに配信します。Ingressコントローラーは、デフォルトのkube-proxyトラフィック配信モデルを置き換え、非Kubernetes環境でアプリケーション配信コントローラー（ADC）やリバースプロキシが提供するような追加の制御を提供します。
サービスの個々のポッドを監視し、高度なルーティングを保証し、リクエストが “ブラックホール化“ するのを防ぎます。
相互TLS（mTLS）でセキュリティを強化したり、特定のポッドから特定の外部サービスへの送信トラフィックを制限したりするためのEgressルールを実装します。

Ingressコントローラーを選ぶとき、機能リストから始めたくなるかもしれません。しかし、素晴らしい機能を持ったIngressコントローラーでも、ビジネスニーズを満たせないということになりかねません。その代わりに、Ingress コントローラーがチームやアプリにとってどれだけうまく機能するかに影響を与える2つの要素、すなわち、ユースケース（どんな問題を解決するか）と必要となるリソース（その運用で何を対価として支払うのか）を必ず検討しましょう。このブログの残りの部分で、この2つのトピックをカバーします。

Ingressコントローラーに解決してほしい問題とは？

Ingressコントローラーの中心となるユースケースはトラフィックマネジメントのため、Ingressコントローラーを用いて以下のような一般的なユースケースを処理したいとおそらく考えることでしょう。

ロードバランシング（HTTP2、HTTP/HTTPS、SSL/TLSターミネーション、TCP/UDP、WebSocket、gRPC)
トラフィック制御（レート制限、サーキットブレーカー、アクティブヘルスチェック）
トラフィック分割（デバッグルーティング、A/Bテスト、カナリアデプロイメント、ブルーグリーンデプロイメント）

しかし、「一芸に秀でた」ものを選択しなければいけないという理由はありません。ほとんどのIngressコントローラーは、トラフィックを管理する以上のことができます。Ingress コントローラーを複数の問題を解決するために使うことで、スタックのサイズと複雑さを減らすだけでなく、アプリから Ingress コントローラーに非機能的な要件をオフロードすることができるのです。

Kubernetesのデプロイメントをよりセキュアに、アジャイルに、スケーラブルにしながら、リソースをより効率的に利用するのに役立つ、従来とは異なる４つのIngressコントローラーの使用例を見ていきましょう。

モニタリングと可視性

Kubernetesクラスタに対する可視性の欠如は、本番環境における最大の課題の1つであり、トラブルシューティングと復旧を難しくする一因となっています。IngressコントローラーはKubernetesクラスタのエッジで動作し、あらゆるトラフィックに触れるため、Kubernetesクラスタやプラットフォームにおけるアプリの遅延やリソースの枯渇といった問題に対するトラブルシューティング（および回避）に役立つデータを提供できる絶好の位置に存在します。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）機能により、DevOpsユーザーがIngressリソースごとにポリシーを設定する一方で、SecOpsがリスナーごとにポリシーを適用することができます。

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で取り上げます。