KubernetesでNGINXIngress Controllerを使うメリットとは

NGINX Ingress Controller for Kubernetes 1.8がリリースされました。本リリースは、Red Hat OpenShift、Amazon Elastic Container Service for Kubernetes（EKS）、Azure Kubernetes Service（AKS）、Google Kubernetes Engine（GKE）、IBM Cloud Private、DiamantiなどのKubernetesプラットフォームでのIngressリソース向けに設計されています。

リリース1.8は、パワフルでありながら、柔軟で使いやすいIngress Controllerが引き続き提供され、Kubernetes IngressリソースとNGINX Ingressリソースの両方で構成できます。

• Kubernetes Ingressリソースは、Ingress Controllerの実装全体にわたって最大の互換性を実現します。また、アノテーション とカスタムテンプレートを使用して拡張でき、高度な構成を生成できます。
• NGINX Ingressリソースは、一般のKubernetes Ingressリソースをカスタマイズする場合よりも機能が豊富で、NGINX固有のコンフィグスキームを提供します。

リリース1.8では、主に次の機能強化および機能改善が行われています。

• NGINX App Protectとの統合 – NGINX App Protectは、NGINXベースの主要なアプリケーションセキュリティソリューションであり、高度なシグネチャと構造的な保護をWebアプリケーションにもたらします。
• NGINX Ingressリソースの拡張 – NGINX Ingressリソースを使用したいと考えているものの、VirtualServer/VirtualServerRouteリソースで現在公開されていないNGINX機能のカスタマイズが必要なユーザーのために、コンフィグスニペットとカスタムテンプレートという2つの補完的なメカニズムがサポートされるようになりました。
• URI書き換えと、リクエスト/レスポンスヘッダーの修正 – アップストリームに渡されるリクエスト/レスポンスのヘッダー、およびクライアントに戻される同ヘッダーに対して、詳細な制御（追加、削除）が可能になります。
• ポリシーと、IPアドレスのアクセス制御リスト – ポリシーを使用することで、さまざまなチームが複数の場所で定義および適用できる個別のKubernetesオブジェクト内に、トラフィック管理機能を集約させることができるようになります。アクセス制御リスト（ACL）は、NGINX Ingress Controllerを通過する送受信ネットワークトラフィックをフィルタリングするために使用できます。

• その他の新機能 –

  • Readiness Probe
  • VirtualServer/VirtualServerRouteリソースとHelmチャートにおける複数のIngress Controllerのサポート
  • VirtualServer/VirtualServerRouteリソースのステータス情報の表示
  • Red Hat OpenShift向けNGINX Ingress Operatorのアップデート

NGINX Ingress Controller for Kubernetesとは

NGINX Ingress Controller for Kubernetesは、Kubernetes環境でNGINX Open SourceまたはNGINX Plusと一緒に実行されるデーモンです。このデーモンは、Kubernetes IngressリソースとNGINX Ingressリソースリソースを監視して、Ingressロードバランシングが必要なサービスリクエストを検出します。次に、このデーモンは自動的にNGINXまたはNGINX Plusを構成し、サービスに対してトラフィックのルーティングおよびロードバランシングを行います。

複数のNGINX Ingress Controller実装パターンがあります。オフィシャル版のNGINX実装は、高性能で、本番環境ですぐに利用でき、長期的なデプロイメントに適しています。NGINXは、エンタープライズスケールでデプロイできる機能を提供し、新しいリリースにおいても安定して動作するように注力しています。NGINX Plusのサブスクライバーは、追加費用なしで包括的なテクニカルサポートを利用できます。NGINX Open Sourceユーザーは、NGINXが重点的に取り組んでいる安定した動作と充実したサポートのメリットを享受できます。

NGINX Ingress Controller 1.8の新機能

NGINX App Protectとの統合

デジタルトランスフォーメーションを積極的に加速させる企業が増えるにつれ、アプリケーションに対する攻撃も増加しています。複雑さを増した新たな脆弱性攻撃が毎日のように登場しています。NGINX App Protectは、ネットワークファイアウォールやウイルス対策ソリューションとは異なり、インテリジェントなWebアプリケーションファイアウォール（WAF）として悪意のある攻撃を効果的かつ迅速に防御します。

リリース1.8では、NGINX Ingress Controller内にNGINX App Protectを組み込み、使い慣れたKubernetes APIを使用してApp Protectのセキュリティポリシーと構成を管理できるようになりました。

この統合ソリューションにより、次の3つのメリットが実現します。

