Community Ingress ControllerからF5 NGINX Ingress Controllerへの移行

NGINX | 2022年5月19日
Amir Rawdat
Amir Rawdatソリューションエンジニア

編集部 – この記事は、包括的なeBook『Managing Kubernetes Traffic with F5 NGINX: 実践ガイド』からの抜粋です。今すぐ無料でダウンロード。

Kubernetesを初めて導入する多くの組織は、Kubernetesコミュニティが開発・保守するNGINX Ingress Controller（kubernetes/ingress-nginx）から始めます。しかし、Kubernetes環境の成熟に伴い、NGINXをデータプレーンとして維持しながら、高度な機能や商用サポートが必要になる組織もあります。

選択肢の1つは、F5 NGINXが開発および保守するNGINX Ingress Controller（nginxinc/kubernetes-ingress）に移行することです。ここでは、2つのプロジェクトの違いによって生じる複雑な問題を回避できるよう、詳細な手順を説明します。

これらの選択肢の違いについては、F5のブログ記事「Ingress Controller選定ガイド、パート4：NGINX Ingress Controllerの選択肢」をご覧ください。

この記事では以降、2つのプロジェクトを区別するため、Kubernetesコミュニティが管理するNGINX Ingress Controller（kubernetes/ingress-nginx）を「コミュニティ版Ingress Controller」、F5 NGINXが管理するもの（nginxinc/kubernetes-ingress）を「NGINX Ingress Controller」と呼びます。

コミュニティ版IngressコントローラーからNGINX Ingress Controllerに移行する方法は2つあります。

オプション1：NGINX Ingressリソースを使用した移行

この移行オプションでは、標準のKubernetes Ingressリソースを使用して基本機能を設定し、NGINX Ingressリソースを使用して機能と使いやすさを向上させ、構成を強化します。

NGINX Ingressリソースのカスタムリソース定義（CRD）であるVirtualServer、VirtualServerRoute、TransportServer、GlobalConfiguration、Policyを使用すると、構成の各部分に対する制御をAppDevチームやセキュリティチームなどの異なるチームへ容易に委任できるほか、構成の安全性と検証機能を強化できます。

SSL終端とHTTPパスベースルーティングの設定

この表は、標準のKubernetes IngressリソースのspecフィールドにおけるSSL終端とレイヤー7のパスベースルーティングの設定を、NGINX specリソースのVirtualServerフィールドに対応付けています。2つのリソースでは構文とインデントが若干異なりますが、基本的なIngress機能は同じです。

Kubernetes Ingressリソース NGINX VirtualServerリソース 
apiVersion: networking.k8s.io/v1kind: Ingressmetadata:  name: nginx-testspec:  tls:    - hosts:      - foo.bar.com      secretName: tls-secret  rules:    - host: foo.bar.com      http:        paths:        - path: /login          backend:             serviceName: login-svc            servicePort: 80        - path: /billing            serviceName: billing-svc            servicePort: 80

apiVersion: networking.k8s.io/v1kind: VirtualServermetadata:  name: nginx-testspec:  host: foo.bar.com   tls:    secret: tls-secret  upstreams:    - name: login      service: login-svc      port: 80    - name: billing       service: billing-svc      port: 80  routes:   - path: /login    action:      pass: login   - path: /billing     action:       pass: billing

TCP/UDPロードバランシングとTLSパススルーの設定

コミュニティ版Ingressコントローラーでは、KubernetesのConfigMap APIオブジェクトが、TCPおよびUDPサービスを公開する唯一の方法です。

NGINX Ingress Controllerでは、TransportServerリソースで、TCP/UDPおよびTLS Passthroughの負荷分散に関する幅広いオプションを定義できます。TransportServerリソースは、GlobalConfigurationリソースと組み合わせて使用し、受信接続と送信接続を制御します。

詳細については、F5のブログ記事「NGINX IngressリソースでのTCP、UDP、TLSパススルーサービスのサポート」をご覧ください。

コミュニティ版Ingress ControllerのアノテーションをNGINX Ingress Resourcesに変換

本番環境向けのKubernetesデプロイでは、カナリアデプロイやブルーグリーンデプロイ、トラフィックのスロットリング、イングレス／エグレスのトラフィック操作など、高度なユースケースに対応するために、基本的なIngressルールの拡張が必要になることがよくあります。

コミュニティ版Ingress Controllerでは、こうしたユースケースの多くをKubernetesの「アノテーション」で実装しています。しかし、これらのアノテーションの多くは、極めて限定的なNGINX Ingressリソース定義に対応するカスタムLua拡張機能を使用して構築されています。そのため、安定性とサポートが確保された本番環境で高度な機能を実装する用途には適していません。

