ブログ | NGINX

コミュニティ イングレス コントローラから F5 NGINX イングレス コントローラへの移行

アミール・ラウダットのサムネイル
アミール・ラウダット
2022年5月19日公開

編集者– この投稿は、当社の包括的な電子書籍「F5 NGINX による Kubernetes トラフィックの管理」からの抜粋です。 実用ガイド。 今すぐ無料でダウンロードしてください。

Kubernetes を初めてセットアップする多くの組織は、Kubernetes コミュニティによって開発および保守されている NGINX Ingress コントローラー ( kubernetes/ingress-nginx ) から始めます。 しかし、Kubernetes の導入が成熟するにつれて、一部の組織では、NGINX をデータ プレーンとして維持しながら、高度な機能が必要になったり、商用サポートが必要になったりするようになります。

1 つの選択肢は、F5 NGINX ( nginxinc/kubernetes-ingress ) によって開発および保守されている NGINX Ingress Controller に移行することです。ここでは、2 つのプロジェクト間の違いから生じるいくつかの複雑さを回避できるように、完全な手順を示します。

これらのオプションの違いがよくわかりませんか? Ingress コントローラーの選択ガイド、パート 4 をお読みください。 NGINX Ingress コントローラー オプション 私たちのブログで。

この投稿の残りの部分では、2 つのプロジェクトを区別するために、Kubernetes コミュニティによって管理されている NGINX Ingress Controller ( kubernetes/ingress-nginx ) を「コミュニティ Ingress コントローラー」と呼び、F5 NGINX によって管理されている NGINX Ingress Controller ( nginxinc/kubernetes-ingress ) を「NGINX Ingress コントローラー」と呼びます。

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

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

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

NGINX Ingress リソースのカスタム リソース定義 (CRD) ( VirtualServer、VirtualServerRoute 、 TransportServer 、 GlobalConfiguration 、 Policy ) を使用すると、構成のさまざまな部分の制御をさまざまなチーム (AppDev チームやセキュリティ チームなど) に簡単に委任できるだけでなく、構成の安全性と検証も向上します。

SSL ターミネーションと HTTP パスベース ルーティングの構成

この表は、標準の Kubernetes Ingress リソースの仕様フィールドの SSL 終了とレイヤー 7 パスベース ルーティングの構成を、NGINX VirtualServerリソースの仕様フィールドにマッピングしています。 2 つのリソースの構文とインデントは若干異なりますが、同じ基本的な Ingress 機能を実現します。

Kubernetes イングレス リソース NGINX 仮想サーバー リソース 
apiVersion: networking.k8s.io/v1kind: Ingress
metadata:
  name: nginx-test
spec:
  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: VirtualServer
metadata:
  name: nginx-test
spec:
  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 パススルー ロード バランシングの幅広いオプションを定義します。 TransportServer リソースは、 GlobalConfigurationリソースと組み合わせて使用され、受信接続と送信接続を制御します。

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

コミュニティ Ingress コントローラーのアノテーションを NGINX Ingress リソースに変換する

本番環境レベルの Kubernetes デプロイメントでは、多くの場合、カナリア デプロイメントやブルーグリーン デプロイメント、トラフィック スロットリング、イングレス エグレス トラフィック操作などの高度なユースケースを実装するために、基本的な Ingress ルールを拡張する必要があります。

コミュニティ Ingress コントローラーは、Kubernetesアノテーションを使用してこれらのユースケースの多くを実装します。 ただし、これらのアノテーションの多くは、非常に特殊な NGINX Ingress リソース定義に関連するカスタム Lua 拡張機能を使用して構築されているため、安定したサポートされている本番環境で高度な機能を実装するには適していません。

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

カナリアデプロイメント

実稼働コンテナのワークロードに頻繁にコード変更をプッシュしながらも、既存のユーザーにサービスを提供し続ける必要があります。 カナリア デプロイメントとブルーグリーン デプロイメントを使用すると、これを実現できます。また、NGINX Ingress Controller データ プレーンでこれらを実行して、実稼働グレードの Kubernetes 環境で安定した予測可能な更新を実現できます。

この表は、カナリア デプロイメントのコミュニティ Ingress コントローラー アノテーションに対応する NGINX 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 マニフェストにその順序で表示する必要があります。

コミュニティイングレスコントローラー 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-canary
action:
  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-canary
action:
  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 チームは、回路遮断やレートと接続の制限などのトラフィック制御ポリシーを広範に使用して、アプリケーションが正常でない場合や期待どおりに機能しない場合にエラー状態が発生するのを防ぎます。

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

コミュニティイングレスコントローラー 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 つのコミュニティ Ingress コントローラー アノテーションを直接翻訳するフィールドが含まれていないため、スニペットを使用する必要があります。 NGINX Ingress Controller の将来のリリースでは、ポリシーリソースを使用した 4 つのアノテーションの直接サポートが計画されています。

  • 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 コントローラは、ブラウザのフロントエンド JavaScript コードがバックエンド アプリまたは Web サーバーに接続する AJAX アプリケーションで使用されるクロスオリジン リソース共有(CORS) ヘッダーの有効化と設定をサポートしています。

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