• アプリケーションの境界保護 – 優れたアーキテクチャーを持つKubernetesデプロイメントにおいて、Ingress Controllerは、Kubernetes内で実行されているサービスへのデータプレーントラフィックの唯一のエントリーポイントとして、セキュリティプロキシをデプロイするのに最適な場所となります。
• データプレーンの統合 – Ingress Controller内にWAFを組み込むことで、個別のWAFデバイスが不要になります。これにより、複雑さを緩和させ、コストを削減し、障害点を減らすことができます。
• コントロールプレーンの統合 – Kubernetes APIでWAFの構成を管理することで、CI/CDプロセスの自動化が非常に容易になります。NGINX Ingress Controllerの構成は、Kubernetesのロールベースのアクセス制御（RBAC）のプラクティスに準拠しているため、WAFの構成をDevSecOps専任チームに安全に任せることができます。

NGINX Ingress ControllerでのNGINX App Protectの構成とトラブルシューティングの詳細については、Ingress Controllerのドキュメントを参照してください。App Protectのその他のユースケースについては、NGINX App Protectのドキュメントを参照してください。

NGINX Ingress ControllerのDockerイメージにApp Protectを適用するには、NGINX PlusとNGINX App Protectのサブスクリプションが必要です。

スニペットとカスタムテンプレートによるNGINX Ingressリソースの拡張

これまでのリリースでは、コンフィグスニペットやカスタムテンプレートを使用して、標準のKubernetes IngressリソースにNGINX設定を入れ込むことができました。コンフィグスニペットを使用すると、ほとんどのNGINX設定コンテキストにNGINXネイティブ機能を割り当てられるようになります。カスタムテンプレートを使用すると、デフォルトサーバなど、NGINX設定のその他のブロックを生成し、それらをConfigMapsで適用できるようになります。リリース1.8では、コンフィグスニペットとカスタムテンプレートの使用範囲が拡張され、NGINX Ingressリソース（VirtualServerおよびVirtualServerRoute）にも利用できるようになりました。

スニペットとカスタムテンプレートのどちらを使用しても、管理者は標準のKubernetes IngressリソースとNGINX Ingressリソースで公開されていないユースケースや機能の設定をどちらでも実装できます。特に重要なユースケースとして、Kubernetesへ移行させることによって、すでにNGINXでプロキシが設定されている非Kubernetesアプリケーションを刷新する場合が挙げられます。この場合、スニペットやカスタムテンプレートを使用すると、コンテンツキャッシュやレート制限といった、NGINX Ingressリソースにはまだ実装されていないNGINX機能を継続して使用できるようになります。

以下のサンプル構成では、異なるNGINX設定コンテキストにコンフィグスニペットを使用して、キャッシングとレート制限を構成する方法を示しています。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
  namespace: cafe
spec:
  http-snippets: |
    limit_req_zone $binary_remote_addr zone=mylimit:10m rate=1r/s;
    proxy_cache_path /tmp keys_zone=one:10m;
  host: cafe.example.com
  tls:
    secret: cafe-secret
  server-snippets: |
    limit_req zone=mylimit burst=20;
  upstreams:
  - name: tea
    service: tea-svc
    port: 80
  - name: coffee
    service: coffee-svc
    port: 80
  routes:
  - path: /tea
    location-snippets: |
      proxy_cache one;
      proxy_cache_valid 200 10m;
    action:
      pass: tea
  - path: /coffee
    action:
      pass: coffee

コンフィグスニペットやカスタムテンプレートの品質を入念にチェックすることが重要です。無効なコンフィグスニペットやテンプレートを使用すると、NGINX設定が適用できなくなります。この場合、トラフィック処理は中断されませんが（NGINXは既存の有効な構成で実行を継続します）、安定性を高めるために、以下のような追加のメカニズムも利用できます。

• コンフィグスニペットの有効/無効のグローバル設定。

URI書き換えと、リクエスト/レスポンスヘッダーの修正

リリース1.8では、アップストリーム接続とダウンストリーム接続の両方で、URI書き換えと、リクエスト/レスポンスヘッダーの修正が可能になりました。これは、フィルタリングと修正レイヤーを追加することで、エンドユーザーをバックエンドから本質的に切り離します。この機能は、VirtualServer/VirtualServerRouteリソースで直接利用し、特定のパスに対して構成できるようになりました。

URI書き換えや、リクエスト/レスポンスヘッダーの修正が可能になったため、本番環境での信頼性に関する予期せぬ問題に素早く対処できるようになり、バックエンドの開発者がトラブルシューティングやコードの書き換えを行う必要がなくなりました。これにより、Kubernetesでのアプリケーションワークロードの可用性、セキュリティ、回復力が向上します。

一般的なユースケースは、以下のとおりです。