以降のセクションでは、コミュニティ版IngressコントローラーのアノテーションをNGINX Ingress Controllerリソースに変換する方法を説明します。

カナリアデプロイ

本番環境のコンテナワークロードにコード変更を頻繁に反映する場合でも、既存ユーザーへのサービス提供を継続する必要があります。カナリアデプロイとブルーグリーンデプロイを使用すれば、サービスを継続しながら、NGINX Ingress Controllerのデータプレーン上でデプロイを実行でき、本番運用レベルのKubernetes環境で安定した予測可能な更新を実現できます。

この表は、コミュニティ版IngressコントローラーのVirtualServerおよびVirtualServerRouteリソースにおけるカナリアデプロイ用のアノテーションに対応するフィールドを示しています。

コミュニティ版Ingressコントローラーは、次の優先順位でカナリアアノテーションを評価します。

  1. nginx.ingress.kubernetes.io/canary-by-header
  2. nginx.ingress.kubernetes.io/canary-by-cookie
  3. nginx.ingress.kubernetes.io/canary-by-weight

NGINX Ingress Controllerで同じように評価するには、NGINX VirtualServerまたはVirtualServerRouteマニフェスト内に、この順序で記述する必要があります。

Community Ingress Controller NGINX Ingress Controller 
				nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"
				
				matches:- conditions:  - header: httpHeader      value: never  action:    pass: echo   - header: httpHeader      value: always  action:    pass: echo-canaryaction:  pass: echo
				
				nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"nginx.ingress.kubernetes.io/canary-by-header-value: "my-value"
				
				matches:- conditions:  - header: httpHeader      value: my-value  action:    pass: echo-canary action:  pass: echo
				
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"
				
				matches:- conditions:  - cookie: cookieName      value: never  action:    pass: echo   - cookie: cookieName      value: always  action:    pass: echo-canaryaction:  pass: echo
				
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: "10"
				
splits:- weight: 90   action:    pass: echo- weight: 10    action:     pass: echo-canary

トラフィック制御

マイクロサービス環境では、アプリケーションは本質的に一時的な存在であり、エラーレスポンスを返す可能性が高くなります。そのためDevOpsチームは、アプリケーションが正常でない場合や想定どおりに機能していない場合にエラー状態が発生するのを防ぐため、サーキットブレーカー、レート制限、接続制限などのトラフィック制御ポリシーを幅広く活用しています。

この表は、NGINX VirtualServerおよびVirtualServerRouteリソースのフィールドのうち、コミュニティ版Ingressコントローラーの次のアノテーションに対応するものを示しています。レート制限、カスタムHTTPエラー、カスタムデフォルトバックエンド、URI書き換え。

Community Ingress Controller NGINX Ingress Controller 
nginx.ingress.kubernetes.io/custom-http-errors: "code"nginx.ingress.kubernetes.io/default-backend: "default-svc"
				
				errorPages:- codes: [code]    redirect:      code: 301      url: default-svc
				
				nginx.ingress.kubernetes.io/limit-connections: "number"
				
				http-snippets: |    limit_conn_zone $binary_remote_addr zone=zone_name:size;routes:- path: /path    location-snippets: |      limit_conn zone_name number;
				
				nginx.ingress.kubernetes.io/limit-rate: "number"nginx.ingress.kubernetes.io/limit-rate-after: "number"
				
location-snippets: |    limit_rate number;    limit_rate_after number;
				
nginx.ingress.kubernetes.io/limit-rpm: "number"nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
				
				rateLimit:    rate: numberr/m    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				
nginx.ingress.kubernetes.io/limit-rps: "number"nginx.ingress.kubernetes.io/limit-burst-multiplier: "multiplier"
				
rateLimit:    rate: numberr/s    burst: number * multiplier    key: ${binary_remote_addr}    zoneSize: size
				
				nginx.ingress.kubernetes.io/limit-whitelist: "CIDR"
				
				http-snippets: |server-snippets: |
				
nginx.ingress.kubernetes.io/rewrite-target: "URI"
				
rewritePath: "URI"

表に示すとおり、本稿執筆時点では、NGINX Ingressリソースに以下の4つのCommunity Ingress Controllerアノテーションを直接変換するフィールドはないため、スニペットを使用する必要があります。この4つのアノテーションをPolicyリソースで直接サポートする機能は、NGINX Ingress Controllerの今後のリリースで提供される予定です。

  • nginx.ingress.kubernetes.io/limit-connections
  • nginx.ingress.kubernetes.io/limit-rate
  • nginx.ingress.kubernetes.io/limit-rate-after
  • nginx.ingress.kubernetes.io/limit-whitelist

