NGINX Ingress Controller の詳細なサービスインサイトを活用して、より適切な意思決定を行う

2023 年 1 月に、多数の重要な新機能と強化された機能を備えたNGINX Ingress Controllerバージョン 3.0 をリリースしました。 特に価値があると思われる新機能の 1 つは、NGINX Ingress Controller の NGINX Plus エディションで利用できる Deep Service Insight です。

Deep Service Insight は、ロード バランサなどのルーティング決定システムが 1 つ以上の Kubernetes クラスタの前に配置されている場合に、最適な機能を妨げる制限、つまり、システムが Ingress コントローラの背後にあるクラスタで実行されている個々のサービスの健全性に関する情報にアクセスできないという制限に対処します。 これにより、トラフィックが正常なサービスを持つクラスタにのみルーティングされることがなくなり、ユーザーが次のような障害やエラーに遭遇する可能性がなくなります。404そして500。

Deep Service Insight は、バックエンド サービス ポッドのヘルス ステータス (NGINX Ingress Controller によって収集) を専用エンドポイントで公開し、システムがアクセスしてルーティングの決定を改善できるようにすることで、この問題を解決します。

この記事では、Deep Service Insight によって解決される問題を詳しく見ていき、一般的なユースケースでどのように機能するかを説明し、設定方法を示します。

なぜ Deep Service Insight が必要なのでしょうか?

標準の Kubernetes の稼働状況、準備状況、起動状況のプローブは、クラスターで実行されているバックエンド サービスに関する情報を提供しますが、スタック全体にわたってより適切なルーティング決定を行うために必要な洞察を得るには不十分です。 Kubernetes の導入が複雑化し、中断のない稼働時間に対するビジネス要件がさらに切迫するにつれて、適切な情報が不足することはさらに大きな問題になります。

Kubernetes 環境を拡張する際に稼働時間を改善するための一般的なアプローチは、ロードバランサー、DNS マネージャー、およびその他の自動化された意思決定システムをクラスターの前に展開することです。 ただし、Ingress コントローラーの動作の仕組み上、Kubernetes クラスターの前にあるロードバランサーは通常、クラスター内の Ingress コントローラーの背後にあるサービスに関するステータス情報にアクセスできません。Ingress コントローラー ポッド自体が正常でトラフィックを受け入れていることのみを確認できます。

一方、NGINX Ingress Controller にはサービスの健全性に関する情報があります。 HTTP 、 TCP 、 UDP 、 gRPCサービスのパッシブヘルスチェックを定期的に送信し、リクエストの応答性を監視し、成功した応答コードやその他のメトリックを追跡することで、クラスター内のアップストリームポッドのヘルスをすでに監視しています。 この情報を使用して、サービスのポッド間でトラフィックを分散する方法を決定し、一貫性のある予測可能なユーザー エクスペリエンスを提供します。 通常、NGINX Ingress Controller は、このすべての魔法をバックグラウンドで静かに実行しており、その内部で何が起こっているかについて、ユーザーが考えることはほとんどないかもしれません。 Deep Service Insight は、この貴重な情報を「表面化」させ、スタックの他のレイヤーでより効果的に使用できるようにします。

Deep Service Insight はどのように機能しますか?

Deep Service Insight は、NGINX VirtualServerおよびTransportServerカスタム リソース (それぞれ HTTP および TCP/UDP 用) を使用してデプロイするサービスで利用できます。 Deep Service Insight は、 NGINX Plus API を使用して、バックエンド サービス内の個々のポッドの NGINX Ingress Controller ビューを、Deep Service Insight 固有の専用エンドポイントで共有します。

• VirtualServerの場合 – <IP アドレス> :<ポート> /プローブ/<ホスト名>
• TransportServerの場合 – <IP アドレス> :<ポート> /プローブ/ts/<サービス名>

どこ

• <IP アドレス> NGINX Ingress Controllerに属する
• <ポート> Deep Service Insight のポート番号です (デフォルトでは 9114)
• <ホスト名> は、 スペックホスト VirtualServerリソースのフィールド
• <サービス名> は、 スペックアップストリームサービス TransportServerリソースのフィールド

出力には 2 種類の情報が含まれます。

1. ホスト名またはサービス名の HTTP ステータス コード:

   • 200 OK – 少なくとも 1 つのポッドが正常です
   • 418 私はティーポットです– ポッドは健康的ではありません
   • 404 見つかりません– 指定されたホスト名またはサービス名に一致するポッドが存在しません

2. 指定されたホスト名またはサービス名の 3 つのカウンター:

   • サービスインスタンス（ポッド）の合計数
   • 稼働中（正常）状態のポッドの数
   • 不健全な状態のポッドの数

以下は、サービスの 3 つのポッドすべてが正常な例です。

HTTP/1.1 200 OKコンテンツタイプ: application/json; charset=utf-8 日付: 日、 DD 月 YYYY hh : mm : ss TZコンテンツの長さ: 32 {"合計":3,"上昇":3,"不健康":0}

詳細については、NGINX Ingress Controller のドキュメントを参照してください。

アクティブ ヘルス チェックを構成することで、NGINX Ingress Controller がポッドが正常であると判断するために使用する基準をさらにカスタマイズできます。 ヘルスチェックが送信されるパスとポート、ポッドが異常であると判断されるために指定された期間内に発生する必要がある失敗したチェックの数、予想されるステータス コード、接続または応答の受信のタイムアウトなどを設定できます。 VirtualServerまたはTransportServerリソースにUpstream.Healthcheckフィールドを含めます。