• URI書き換え – アプリケーションコードで公開されているものとは異なるパスでアプリケーションを公開したい管理者が利用します。例えば、アプリケーションを外部には/coffee URIで公開し、Ingress Controllerではアプリケーションのバックエンドでリッスンしているルート（/）のURIにリクエストを変換させることができます。
• キャッシング – キャッシングヘッダーを適切に設定できないことがあるアプリケーション開発者が利用する。管理者はヘッダーの修正を使用して、デプロイされているアプリケーションのヘッダーにパッチを適用できます。

ヘッダー修正とURI書き換えは、VirtualServerまたはVirtualServerRouteのproxyアクションの下で構成します。ここはリクエストがアップストリームに渡されるところです。

以下のサンプル構成では、Ingress Controllerが/teaパスのクライアントリクエストをプロキシ経由させるときに、リクエストをアップストリームに転送する前にContent-Typeのリクエストヘッダーを変更します。また、/tea URIを、rewritePathフィールドで指定されているように、/に書き換えます。サーバーのレスポンスをクライアントに返す前に、Ingress Controllerは新たにAccess-Control-Allow-Originヘッダーを追加し、それ以外のいくつかのヘッダーについても、非表示にする、無視する、渡すなどを設定していします。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  upstreams:
  - name: tea
    service: tea-svc
    port: 80
  - name: coffee
    service: coffee-svc
    port: 80
  routes:
  - path: /tea
    action:
      proxy:
        upstream: tea
        requestHeaders:
          pass: true
          set:
          - name: Content-Type
            value: application/json
        responseHeaders:
          add:
          - name: Access-Control-Allow-Origin
            value: "*"
            always: true
          hide:
          - x-internal-version
          ignore:
          - Expires
          - Set-Cookie
          pass:
          - Server
        rewritePath: /
  - path: /coffee
    action:
      pass: coffee

以下のサンプル構成では、条件が一致したときにヘッダー操作とURI書き換えをactionブロックに組み込むことで、さらに高度なトラフィック処理を実現する方法を示しています。

apiVersion: k8s.nginx.org/v1
kind: VirtualServer
metadata:
  name: cafe
spec:
  host: cafe.example.com
  upstreams:
  - name: tea
    service: tea-svc
    port: 80
  - name: tea-post
    service: tea-post-svc
    port: 80
  routes:
  - path: /tea
    matches:
    - conditions:
      - variable: $request_method
        value: POST
      action:
        proxy:
          upstream: tea-post
          requestHeaders:
            pass: true
            set:
            - name: Content-Type
              value: application/json
          rewritePath: /
    action:
      pass: tea

ポリシーと、IPアドレスのアクセス制御リスト

多くの組織において、複数のチームの連携によりアプリケーションデリバリーが行われています。たとえば、NetOpsはポートの開放とトラフィックのフィルタリングを担当し、SecOpsは一貫したセキュリティ態勢を確保し、複数のアプリケーションオーナーは多数のバックエンドアプリケーションサービスに対してIngressロードバランシングポリシーをプロビジョニングしたりしています。

組織ごとに異なる方法でロールを委任していても、NGINX Ingress Controllerでは、構成の特定部分を所有するチームに定義することで、最大限の柔軟性を提供し、また全てを組み立てて実行することも可能です。これにより、管理者の委任を可能な限り簡素化しながら、マルチテナントがサポートされます。

マルチテナントのサポートにより、NGINX Ingress Controllerリリース1.8.では、ポリシーが導入されました。最初にサポートされたポリシーのタイプは、IPアドレスベースのアクセス制御リスト（ACL）です。

• ポリシーを使用することで、さまざまなチームが複数の場所で定義および適用できる個別のKubernetesオブジェクト内に、トラフィック管理機能を抽象化させることができるようになります。これは、NGINX Ingress Controllerをこれまでよりも容易かつ自然に構成する方法であり、タイプセーフ、委任、マルチテナント、カプセル化、構成の簡素化、再利用性、信頼性など、多くのメリットをもたらします。
• IPアドレスベースのACLを使用することで、ネットワークトラフィックをフィルタリングし、特定のIngressリソースへのアクセスを許可または拒否するIPアドレス（またはCIDR表記で定義されたIPアドレスのグループ）を正確に制御できます。

注：リリース1.8では、ポリシーが参照されるのはVirtualServerリソース内のみあり、その場合はserverコンテキストにポリシーが適用されます。将来のリリースでは、ポリシーサポートをVirtualServerRouteリソースにも拡張する予定であり、その場合はlocationコンテキストにポリシーが適用されます。また、レート制限などその他の機能についてもポリシーを実装していく予定です。