ヘッダー操作

HTTPヘッダーには、HTTPトランザクションに関与するシステムにとって重要かつ関連性の高い追加情報が含まれているため、多くのユースケースでHTTPヘッダーの操作が役立ちます。たとえば、コミュニティ版Ingressコントローラーでは、クロスオリジンリソース共有（CORS）ヘッダーを有効化して設定できます。CORSヘッダーは、ブラウザーのフロントエンドJavaScriptコードからバックエンドアプリケーションまたはWebサーバーに接続するAJAXアプリケーションで使用されます。

次の表は、NGINX VirtualServerおよびVirtualServerRouteリソースのフィールドのうち、コミュニティ版Ingressコントローラーのヘッダー操作用アノテーションに対応するものを示しています。

Community Ingress Controller NGINX Ingress Controller 
				nginx.ingress.kubernetes.io/enable-cors: "true"nginx.ingress.kubernetes.io/cors-allow-credentials: "true"nginx.ingress.kubernetes.io/cors-allow-headers: "X-Forwarded-For" nginx.ingress.kubernetes.io/cors-allow-methods: "PUT, GET, POST, OPTIONS"nginx.ingress.kubernetes.io/cors-allow-origin: "*"nginx.ingress.kubernetes.io/cors-max-age: "seconds"
				
				responseHeaders:  add:     - name: Access-Control-Allow-Credentials      value: "true"     - name: Access-Control-Allow-Headers      value: "X-Forwarded-For"    - name: Access-Control-Allow-Methods      value: "PUT, GET, POST, OPTIONS"    - name: Access-Control-Allow-Origin      value: "*"    - name: Access-Control-Max-Age      value: "seconds"

プロキシと負荷分散

具体的なユースケースに応じて、NGINX Ingress Controllerでその他のプロキシ機能や負荷分散機能を設定することもできます。これらの機能には、負荷分散アルゴリズムの指定に加え、プロキシ接続のタイムアウトやバッファリングの設定が含まれます。

この表は、upstreamフィールドにあるステートメントのうち、コミュニティ版Ingress Controllerの次のアノテーションに対応するNGINX VirtualServerおよびVirtualServerRouteリソースのステートメントを示しています。NGINXロードバランシングのカスタマイズ、プロキシのタイムアウト、プロキシのバッファリング、およびサービスのCluster IPアドレスとポートへの接続のルーティング。

コミュニティ版Ingress Controller NGINX Ingress Controller 
nginx.ingress.kubernetes.io/load-balance
				
				lb-method
				
				nginx.ingress.kubernetes.io/proxy-buffering
				
buffering
				
				nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size
				
				buffers
				
				nginx.ingress.kubernetes.io/proxy-connect-timeout
				
				connect-timeout
				
				nginx.ingress.kubernetes.io/proxy-next-upstream
				
				next-upstream
				
				nginx.ingress.kubernetes.io/proxy-next-upstream-timeout
				
				next-upstream-timeout
				
				nginx.ingress.kubernetes.io/proxy-read-timeout
				
read-timeout
				
				nginx.ingress.kubernetes.io/proxy-send-timeout
				
				send-timeout
				
				nginx.ingress.kubernetes.io/service-upstream
				
				use-cluster-ip

mTLS認証

A サービスメッシュは、厳格なゼロトラスト環境で特に有用です。この環境では、クラスター内の分散アプリケーションが相互認証によって安全に通信します。では、クラスターに出入りするトラフィック（南北トラフィック）にも同等のセキュリティを適用する必要がある場合は、どうすればよいでしょうか。

Ingress ControllerレイヤーでmTLS認証を設定すると、外部接続のエンドシステムが有効な証明書を提示し、相互に認証できるようになります。

この表は、NGINX Policyリソースのフィールドのうち、コミュニティ版Ingress Controllerのアノテーションである「クライアント証明書認証」および「バックエンド証明書認証」に対応するものを示しています。

コミュニティ版Ingress Controller NGINX Ingress Controller 
				nginx.ingress.kubernetes.io/auth-tls-secret: secretNamenginx.ingress.kubernetes.io/auth-tls-verify-client: "on"nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
				
				ingressMTLS:   clientCertSecret: secretName   verifyClient: "on"   verifyDepth: 1
				
