ブログ | NGINX

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

NGINX-F5 水平黒タイプ RGB の一部
アミール・ラウダットのサムネイル
アミール・ラウダット
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 仮想サーバー リソース 
APIバージョン: networking.k8s.io/v1kind: Ingress
メタデータ:
名前: nginx-test
仕様:
tls:
- ホスト:
- foo.bar.com
secretName: tls-secret
ルール:
- ホスト: foo.bar.com
http:
パス:
- パス: /login
バックエンド: 
サービス名: login-svc
サービスポート: 80
- パス: /billing
サービス名: billing-svc
サービスポート: 80

APIバージョン: networking.k8s.io/v1kind: VirtualServer
メタデータ:
名前: nginx-test
仕様:
ホスト: foo.bar.com
tls:
シークレット: tls-secret
アップストリーム:
-名前: login
サービス: login-svc
ポート: 80
- 名前: billing
サービス: billing-svc
ポート: 80
ルート: 
- パス: /login
アクション: 
パス: login 
- パス: /billing 
アクション: 
パス: 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 イングレス コントローラー 
nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-header: "httpHeader"

一致:- 条件: - ヘッダー: httpHeader 値: never アクション: pass: echo - ヘッダー: httpHeader 値: always アクション: pass: echo-canary アクション: 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 "

一致:- 条件: - ヘッダー: httpHeader 値: my-valueアクション: pass: echo-canary アクション: pass: echo

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-by-cookie: "cookieName"

一致:- 条件:
- クッキー: cookieName
値: never
アクション:
pass: echo
- クッキー: cookieName
値: always
アクション:
pass: echo-canary
アクション:
pass: echo

nginx.ingress.kubernetes.io/canary: "true"nginx.ingress.kubernetes.io/canary-weight: 「10」

スプリット:- 重量: 90 アクション: パス: エコー - 重み: 10 アクション: パス: エコーカナリア

交通管制

アプリケーションが本質的に短命でエラー応答を返す可能性が高くなるマイクロサービス環境では、DevOps チームは、回路遮断やレートと接続の制限などのトラフィック制御ポリシーを広範に使用して、アプリケーションが正常でない場合や期待どおりに機能しない場合にエラー状態が発生するのを防ぎます。

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

コミュニティイングレスコントローラー NGINX イングレス コントローラー 
nginx.ingress.kubernetes.io/custom-http-errors: "コード" nginx.ingress.kubernetes.io/default-backend: "default-svc"

errorPages :- コード: [コード] リダイレクト: コード: 301 URL: デフォルトSVC

nginx.ingress.kubernetes.io/limit-connections: "数値"

http-snippets : | limit_conn_zone $binary_remote_addr zone= zone_name : size ; ルート: - パス: /パス場所-snippets : | limit_conn zone_name number ;

nginx.ingress.kubernetes.io/limit-rate: "数値" nginx.ingress.kubernetes.io/limit-rate-after: "数値"

ロケーション スニペット: | limit_rate数値; limit_rate_after数値;

nginx.ingress.kubernetes.io/limit-rpm: "数値" nginx.ingress.kubernetes.io/limit-burst-multiplier: "乗数"

rateLimit : レート:数値r/m バースト:数値*乗数キー: ${binary_remote_addr} ゾーンサイズ:サイズ

nginx.ingress.kubernetes.io/limit-rps: "数値" nginx.ingress.kubernetes.io/limit-burst-multiplier: "乗数"

rateLimit: レート:数値r/s バースト:数値*乗数キー: ${binary_remote_addr} ゾーンサイズ:サイズ

nginx.ingress.kubernetes.io/limit-whitelist: 「 CIDR 」

http スニペット: |サーバー スニペット: |

nginx.ingress.kubernetes.io/rewrite-target: 「 URI 」

書き換えパス: 「 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 イングレス コントローラー 
nginx.ingress.kubernetes.io/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、オプション」 nginx.ingress.kubernetes.io/cors-allow-origin: "*" nginx.ingress.kubernetes.io/cors-max-age: "秒"

レスポンスヘッダー: 追加: - 名前: Access-Control-Allow-Credentials 値: "true" - 名前: Access-Control-Allow-Headers 値: 「X-Forwarded-For」 - 名前: Access-Control-Allow-Methods 値: 「PUT、GET、POST、OPTIONS」 - 名前: Access-Control-Allow-Origin 値: "*" - 名前: Access-Control-Max-Age 値: "秒"

プロキシと負荷分散

特定のユースケースに応じて、NGINX Ingress Controller で設定する必要がある他のプロキシ機能や負荷分散機能もあります。 これらの機能には、負荷分散アルゴリズムの設定、プロキシ接続のタイムアウトとバッファリング設定が含まれます。

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

コミュニティイングレスコントローラー NGINX イングレス コントローラー 
nginx.ingress.kubernetes.io/load-balance

lbメソッド

nginx.ingress.kubernetes.io/proxy-buffering

バッファリング

