Ingress Controller選定ガイド第1回：要件の特定

NGINX | 2021年9月08日

編集者 – この記事は全10回のシリーズの一部です：

一連のブログ記事をまとめた無料のeBookもダウンロードできます。『Kubernetesをテスト環境から本番環境へ』

組織がKubernetesを初めて試す際には、Ingressコントローラーの選択についてあまり深く検討しないことがよくあります。どのIngressコントローラーも同じだと考え、迅速に稼働させるために、選択したKubernetesフレームワークのデフォルトのIngressコントローラーをそのまま使用するのが最も簡単だと判断する場合があります。実際、テスト環境やトラフィック量の少ない本番環境であれば、ほぼどのIngressコントローラーでも問題ありません。しかし、規模が拡大するにつれて、Ingressコントローラーの選択はより重要になります。Ingressコントローラーは、トラフィックをポイントAからポイントBへ転送するという基本機能をはるかに超える機能を提供できるためです。

高度なトラフィック管理から可視化、組み込みのセキュリティまで、IngressコントローラーはKubernetesスタックで最も強力なツールの1つになり得ます。実際、F5 NGINXでは、あらゆる本番環境レベルのKubernetesデプロイメントの基盤になると考えています。しかし、多くの開発者やPlatform Opsチームは、Ingressコントローラーが持つ能力を十分に理解しておらず、スケーリングできないものを選択した場合の影響も認識していません。十分にスケーリングできない、または複雑な環境を保護できないIngressコントローラーを選ぶと、Kubernetesをテスト段階から本番環境へ移行できなくなる可能性があります。このブログシリーズでは、Ingressコントローラーの基礎を解説するとともに、現在および将来に必要な機能とセキュリティを提供できるIngressコントローラーを適切に選択する方法をご紹介します。

Ingress Controllerとは？

Ingressコントローラーは、Kubernetesクラスターに流入するレイヤー4および7のトラフィックと、場合によってはクラスターから流出するトラフィックを管理する専用のロードバランサーです。認識を統一するため、NGINXで使用している用語を以下に示します（業界全体でもほぼ同じです）。

Ingressトラフィック – Kubernetesクラスターに入るトラフィック
Egressトラフィック – Kubernetesクラスターから送出されるトラフィック
ノースサウストラフィック – Kubernetesクラスターに出入りするトラフィック（「イングレス・エグレストラフィック」とも呼ばれます）
East‑westトラフィック – Kubernetesクラスター内のサービス間を移動するトラフィック（「service-to-serviceトラフィック」とも呼ばれます）
サービスメッシュ – サービス間トラフィックのルーティングとセキュリティ確保に使用するトラフィック管理ツール

Ingress Controllerが必要な理由

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

Kubernetesサービスへの外部アクセスを提供する必要がある場合は、Ingressリソースを作成し、URIパス、バックエンドサービス名などの接続ルールを定義します。ただし、Ingressリソースは単独では機能しません。Ingressリソースで定義したルールを実装するには、Ingressコントローラーアプリケーションを（Kubernetes APIを使用して）デプロイし、設定する必要があります。

Ingressコントローラーの役割

Kubernetes環境外からのトラフィックを受け入れ、必要に応じて変更（シェーピング）し、環境内で実行されているPodに分散します。Ingressコントローラーは、デフォルトの「kube-proxy」トラフィック分散モデルに代わり、Kubernetes以外の環境でアプリケーションデリバリーコントローラー（ADC）やリバースプロキシが提供するような追加の制御機能を利用できるようにします。
サービスを構成する個々のPodを監視し、インテリジェントなルーティングを保証するとともに、リクエストが「ブラックホール化」されるのを防ぎます。
エグレスルールを実装し、相互TLS（mTLS）によってセキュリティを強化するか、特定のPodから指定した外部サービスへの送信トラフィックを制限します。