nginx.ingress.kubernetes.io/proxy-ssl-secret: "secretName"nginx.ingress.kubernetes.io/proxy-ssl-verify: "on|off"nginx.ingress.kubernetes.io/proxy-ssl-verify-depth: "1"nginx.ingress.kubernetes.io/proxy-ssl-protocols: "TLSv1.2"nginx.ingress.kubernetes.io/proxy-ssl-ciphers: "DEFAULT"nginx.ingress.kubernetes.io/proxy-ssl-name: "server-name"nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on|off"
				
egressMTLS:   tlsSecret: secretName   verifyServer: true|false   verifyDepth: 1   protocols: TLSv1.2   ciphers: DEFAULT   sslName: server-name   serverName: true|false

セッション永続化（NGINX Plus限定）

この表は、NGINX Policyリソースのフィールドのうち、NGINX PlusベースのNGINX Ingress Controllerでのみ使用でき、コミュニティ版Ingress Controllerのセッション永続化（アフィニティ）アノテーションに対応するものを示しています。

コミュニティ版Ingress Controller NGINX Ingress Controller 
nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookieName"nginx.ingress.kubernetes.io/session-cookie-expires: "x"nginx.ingress.kubernetes.io/session-cookie-path: "/route"nginx.ingress.kubernetes.io/session-cookie-secure: "true"
				
sessionCookie:  enable: true  name: cookieName  expires: xh  path: /route  secure: true

オプション2：Kubernetes Ingressリソースを使用して移行

コミュニティ版IngressコントローラーからNGINX Ingress Controllerに移行する2つ目の方法は、標準のKubernetes IngressリソースでアノテーションとConfigMapのみを使用し、必要に応じてmaster/minion方式の処理を利用することです。これにより、すべての設定をIngressオブジェクト内に保持できます。

注：この方法では、Ingressリソースのspecフィールドを変更しないでください。

アノテーションを使用した高度な設定

次の表は、NGINX Ingress Controllerがサポートするアノテーションに直接対応する、コミュニティ版Ingressコントローラーのアノテーションを示しています。

Community Ingress Controller NGINX Ingress Controller NGINX Directive
N/A
Default:

 

				random two least_conn
				
nginx.org/rewrites: "serviceName=svc rewrite=URI"
N/A
N/A2

1コミュニティ版Ingressコントローラーでは、一部の負荷分散アルゴリズムの実装にLuaを使用しています。NGINX Ingress Controllerには、それらすべてに相当する機能があるわけではありません。

2HTTPトラフィックをHTTPSにリダイレクトします。コミュニティ版IngressコントローラーではLuaコードで実装していますが、NGINX Ingress ControllerではNGINXネイティブの「if」条件を使用します。

次の表は、NGINX PlusベースのNGINX Ingress Controllerでサポートされるアノテーションに直接対応する、コミュニティ版Ingressコントローラーのアノテーションを示しています。

コミュニティ版Ingress Controller NGINX PlusベースのNGINX Ingress Controller 
				nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"

注：NGINX PlusベースのNGINX Ingress Controllerには、コミュニティ版Ingress Controllerではまったくサポートされていない機能向けの追加アノテーションがあります。これには、アクティブヘルスチェックや、JSON Web Tokenを使用した認証（JWT）などが含まれます。

ConfigMapによるグローバル設定

次の表は、コミュニティ版Ingress ControllerのConfigMapキーと、それぞれに直接対応するNGINX Ingress ControllerのConfigMapキーの対応関係を示しています。一部のConfigMapキー名は同一です。また、コミュニティ版Ingress ControllerとNGINX Ingress Controllerには、それぞれ相手側にはないConfigMapキーもあります（表には記載していません）。

Community Ingress ControllerNGINX Ingress Controller
disable-access-log
access-log-off
error-log-level
error-log-level
hsts
hsts
hsts-include-subdomains
hsts-include-subdomains
hsts-max-age
hsts-max-age
http-snippet
http-snippets
keep-alive
keepalive-timeout
keep-alive-requests
keepalive-requests
load-balance
lb-method
location-snippet
location-snippets
log-format-escape-json: "true"
log-format-escaping: "json"
log-format-stream
stream-log-format
log-format-upstream
log-format
main-snippet
main-snippets
max-worker-connections 
worker-connections
max-worker-open-files
worker-rlimit-nofile
proxy-body-size
client-max-body-size
proxy-buffering
proxy-buffering
proxy-buffers-number: "number"proxy-buffer-size: "size"
proxy-buffers: number size
proxy-connect-timeout
proxy-connect-timeout
proxy-read-timeout
proxy-read-timeout
proxy-send-timeout
proxy-send-timeout
server-name-hash-bucket-size
server-names-hash-bucket-size
server-name-hash-max-size
server-names-hash-max-size
server-snippet
server-snippets
server-tokens
server-tokens
ssl-ciphers
ssl-ciphers
ssl-dh-param
ssl-dhparam-file
ssl-protocols
ssl-protocols
ssl-redirect
ssl-redirect
upstream-keepalive-connections
keepalive
use-http2
http2
use-proxy-protocol
proxy-protocol
variables-hash-bucket-size
variables-hash-bucket-size
worker-cpu-affinity
worker-cpu-affinity
worker-processes
worker-processes
worker-shutdown-timeout
worker-shutdown-timeout

