ブログ | NGINX

NGINX Ingress コントローラー バージョン 2.0: 知っておくべきこと

NGINX-F5 水平黒タイプ RGB の一部
ブライアン・エラート サムネイル
ブライアン・エラート
2021年12月27日公開

10 月に、F5 NGINX Ingress Controller バージョン 2.0 ( nginxinc/kubernetes-ingress )をリリースし、 Kubernetes 1.22とIngress APIバージョン 1 ( networking.k8s.io/v1 ) のサポートを追加しました。 あなたは疑問に思うかもしれません –だから何？

「だから何？」という問いには微妙なニュアンスがあり、次の 3 つの相互に関連する質問に答えることで答えます。

答えについては、このまま読み進めてください。また、2022 年 1 月 11 日の「Kubernetes バージョンの攻撃に対する戦闘計画」もご覧ください。

Kubernetes のリリースが重要な理由

この質問に対する答えは単純ですが複雑です。 Kubernetes の互換性管理は、Kubernetes オペレーターが次の3 つのカテゴリのバージョン管理を管理する必要があるため、困難です。

  1. Kubernetes プラットフォーム自体– 新しいリリースごとに、Kubernetes チームは古いバージョンのメンテナンスを停止します。 このようなバージョンを引き続き使用すると、リスク管理戦略に問題が生じ、Kubernetes チームからのサポートが利用できなくなるため、トラブルシューティングが難しくなります。 現在、Kubernetes プロジェクトは、最新の 3 つのマイナー リリース (1.20、1.21、1.22) のリリース ブランチを管理しています。 Kubernetes 1.19 以降では約 1 年間のパッチ サポートが提供され、1.18 以前は約 9 か月間のパッチ サポートが提供されます。 (1.18 以前のリリース期間が短いのは、Kubernetes が現在の 3 回ではなく、以前は年に 4 回リリースされていたためです)。

  2. Kubernetes API – Kubernetes のリリースごとに新しい API が誕生し、古い API が廃止されます。また、API の変更は対応するリソースとツールに影響を及ぼします。 Kubernetes プラットフォームをアップグレードする場合、API もアップグレードする必要がある可能性があります。

  3. Kubernetes にデプロイしたツール– Kubernetes またはその API に大きな変更が加えられると、Ingress コントローラーなどのツールと対応するリソースが引き続き適切に機能するかどうかに影響する可能性があります。

したがって、Kubernetes 用、Ingress API 用、NGINX Ingress Controller 用の 3 つのタイムラインを追跡する必要があります。 Kubernetes が壊れないようにするには、Kubernetes バージョンが API および NGINX Ingress Controller と互換性のある最適な状態を見つける必要があります。 互換性を確認せずに 3 つのコンポーネントのいずれかをアップグレードすると、重大な結果を招く可能性があります。 3 つのコンポーネントすべてが互いに互換性がない場合は、おめでとうございます。アプリが壊れてしまいます。

Ingress API とは何ですか? networking.k8s.io/v1が重要なのはなぜですか?

Ingress API を使用すると、Ingress コントローラーが Kubernetes アプリを安全に公開できるようになります。 networking.k8s.io/v1 API（別名 Ingress API v1) は Kubernetes 1.19 で導入されました。 当時、Kubernetes はv1beta1とv1 の両方をサポートしており、一方のバージョンをもう一方のバージョンとして自動的に表示していました。 API バージョンのこの「内部的な」互換性は運用上はメリットがありますが、計画作業の妨げになることもあります。

Kubernetes 1.22 のリリースにより、 v1 がIngress API の唯一のバージョンになりました。これは重要なことです。Ingress API v1 が「唯一の」バージョンになると、すべてのベータ バージョン ( extensions/v1beta1およびnetworking.k8s.io/v1beta1 ) が非推奨になるからです。 これは、Ingress API v1 をまだ導入していない組織にとっては混乱を招きますが、NGINX ではこの変更を良い兆候と捉えています。 Ingress API がベータ版から昇格したことは、成熟した完全に実現された API への進歩を意味します。では、この変更が重要なのはなぜでしょうか? そうですね、それはバージョン管理に関係します。 既存のクラスターを Kubernetes 1.22 にアップグレードしたが、 v1beta1 のIngress 関連リソースを引き続き使用している場合、Ingress リソースが壊れてしまいます。おめでとうございます。