Ingressコントローラーを選定する際、まず機能一覧に目を向けたくなるかもしれません。しかし、それでは優れた機能を備えていても、ビジネスニーズを満たさないIngressコントローラーを選んでしまう可能性があります。そこで、チームやアプリにとってIngressコントローラーがどの程度有効に機能するかを左右する2つの要素、つまりユースケース（どのような課題を解決するか）とリソース確保（そのためのコストをどのように負担するか）を必ず検討してください。このブログの残りの部分では、この2つのトピックについて説明します。

Ingress Controllerで解決したい課題

Ingressコントローラーの中核的なユースケースはトラフィック管理です。そのため、一般的な次のユースケースのうち、1つ以上に対応することが求められるでしょう。

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

しかし、「1つの機能しかない」ものに妥協する必要はありません。ほとんどのIngressコントローラーは、トラフィック管理以外にも活用できます。Ingressコントローラーで複数の課題に対処することで、スタックの規模と複雑さを軽減できるだけでなく、非機能要件をアプリからIngressコントローラーにオフロードすることも可能です。ここでは、リソースをより効率的に活用しながら、Kubernetesデプロイメントのセキュリティ、俊敏性、拡張性の向上に役立つ、従来とは異なるIngressコントローラーの4つのユースケースをご紹介します。

監視と可視性

Kubernetesクラスターの可視性不足は、本番環境における最大の課題の1つであり、トラブルシューティングを困難にし、レジリエンスにも影響します。IngressコントローラーはKubernetesクラスターのエッジで動作し、すべてのトラフィックを処理するため、アプリケーションの遅延とKubernetesクラスターまたはプラットフォームのリソース枯渇という2つの一般的な問題のトラブルシューティング（さらには回避）に役立つデータを提供するのに適しています。可視性を向上させるには、Ingressコントローラーに次の機能が必要です。

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

API Gateway

Kubernetesでリクエストとレスポンスを操作する必要がない限り、IngressコントローラーをAPIゲートウェイとして兼用できる可能性は非常に高いでしょう。機能セットによっては、IngressコントローラーでTLS終端、クライアント認証、レート制限、きめ細かなアクセス制御、レイヤー4～7でのリクエストルーティングなど、APIゲートウェイの中核機能を提供できる場合があります。

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

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

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

Web Application Firewallとの統合

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

Ingressコントローラーのリソースをどのように確保するか

どのIngressコントローラーにもコストがかかります。無料のオープンソースであっても例外ではありません（「子犬のような無料」という表現を聞いたことがあるかもしれません）。予算の項目として金額を予測できるコストもあれば、選択したIngressコントローラーに伴う複雑性の増大や移植性の欠如などへの対応に、チームがどれだけの時間を費やす必要があるかによって変わるコストもあります。Ingressコントローラーの予算を策定する際に考慮すべき、時間と費用の両面のコストを見ていきましょう。

時間コストの予算化

人員に関する予算策定は、固定費項目の場合よりもはるかに難しいことがあります。特に、経験のない分野のプロジェクトに必要な人員を確保しようとする場合はなおさらです。次のような点を検討する必要があります。

Ingressコントローラーの設定と管理は誰が担当しますか。それは本来の業務の一部（たとえば、プラットフォーム運用チームのメンバーとして）ですか。それとも、開発者が追加の業務として担当しますか。
従業員が正式なトレーニングを受ける時間を確保できますか？それとも、実務を通じて短期間で容易に習得できるほどシンプルなツールである必要がありますか？
新機能が必要になるたびに従業員に試行錯誤させたり、問題が発生した際のトラブルシューティングに多くの時間を費やさせたりする余裕はありますか。それとも、ほかの形でビジネス価値を生み出す業務に注力してもらう必要がありますか。

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

業界では、ツールとその管理責任をNetOpsチームの管轄下に集約する傾向が見られます。これはスタックの簡素化とセキュリティの向上に大きく貢献しますが、F5は、チームの目標に応じてツールを慎重に重複させることを推奨します。外部ロードバランサーなどの境界領域のツールは、プラットフォーム全体を担当する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プロキシを使用する予定であり、ツールに付属する可能性のあるバンドルサービスが不要な場合は、インスタンス単位の料金体系が適しています。