編集者– この投稿は、当社の包括的な電子書籍「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 つの方法があります。
この移行オプションでは、標準の Kubernetes Ingress リソースを使用してルート機能を設定し、 NGINX Ingress リソースを使用して構成を強化し、機能と使いやすさを向上させます。
NGINX Ingress リソースのカスタム リソース定義 (CRD) ( VirtualServer、VirtualServerRoute 、 TransportServer 、 GlobalConfiguration 、 Policy ) を使用すると、構成のさまざまな部分の制御をさまざまなチーム (AppDev チームやセキュリティ チームなど) に簡単に委任できるだけでなく、構成の安全性と検証も向上します。
この表は、標準の Kubernetes Ingress リソースの仕様
フィールドの SSL 終了とレイヤー 7 パスベース ルーティングの構成を、NGINX VirtualServerリソースの仕様
フィールドにマッピングしています。 2 つのリソースの構文とインデントは若干異なりますが、同じ基本的な Ingress 機能を実現します。
Kubernetes イングレス リソース | NGINX 仮想サーバー リソース |
---|---|
|
|
コミュニティ Ingress コントローラーでは、Kubernetes ConfigMap API オブジェクトがTCP および UDP サービスを公開する唯一の方法です。
NGINX Ingress Controller を使用すると、 TransportServerリソースは TCP/UDP および TLS パススルー ロード バランシングの幅広いオプションを定義します。 TransportServer リソースは、 GlobalConfigurationリソースと組み合わせて使用され、受信接続と送信接続を制御します。
詳細については、ブログの「NGINX Ingress リソースでの TCP、UDP、TLS パススルー サービスのサポート」を参照してください。
本番環境レベルの Kubernetes デプロイメントでは、多くの場合、カナリア デプロイメントやブルーグリーン デプロイメント、トラフィック スロットリング、イングレス エグレス トラフィック操作などの高度なユースケースを実装するために、基本的な Ingress ルールを拡張する必要があります。
コミュニティ Ingress コントローラーは、Kubernetesアノテーションを使用してこれらのユースケースの多くを実装します。 ただし、これらのアノテーションの多くは、非常に特殊な NGINX Ingress リソース定義に関連するカスタム Lua 拡張機能を使用して構築されているため、安定したサポートされている本番環境で高度な機能を実装するには適していません。
次のセクションでは、コミュニティ Ingress コントローラー アノテーションを NGINX Ingress コントローラー リソースに変換する方法を示します。
実稼働コンテナのワークロードに頻繁にコード変更をプッシュしながらも、既存のユーザーにサービスを提供し続ける必要があります。 カナリア デプロイメントとブルーグリーン デプロイメントを使用すると、これを実現できます。また、NGINX Ingress Controller データ プレーンでこれらを実行して、実稼働グレードの Kubernetes 環境で安定した予測可能な更新を実現できます。
この表は、カナリア デプロイメントのコミュニティ Ingress コントローラー アノテーションに対応する NGINX VirtualServer および VirtualServerRouteリソースのフィールドを示しています。
コミュニティ Ingress コントローラーは、次の優先順位でカナリア アノテーションを評価します。
nginx.ingress.kubernetes.io/canary-by-header
nginx.ingress.kubernetes.io/canary-by-cookie
nginx.ingress.kubernetes.io/canary-by-weight
NGINX Ingress Controller がそれらを同じ方法で評価するには、NGINX VirtualServer または VirtualServerRoute マニフェストにその順序で表示する必要があります。
コミュニティイングレスコントローラー | NGINX イングレス コントローラー |
---|---|
|
|
|
|
|
|
|
|
アプリケーションが本質的に短命でエラー応答を返す可能性が高くなるマイクロサービス環境では、DevOps チームは、回路遮断やレートと接続の制限などのトラフィック制御ポリシーを広範に使用して、アプリケーションが正常でない場合や期待どおりに機能しない場合にエラー状態が発生するのを防ぎます。
この表は、レート制限、カスタム HTTP エラー、カスタム デフォルト バックエンド、およびURI 書き換えのコミュニティ Ingress コントローラー アノテーションに対応する NGINX VirtualServer および VirtualServerRouteリソースのフィールドを示しています。
コミュニティイングレスコントローラー | NGINX イングレス コントローラー |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表に示されているように、この記事の執筆時点では、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 Controller で設定する必要がある他のプロキシ機能や負荷分散機能もあります。 これらの機能には、負荷分散アルゴリズムの設定、プロキシ接続のタイムアウトとバッファリング設定が含まれます。
この表は、カスタム NGINX ロード バランシング、プロキシ タイムアウト、プロキシ バッファリング、およびサービスのクラスター IP アドレスとポートへの接続のルーティングに関するコミュニティ Ingress コントローラー アノテーションに対応する、NGINX VirtualServer および VirtualServerRoute リソースのアップストリーム
フィールドのステートメントを示しています。
コミュニティイングレスコントローラー | NGINX イングレス コントローラー |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
サービス メッシュは、クラスター内の分散アプリケーションが相互認証によって安全に通信する厳格なゼロ トラスト環境で特に役立ちます。 クラスターに出入りするトラフィック (North-South トラフィック) に同じレベルのセキュリティを課す必要がある場合はどうなるでしょうか?
外部接続のエンド システムが有効な証明書を提示して相互に認証するように、Ingress Controller レイヤーで mTLS 認証を構成できます。
この表は、クライアント証明書認証とバックエンド証明書認証のコミュニティ Ingress コントローラー アノテーションに対応する NGINXポリシーリソースのフィールドを示しています。
コミュニティイングレスコントローラー | NGINX イングレス コントローラー |
---|---|
|
|
|
|
この表は、NGINX Plus に基づく NGINX Ingress コントローラー専用の NGINXポリシーリソースのフィールドを示しており、セッション永続性(アフィニティ) のコミュニティ Ingress コントローラー アノテーションに対応しています。
コミュニティイングレスコントローラー | NGINX イングレス コントローラー |
---|---|
|
|
コミュニティ Ingress コントローラーから NGINX Ingress コントローラーに移行するための 2 番目のオプションは、標準の Kubernetes Ingress リソースでアノテーションとConfigMap のみを使用し、マスター/ミニオンスタイルの処理に依存する可能性があることです。 これにより、すべての構成が Ingress オブジェクトに保持されます。
注記: この方法では、Ingress リソースのspec
フィールドを変更しないでください。
次の表は、NGINX Ingress Controller でサポートされているアノテーションに直接対応するコミュニティ Ingress Controller アノテーションの概要を示しています。
1コミュニティ Ingress コントローラは、負荷分散アルゴリズムの一部を実装するために Lua を使用します。 NGINX Ingress Controller には、これらすべてに相当するものはありません。
2HTTP トラフィックを HTTPS にリダイレクトします。 コミュニティ Ingress コントローラーはこれを Lua コードで実装しますが、NGINX Ingress コントローラーはネイティブの NGINX if
条件を使用します。
次の表は、NGINX Plus に基づく NGINX Ingress コントローラーでサポートされているアノテーションに直接対応するコミュニティ Ingress コントローラー アノテーションの概要を示しています。
コミュニティイングレスコントローラー | NGINX Plus ベースの NGINX Ingress コントローラー |
---|---|
|
|
注記: NGINX Plus をベースにした NGINX Ingress コントローラーには、アクティブ ヘルス チェックやJSON Web Token (JWT) を使用した認証など、コミュニティ Ingress コントローラーではまったくサポートされていない機能に対する追加のアノテーションがあります。
次の表は、コミュニティ Ingress コントローラー ConfigMap キーを、それに直接対応する NGINX Ingress コントローラー ConfigMap キーにマッピングします。 いくつかの ConfigMap キー名が同一であることに注意してください。 また、コミュニティ Ingress コントローラーと NGINX Ingress コントローラーの両方に、もう一方にはない ConfigMaps キーがあります (表には表示されていません)。
カスタム NGINX Ingress リソース、またはアノテーションと ConfigMap を含む標準 Kubernetes Ingress リソースを使用して、コミュニティ Ingress コントローラーから NGINX Ingress コントローラーに移行できます。 前者のオプションは、より幅広いネットワーク機能をサポートしているため、本番環境レベルの Kubernetes 環境に適しています。
この投稿は、弊社の包括的な電子書籍「F5 NGINX による Kubernetes トラフィックの管理」からの抜粋です。 実用ガイド。 今すぐ無料でダウンロードしてください。
今すぐ、NGINX Plus をベースにした NGINX Ingress Controller を30 日間の無料トライアルでお試しください。または、弊社にお問い合わせいただき、ユースケースについてご相談ください。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"