nginx.ingress.kubernetes.io/proxy-buffers-numbernginx.ingress.kubernetes.io/proxy-buffer-size

バッファ

nginx.ingress.kubernetes.io/proxy-connect-timeout

接続タイムアウト

nginx.ingress.kubernetes.io/proxy-next-upstream

次の上流

nginx.ingress.kubernetes.io/proxy-next-upstream-timeout

次のアップストリームタイムアウト

nginx.ingress.kubernetes.io/proxy-read-timeout

読み取りタイムアウト

nginx.ingress.kubernetes.io/proxy-send-timeout

送信タイムアウト

nginx.ingress.kubernetes.io/service-upstream

クラスターIPを使用する

mTLS認証

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

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

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

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

nginx.ingress.kubernetes.io/auth-tls-secret: secretName
nginx.ingress.kubernetes.io/auth-tls-verify-client: "オン"
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: 「デフォルト」
nginx.ingress.kubernetes.io/proxy-ssl-name: 「サーバー名」
nginx.ingress.kubernetes.io/proxy-ssl-server-name: 「オン|オフ」

egressMTLS : tlsSecret: secretName verifyServer: true|false verifyDepth: 1 プロトコル: TLSv1.2 暗号: デフォルト sslName: サーバー名 serverName: true|false

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

この表は、NGINX Plus に基づく NGINX Ingress コントローラー専用の NGINXポリシーリソースのフィールドを示しており、セッション永続性(アフィニティ) のコミュニティ Ingress コントローラー アノテーションに対応しています。

コミュニティイングレスコントローラー NGINX イングレス コントローラー 
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 : 有効: true 名前: cookieName 有効期限: x h パス: /route セキュア: true

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

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

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

注釈による高度な設定

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

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

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

nginx.org/lb-メソッド
デフォルト：

 

ランダム2つのleast_conn

nginx.ingress.kubernetes.io/プロキシバッファリング: "オン|オフ"

nginx.org/プロキシバッファリング: 「真|偽」

プロキシバッファリング

nginx.ingress.kubernetes.io/プロキシ バッファ数: "数値" nginx.ingress.kubernetes.io/プロキシ バッファサイズ: " xk "

nginx.org/proxy-buffers : "数値4k|8k" nginx.org/proxy-buffer-size : 「4k|8k」

proxy_buffersプロキシ_buffer_size

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

nginx.org/proxy-connect-timeout: : "秒s"

プロキシ接続タイムアウト

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

nginx.org/proxy-read-timeout : "秒s"

プロキシ読み取りタイムアウト

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

nginx.org/proxy-send-timeout : "秒s"

プロキシ送信タイムアウト

nginx.ingress.kubernetes.io/rewrite-target : 「 URI 」

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

リライト

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

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

ingress.kubernetes.io/ssl-redirect : 「真|偽」
該当なし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 : "秒" 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 イングレス コントローラー 
アクセスログを無効にする

アクセスログオフ

エラーログレベル

エラーログレベル

hsts

hsts

hsts サブドメインを含める

hsts サブドメインを含める

hsts 最大年齢

hsts 最大年齢

http スニペット

http スニペット

キープアライブ

キープアライブタイムアウト

キープアライブリクエスト

キープアライブリクエスト

負荷分散

lbメソッド

場所スニペット

場所スニペット

ログ形式のエスケープ JSON : "true"

ログ形式のエスケープ: "json"

ログ形式ストリーム

ストリームログ形式

ログフォーマットアップストリーム

ログ形式

メインスニペット

メインスニペット

最大ワーカー接続数 

労働者のつながり

ワーカーがオープンできるファイルの最大数

ワーカー制限なしファイル

プロキシ本体のサイズ

クライアントの最大ボディサイズ

プロキシバッファリング

プロキシバッファリング

プロキシ バッファ数: "数"プロキシ バッファ サイズ: "サイズ"

プロキシバッファ:数値サイズ

プロキシ接続タイムアウト

プロキシ接続タイムアウト

プロキシ読み取りタイムアウト

プロキシ読み取りタイムアウト

プロキシ送信タイムアウト

プロキシ送信タイムアウト

サーバー名ハッシュバケットサイズ

サーバー名ハッシュバケットサイズ

サーバー名ハッシュ最大サイズ

サーバー名ハッシュ最大サイズ

サーバースニペット

サーバースニペット

サーバートークン

サーバートークン

SSL暗号

SSL暗号

ssl-dh-パラメータ

ssl-dhparam-ファイル

SSL プロトコル

SSL プロトコル

SSLリダイレクト

SSLリダイレクト

アップストリームキープアライブ接続

キープアライブ

http2 を使用する

2 番目

プロキシプロトコルを使用する

プロキシプロトコル

変数ハッシュバケットサイズ

変数ハッシュバケットサイズ

ワーカーCPUアフィニティ

ワーカーCPUアフィニティ

ワーカープロセス

ワーカープロセス

ワーカーシャットダウンタイムアウト

ワーカーシャットダウンタイムアウト

まとめ

カスタム 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 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"