下図は、ポリシーの使用方法を説明したものです。左側のVirtualServerリソースは、webapp-policyという名前のポリシーを参照し、右側の構成スニペットはそれぞれ10.0.0.0.0/8サブネットからの接続をフィルタリング（許可または拒否）する同名のポリシーを定義します。両方のポリシーに名前を割り当てるということは、Kubernetes APIを使用してVirtualServerに対象ポリシーを適用することで、ポリシーの切り替えができるということです。

その他の新機能

Readiness Probe

多くのIngressリソース（標準のKubernetes、NGINX、またはその両方）がある環境では、NGINX構成が完全にロードされる前にPodがオンラインになり、トラフィックのブラックホール化を引き起こす可能性があります。本番環境レベルの信頼性を実現するための取り組みの一環として、リリース1.8では、Kubernetes Readiness Probeが導入されました。これにより、Ingress Controllerがトラフィックを受け入れる準備が整うまで（つまり、NGINX構成がロードされ、保留になっているリロードがない状態になるまで）、トラフィックは特定のPodに転送されません。

NGINX IngressとHelmチャートにおける複数のIngress Controllerのサポート

これまでのリリースでは、NGINX Ingress Controllerの複数のインスタンスを同一クラスター上に共存させることが可能でしたが、標準のKubernetes Ingressリソースでkubernetes.io/ingress.classアノテーションを使用して対象のNGINX Ingress Controllerデプロイメントを指定した場合に限られていました。リリース1.8では、VirtualServer/VirtualServerRouteリソースにingressClassNameフィールドを追加して、これらのリソースでも同じことができるようにしました。また、複数のNGINX Ingress Controllerデプロイメントをサポートするように、Helmチャートをアップデートしました。

VirtualServer/VirtualServerRouteリソースのステータス表示

kubectl describeコマンドからの出力では、Ingress Controllerの構成が正常に更新されたかどうかを示し（Eventsセクション）、外部エンドポイントのIPアドレスとポートのリストを表示します（Statusセクション）。リリース1.8.0では、VirtualServer/VirtualServerRouteリソースでこの情報を示すよう拡張しました。VirtualServerRouteリソースでは、Statusセクションに、親のVirtualServerリソースの名前も表示されます。

プリオーナーの場合、VirtualServerRouteリソースの親であるVirtualServerが削除され、アプリケーションにアクセスできなくなっている可能性があります。その場合は、関連するVirtualServer/VirtualServerRouteリソースに対してkubectl describeコマンドを発行することで、トラブルシューティングできます。

以下のサンプルコマンドは、cafeのVirtualServerの構成が正常に適用されたことを示しています。これは、EventsセクションのTypeにNormal、ReasonにAddedorUpdatedと表示されていることでわかります。

$ kubectl describe vs cafe
. . .
Events:
  Type    Reason          Age   From                      Message
  ----    ------          ----  ----                      -------
  Normal  AddedOrUpdated  16s   nginx-ingress-controller  Configuration for default/cafe was added or updated

以下のサンプルコマンドは、cafeのVirtualServerの構成が無効として拒否されたことを示しています。これは、EventsセクションのTypeにWarning、ReasonにRejectedと表示されていることでわかります。理由として、teaという名前のアップストリームが2つあったことが示されています。

$ kubectl describe vs cafe
. . .
Events:
  Type     Reason    Age   From                      Message
  ----     ------    ----  ----                      -------
  Warning  Rejected  12s   nginx-ingress-controller  VirtualServer default/cafe
is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"

出力のStatusセクションでは、各外部エンドポイントのIPアドレスとポートと一緒に、MessageとReasonのフィールドに、Eventsセクションと同じ情報が表示されます。

$ kubectl describe vs cafe
. . .
Status:
  External Endpoints:
    Ip:        12.13.23.123
    Ports:     [80,443]
  Message:  VirtualServer default/cafe is invalid and was rejected: spec.upstreams[1].name: Duplicate value: "tea"
  Reason:   Rejected

Red Hat OpenShift向けNGINX Ingress Operatorのアップデート

• ポリシー – NGINX Ingress Controller Operatorを活用して、エンドユーザーごとにポリシーをデプロイできるようになりました。
• App Protectによるスケーリング管理 – Operatorを使用して、同一デプロイメント内のすべてのインスタンスがトラフィックを検査するように、App ProtectでNGINX Ingress Controllerのスケーリングを管理できるようになりました。

参考資料

リリース1.8.の詳細な変更点については、リリースノートを参照してください。

是非この機会に、無料トライアル（30日間）をお試しください。NGINX Ingress Controller for KubernetesとNGINX Plusをお使いいただけます。また、その他ご質問などはこちらからご相談ください。

NGINX Open SourceでNGINX Ingress Controllerをご利用の場合は、リリースソースコードを入手するか、DockerHubからビルド済みのコンテナをダウンロードしてください。