まとめ

カスタムのNGINX Ingressリソース、またはアノテーションとConfigMapを使用する標準のKubernetes Ingressリソースのいずれかを使用して、コミュニティ版IngressコントローラーからNGINX Ingress Controllerに移行できます。前者は、より幅広いネットワーク機能をサポートしているため、本番環境レベルのKubernetes環境により適しています。

この記事は、包括的なeBook『Managing Kubernetes Traffic with F5 NGINX: A Practical Guide』からの抜粋です。今すぐ無料でダウンロード。

NGINX PlusベースのNGINX Ingress Controllerを、30日間の無料トライアルで今すぐお試しいただくか、ユースケースについてご相談ください。

共有
注目のブログ記事
クラウドネイティブ技術、プラットフォームエンジニアリング、AIの最新トレンドF5 NGINX OneによるアプリとAPIデリバリーのライフサイクル全体の管理モダンアプリケーションデリバリをシンプルに：F5 NGINX Oneの9か月
タグ： F5 NGINX, Tech, Kubernetes (k8S), F5 NGINX Ingress Controller, Learn, BIG-IP Container Ingress Services, Networking for Kubernetes, BIG-IP Next for Kubernetes, F5 Distributed Cloud Load Balancer & K8s Gateway

著者について

Amir Rawdat
Amir Rawdatソリューションエンジニア

Amir Rawdatのその他のブログ記事

関連するブログ記事

チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する
NGINX | 2024/01/18

チュートリアル：NGINXを使用してアプリケーション向けにOpenTelemetryを構成する

OpenTelemetryを使用してNGINXサーバーの状態と健全性をより明確に把握することで、問題のトラブルシューティングを行い、Webアプリケーションのパフォーマンスを向上できます。

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正
NGINX | 2023/05/31

AkitaのNGINX Plus認定モジュールでAPIエンドポイントの問題を特定・修正

Akita SoftwareのAPIオブザーバビリティ向け新しいNGINX Plus Certified Moduleを活用して、APIエンドポイントの問題をより迅速に特定し、修正できます。

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法
NGINX | 2023/02/09

JavaプロジェクトをスキャフォールディングしてKubernetesネイティブアプリを構築する方法

Red HatのシニアプリンシパルデベロッパーアドボケイトであるDaniel Oh氏が、Javaプロジェクトをゼロから構築するためのひな形を作成し、Kubernetesネイティブアプリケーションとしてビルドする方法を解説します。

F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング
NGINX | 2022/05/24

F5 NGINXaaS for Azureのご紹介：Microsoft Azureでネイティブに利用できるSaaS型ロードバランシング

NGINXaaS for Azureは、NGINX PlusをAzureネイティブのSaaSとして利用できるサービスです。NGINXの設定を容易にリフト＆シフトできるため、クラウド導入とモダンアプリの展開を加速できます。

SELinuxでNGINXおよびNGINX Plusを使用する
NGINX | 2018/08/17

SELinuxでNGINXおよびNGINX Plusを使用する

Red Hat Enterprise Linux（RHEL）および関連ディストリビューションでSecurity-Enhanced Linux（SELinux）を有効にすると、デフォルト設定によりNGINXとNGINX Plusの一部の操作が制限されます。この記事では、すべての機能を利用できるようにSELinuxの設定を変更する方法について説明します。

NGINX PlusによるAWS Auto Scalingグループの負荷分散
NGINX | 2017/03/06

NGINX PlusによるAWS Auto Scalingグループの負荷分散

新しいnginx-asg-sync統合ソフトウェアにより、NGINX PlusはAWS Auto Scalingグループの負荷を直接分散できるため、クラウドでの負荷分散がさらに柔軟になります

実行環境を問わず、あらゆるアプリケーションとAPIを提供し、保護します
F5は、現代のデジタルビジネスが運用される複雑な環境全体で、アプリケーションとAPIの高速性、可用性、セキュリティを維持します。F5 Application Delivery and Security Platformの詳細はこちらをご覧ください。
F5とつながる