コミュニティイングレスコントローラー 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 で設定する必要がある他のプロキシ機能や負荷分散機能もあります。 これらの機能には、負荷分散アルゴリズムの設定、プロキシ接続のタイムアウトとバッファリング設定が含まれます。

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

コミュニティイングレスコントローラー 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認証

サービス メッシュは、クラスター内の分散アプリケーションが相互認証によって安全に通信する厳格なゼロ トラスト環境で特に役立ちます。 クラスターに出入りするトラフィック (North-South トラフィック) に同じレベルのセキュリティを課す必要がある場合はどうなるでしょうか?

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

この表は、クライアント証明書認証とバックエンド証明書認証のコミュニティ Ingress コントローラー アノテーションに対応する NGINXポリシーリソースのフィールドを示しています。

コミュニティイングレスコントローラー NGINX Ingress Controller 

nginx.ingress.kubernetes.io/auth-tls-secret: secretName
nginx.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 Plus に基づく NGINX Ingress コントローラー専用の NGINXポリシーリソースのフィールドを示しており、セッション永続性(アフィニティ) のコミュニティ Ingress コントローラー アノテーションに対応しています。

コミュニティイングレスコントローラー 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 コントローラーに移行するための 2 番目のオプションは、標準の Kubernetes Ingress リソースでアノテーションとConfigMap のみを使用し、マスター/ミニオンスタイルの処理に依存する可能性があることです。 これにより、すべての構成が Ingress オブジェクトに保持されます。

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

注釈による高度な設定

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

コミュニティイングレスコントローラー NGINX Ingress Controller NGINX ディレクティブ 
nginx.ingress.kubernetes.io/configuration-snippet: |

nginx.org/location-snippets: |
該当なし 
nginx.ingress.kubernetes.io/load-balance1

nginx.org/lb-method
デフォルト：

 

random two least_conn

nginx.ingress.kubernetes.io/proxy-buffering: "on|off"

nginx.org/proxy-buffering: "True|False"

proxy_buffering

nginx.ingress.kubernetes.io/proxy-buffers-number: "number"nginx.ingress.kubernetes.io/proxy-buffer-size: "xk"

nginx.org/proxy-buffers: "number 4k|8k"nginx.org/proxy-buffer-size: "4k|8k"

proxy_buffers
proxy_buffer_size

nginx.ingress.kubernetes.io/proxy-connect-timeout: "seconds"

nginx.org/proxy-connect-timeout: : "secondss"

proxy_connect_timeout

nginx.ingress.kubernetes.io/proxy-read-timeout: "seconds"

nginx.org/proxy-read-timeout: "secondss"

proxy_read_timeout

nginx.ingress.kubernetes.io/proxy-send-timeout: "seconds"

nginx.org/proxy-send-timeout: "secondss"

proxy_send_timeout

nginx.ingress.kubernetes.io/rewrite-target: "URI"

nginx.org/rewrites: "serviceName=svc rewrite=URI"

rewrite

nginx.ingress.kubernetes.io/server-snippet: |

nginx.org/server-snippets: |
該当なし 
nginx.ingress.kubernetes.io/ssl-redirect: "true|false"

ingress.kubernetes.io/ssl-redirect: "True|False"
該当なし2

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

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

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

コミュニティイングレスコントローラー NGINX Plus ベースの NGINX Ingress コントローラー 
nginx.ingress.kubernetes.io/affinity: "cookie"nginx.ingress.kubernetes.io/session-cookie-name: "cookie_name"
nginx.ingress.kubernetes.io/session-cookie-expires: "seconds"
nginx.ingress.kubernetes.io/session-cookie-path: "/route"

nginx.com/sticky-cookie-services: "serviceName=example-svc cookie_name expires=time path=/route"

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

ConfigMaps によるグローバル構成

次の表は、コミュニティ Ingress コントローラー ConfigMap キーを、それに直接対応する NGINX Ingress コントローラー ConfigMap キーにマッピングします。 いくつかの ConfigMap キー名が同一であることに注意してください。 また、コミュニティ Ingress コントローラーと NGINX Ingress コントローラーの両方に、もう一方にはない ConfigMaps キーがあります (表には表示されていません)。

コミュニティイングレスコントローラー NGINX 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 コントローラーに移行できます。 前者のオプションは、より幅広いネットワーク機能をサポートしているため、本番環境レベルの Kubernetes 環境に適しています。

この投稿は、弊社の包括的な電子書籍「F5 NGINX による Kubernetes トラフィックの管理」からの抜粋です。 実用ガイド。 今すぐ無料でダウンロードしてください。

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

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 q。"