NGINX Ingress Controller 2.0 は現在の顧客にどのような影響を与えますか?

NGINX Ingress Controller は Ingress API と密接に結合されているため、 v1のリリースは製品として、そしてお客様である皆様に大きな影響を与えました。そのため、NGINX Ingress Controller のバージョン番号を 1. xから 2. xに上げました。 NGINX Ingress Controller 2.0 を再設計して Ingress API v1 を活用し、Kubernetes 1.22 と完全に互換性を持たせました。

NGINX Ingress Controller を使用する場合は、Kubernetes、Ingress リソース、または NGINX Ingress Controller が破損しないように、バージョンに依存するいくつかのアクションをすぐに実行する必要があります。

  • Kubernetes 1.18 以前:

    • 利用可能な機能セットを最大限に活用できるように、NGINX Ingress Controller 1.12 を使用していることを確認してください。 (NGINX Ingress Controller 2.0 にアップグレードする場合は、Kubernetes 1.19 以降にもアップグレードする必要があります。)

    • Kubernetes 1.18 は次回の Kubernetes リリース以降はサポートされなくなるため、今後数か月以内に Kubernetes (および NGINX Ingress Controller) の新しいバージョンに移行する計画を立ててください。

  • Kubernetes 1.19～1.21:

    • NGINX Ingress Controller 2.0 にアップグレードします。

    • Ingress 関連のリソースをnetworking.k8s.io/v1にまだ移行していない場合 ( NGINX Ingress Controller 2.0 リリース ノートを参照)、今すぐプランを作成してください。 Kubernetes 1.19～1.21 は、Ingress API の現在のすべてのバージョン ( v1beta1とv1 の両方) をサポートしており、その場で変換することができます。

    • まだ行っていない場合は、Ingress および IngressClass リソースをすぐにnetworking.k8s.io/v1に移動してください。

      • Ingress リソースで非推奨のkubernetes.io/ingress.classアノテーションを使用している場合は、 ingressClassNameフィールドに切り替えることをお勧めします。

      • 更新を計画するには、ドキュメントと例( networking.k8s.io/v1および Ingress リソースのingressClassNameフィールドで利用可能) を使用してください。

  • Kubernetes 1.22:

    • NGINX Ingress Controller の以前のバージョンは Kubernetes 1.22 と互換性がなく、Ingress API v1 をサポートしていないため、NGINX Ingress Controller 2.0 がすでに実行されていることを確認してください。

NGINX Ingress コントローラーの (それほどでもない) 簡単な歴史

2016 年の最初のリリース以来、NGINX Ingress Controller は初期のツールから Kubernetes ネットワーキングの強力なツールへと成長しました。 発売から現在までの進化をご紹介します。

2016 ( v0.5.0 )

NGINX エンジニアの Michael Pleshakov が GitHub リポジトリ( nginxinc/kubernetes-ingress )に最初のエントリを公開し、NGINX とF5 NGINX Plus をKubernetes Ingress コントローラー (KIC) として使用できるようにしました。

NGINX Ingress Controller がKubeCon EU 2016で初めて公開されました。 録音をご覧ください: 1 日目、NGINX を使用して Kubernetes 用の高度な負荷分散ソリューションを作成する、 KubeCon EU 2016 。

2017 ( v1.0.0 )

このプロジェクトは、 NGINX Plus ベースのバージョンでの JSON Web Token (JWT) の主要サポートを含む、本番環境対応を実現します。

NGINX Conf 2017 で、Michael Pleshakov は、 「Kubernetes 上の負荷分散アプリケーション用の Ingress コントローラーとしての NGINX Plus の使用」で、高度な負荷分散を含む実稼働機能を紹介します。

2018