深いサービス洞察のサンプルユースケース

Deep Service Insight が特に役立つユースケースの 1 つは、高可用性を実現するために、ロード バランサーが 2 つのクラスターで実行されているサービスにトラフィックをルーティングする場合です。 各クラスター内で、NGINX Ingress Controller は、上記のようにアップストリーム ポッドの健全性を追跡します。 Deep Service Insight を有効にすると、正常なアップストリーム ポッドと異常なアップストリーム ポッドの数に関する情報も専用のエンドポイントに公開されます。 ルーティング決定システムはエンドポイントにアクセスし、その情報を使用して、正常でないポッドから正常なポッドにアプリケーション トラフィックを転送できます。

この図は、このシナリオで Deep Service Insight がどのように機能するかを示しています。

高可用性シナリオでクラスターのメンテナンスを実行するときにも、Deep Service Insight を活用することができます。 メンテナンスを行っているクラスター内のサービスのポッドの数をゼロに減らすだけです。 正常なポッドの不足は Deep Service Insight エンドポイントに自動的に表示され、ルーティング決定システムはその情報を使用して、他のクラスター内の正常なポッドにトラフィックを送信します。 NGINX Ingress Controller またはシステムの設定を変更することなく、自動フェイルオーバーが効果的に実現され、顧客がサービスの中断を経験することはありません。

深いサービス洞察の実現

Deep Service Insight を有効にするには、Kubernetes マニフェストに-enable-service-insightコマンドライン引数を含めるか、Helm を使用している場合はserviceInsight.createパラメータをtrueに設定します。

環境に合わせてエンドポイントを調整するために含めることができるオプションの引数が 2 つあります。

• -サービスインサイトリッスンポート <ポート> – Deep Service Insightのポート番号をデフォルトの9114（<ポート> 1024～65535の範囲の整数です。 Helm で同等のものはserviceInsight.portパラメータです。
• -サービス インサイト tls 文字列 <秘密> – Deep Service InsightエンドポイントのTLS終端用のKubernetesシークレット（TLS証明書とキー）（<秘密> フォーマットの文字列です <名前空間>/<シークレット名>）。 Helm で同等のものはserviceInsight.secretパラメータです。

例： カフェアプリケーションで詳細なサービスインサイトを有効にする

Deep Service Insight の動作を確認するには、NGINX Ingress Controller ドキュメントで例としてよく使用されるCafe アプリケーションに対してこれを有効にします。

1. NGINX カスタム リソースをサポートし、Deep Service Insight を有効にする NGINX Ingress Controller の NGINX Plus エディションをインストールします。

   • Helm を使用する場合は、 serviceInsight.createパラメータをtrueに設定します。
   • Kubernetes マニフェスト(Deployment または DaemonSet) を使用する場合は、マニフェスト ファイルに-enable-service-insight引数を含めます。

2. NGINX Ingress Controller が実行されていることを確認します。

   $ kubectl get pods -n nginx-ingress NAME READY ... ingress-plus-nginx-ingress-6db8dc5c6d-cb5hp 1/1 ... ...  ステータスが年齢を再開します...  ランニング 0 9d

3. READMEの指示に従って Cafe アプリケーションをデプロイします。

4. NGINX VirtualServer カスタム リソースが Cafe アプリケーションにデプロイされていることを確認します (読みやすくするために IP アドレスは省略されています)。

   $ kubectl get vs NAME STATE HOST IP PORTS AGE cafe 有効な cafe.example.com ... [80,443] 7h1m

5. cafe.example.comで実行されている Cafe サービスのアップストリーム ポッドが 3 つあることを確認します。

   $ kubectl get pods名前 準備完了 ステータス 再起動 年齢 coffee-87cf76b96-5b85h 1/1 実行中 0 7h39m coffee-87cf76b96-lqjrp 1/1 実行中 0 7h39m tea-55bc9d5586-9z26v 1/1 実行中 0 111m

6. Deep Service Insight エンドポイントにアクセスします。

   $ カール -i <NIC_IP_アドレス>:9114/プローブ/カフェ.example.com

   の200OK応答コードは、サービスがトラフィックを受け入れる準備ができていることを示します (少なくとも 1 つのポッドが正常です)。 この場合、3 つのポッドはすべて Up 状態になります。

   HTTP/1.1 200 OK コンテンツタイプ: application/json; charset=utf-8 日付: 日、 DD 月 YYYY hh : mm : ss TZコンテンツの長さ: 32 {"合計":3,"上昇":3,"不健康":0}

   の418「I'm a teapot」ステータス コードは、サービスが利用できない (すべてのポッドが正常でない) ことを示します。

   HTTP/1.1 418 私はティーポットですContent-Type: application/json; charset=utf-8 日付: 日、 DD 月 YYYY hh : mm : ss TZコンテンツの長さ: 32 {"合計":3,"上昇":0,"不健康":3}

   の404見つからないステータス コードは、指定されたホスト名でサービスが実行されていないことを示します。

   HTTP/1.1 404 見つかりません日付: 日、 DD 月 YYYY hh : mm : ss TZコンテンツの長さ: 0

リソース

NGINX Ingress Controller リリース 3.0.0 の完全な変更ログについては、リリース ノートを参照してください。

NGINX Ingress Controller を NGINX Plus および NGINX App Protect とともに試用するには、今すぐ30 日間の無料トライアルを開始するか、弊社にお問い合わせの上、ユースケースについてご相談ください。