NGINX Ingress Controller では、可視性、使いやすさ、柔軟性の面で大きな機能強化が実現されています。

  • 5 月 ( v1.2.0 ) – プロジェクトは新しいNGINX Plus APIを採用し、 nginx-ingressイメージは公式のNGINX Docker Hubに移行します。 このバージョンでは、gRPC、パッシブ ヘルス チェック、Helm チャート、Prometheus のサポートが導入されました。
  • 8 月 ( v1.3.0 ) – NGINX Plus のお客様は、メトリックを Prometheus にエクスポートしてアクティブ ヘルス チェックを利用できるようになり、Helm チャート、マージ可能な Ingress リソース、カスタム テンプレートの管理の容易化の改善など、すべてのユーザーがメリットを享受できます ( 「NGINX Ingress Controller for Kubernetes リリース 1.3.0 の発表」を参照)。
  • 11 月 ( v1.4.0 ) – TCP/UDP のサポートが追加され、レイヤー 4 トラフィック管理が可能になりました。 その他の機能としては、カスタム アノテーションの開発が容易になったことや、Random with Two Choices ロード バランシング アルゴリズムのサポートなどが挙げられます ( 「NGINX Ingress Controller for Kubernetes リリース 1.4.0 の発表」を参照)。

NGINX Conf 2018 で、Michael Pleshakov が「NGINX を Kubernetes Ingress コントローラーとして使用する」のステージに登壇し、Helm を使用して NGINX Ingress コントローラーをデプロイする方法、HTTP および TCP/UDP の負荷分散を構成する方法、Prometheus を使用して監視する方法、トラブルシューティングを行う方法を紹介します。

2019

標準の Kubernetes Ingress リソースに代わるリソースを導入し、高度な機能の実行をより簡単かつ信頼性高く行えるようになりました。

「NGINX Ingress Controller の次世代」では、Michael Pleshakov が NGINX Conf 2019 に戻り、ブルーグリーン デプロイメントや A/B テストなどのユースケース向けの VS/VSR を紹介します。

2020

NGINX Ingress リソースに対する数多くの機能強化に加えて、今年の主なテーマはエコシステム ツールと NGINX 製品との統合です。

  • 4 月 ( v1.7.0 ) – OpenShift 4.x環境に NGINX Ingress Controller をデプロイするための高速で簡単な認定済みの方法を提供するために、NGINX Ingress Operator をリリースしました。 NGINX Ingress リソースは、追加のプロトコル、サーキット ブレーカー、検証とレポートの改善のサポートにより、引き続き拡大しています ( 「NGINX Ingress Controller for Kubernetes リリース 1.7.0 の発表」を参照)。
  • 7 月 ( v1.8.0 ) – F5 NGINX App Protect WAFとの統合により、顧客は Ingress コントローラーと同じコンテナーに軽量で柔軟な WAF を導入できるようになります。 スニペットまたはカスタム テンプレートによる NGINX Ingress リソースのカスタマイズが追加され、URI 書き換えやアクセス制御リストなどの機能により、よりきめ細かい制御が可能になります ( 「Kubernetes 向け NGINX Ingress コントローラー リリース 1.8.0 の発表」を参照)。
  • 10 月 ( v1.9.0 ) – F5 NGINX Service Meshとの統合により、同じ構成で南北および東西のトラフィックを管理できるようになりました。 履歴データを簡単に視覚化できるように Grafana ダッシュボードが追加されました ( 「NGINX Ingress Controller リリース 1.9.0 の発表」を参照)。

「NGINX と OpenShiftを使用した本番環境アプリのセキュリティ保護」では、テクニカル マーケティング エンジニアの Amir Rawdat が、NGINX Ingress Operator の使用方法、ロールベースのアクセス制御 (RBAC) を活用した機能横断的なプロビジョニングの方法、NGINX App Protect を使用したコンテナー化されたアプリのセキュリティ保護の方法、JWT を使用したクライアントの検証の方法を紹介します。

2021

セキュリティは、エコシステムのさらなる統合とともに主要なテーマです。

NGINX Sprint 2.0セッション「エンドツーエンドの暗号化によるマイクロサービスのマスター」では、ソフトウェア エンジニアの Aidan Carson が、NGINX Ingress Controller を使用してエッジを保護し、NGINX Service Mesh を使用してサービス間の安全なアクセス制御を設定し、両方の製品を使用して mTLS で出力トラフィックを保護する方法を紹介します。

次のステップ: NGINX Ingress Controllerを試す

オープンソースの Ingress コントローラーがアプリに最適な選択であると判断した場合は、 GitHub リポジトリにある NGINX オープンソース ベースの NGINX Ingress コントローラーをすぐに使い始めることができます。

大規模な本番環境の展開には、NGINX Plus をベースにした商用の NGINX Ingress Controller をぜひお試しください。 NGINX App Protect を含む30 日間の無料トライアルをご利用いただけます。

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

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