10 月に、F5 NGINX Ingress Controller バージョン 2.0 ( nginxinc/kubernetes-ingress )をリリースし、 Kubernetes 1.22とIngress APIバージョン 1 ( networking.k8s.io/v1
) のサポートを追加しました。 あなたは疑問に思うかもしれません –だから何?
「だから何?」という問いには微妙なニュアンスがあり、次の 3 つの相互に関連する質問に答えることで答えます。
networking.k8s.io/v1
へのアップグレードが重要なのはなぜですか?答えについては、このまま読み進めてください。また、2022 年 1 月 11 日の「Kubernetes バージョンの攻撃に対する戦闘計画」もご覧ください。
この質問に対する答えは単純ですが複雑です。 Kubernetes の互換性管理は、Kubernetes オペレーターが次の3 つのカテゴリのバージョン管理を管理する必要があるため、困難です。
Kubernetes プラットフォーム自体– 新しいリリースごとに、Kubernetes チームは古いバージョンのメンテナンスを停止します。 このようなバージョンを引き続き使用すると、リスク管理戦略に問題が生じ、Kubernetes チームからのサポートが利用できなくなるため、トラブルシューティングが難しくなります。 現在、Kubernetes プロジェクトは、最新の 3 つのマイナー リリース (1.20、1.21、1.22) のリリース ブランチを管理しています。 Kubernetes 1.19 以降では約 1 年間のパッチ サポートが提供され、1.18 以前は約 9 か月間のパッチ サポートが提供されます。 (1.18 以前のリリース期間が短いのは、Kubernetes が現在の 3 回ではなく、以前は年に 4 回リリースされていたためです)。
Kubernetes API – Kubernetes のリリースごとに新しい API が誕生し、古い API が廃止されます。また、API の変更は対応するリソースとツールに影響を及ぼします。 Kubernetes プラットフォームをアップグレードする場合、API もアップグレードする必要がある可能性があります。
Kubernetes にデプロイしたツール– Kubernetes またはその API に大きな変更が加えられると、Ingress コントローラーなどのツールと対応するリソースが引き続き適切に機能するかどうかに影響する可能性があります。
したがって、Kubernetes 用、Ingress API 用、NGINX Ingress Controller 用の 3 つのタイムラインを追跡する必要があります。 Kubernetes が壊れないようにするには、Kubernetes バージョンが API および NGINX Ingress Controller と互換性のある最適な状態を見つける必要があります。 互換性を確認せずに 3 つのコンポーネントのいずれかをアップグレードすると、重大な結果を招く可能性があります。 3 つのコンポーネントすべてが互いに互換性がない場合は、おめでとうございます。アプリが壊れてしまいます。
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 は 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 がすでに実行されていることを確認してください。
2016 年の最初のリリース以来、NGINX Ingress Controller は初期のツールから Kubernetes ネットワーキングの強力なツールへと成長しました。 発売から現在までの進化をご紹介します。
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 。
このプロジェクトは、 NGINX Plus ベースのバージョンでの JSON Web Token (JWT) の主要サポートを含む、本番環境対応を実現します。
NGINX Conf 2017 で、Michael Pleshakov は、 「Kubernetes 上の負荷分散アプリケーション用の Ingress コントローラーとしての NGINX Plus の使用」で、高度な負荷分散を含む実稼働機能を紹介します。
NGINX Ingress Controller では、可視性、使いやすさ、柔軟性の面で大きな機能強化が実現されています。
NGINX Conf 2018 で、Michael Pleshakov が「NGINX を Kubernetes Ingress コントローラーとして使用する」のステージに登壇し、Helm を使用して NGINX Ingress コントローラーをデプロイする方法、HTTP および TCP/UDP の負荷分散を構成する方法、Prometheus を使用して監視する方法、トラブルシューティングを行う方法を紹介します。
標準の Kubernetes Ingress リソースに代わるリソースを導入し、高度な機能の実行をより簡単かつ信頼性高く行えるようになりました。
ルート
ユーザーとして実行する機能が追加されました ( 「NGINX Ingress Controller for Kubernetes リリース 1.6.0 の発表」を参照)。「NGINX Ingress Controller の次世代」では、Michael Pleshakov が NGINX Conf 2019 に戻り、ブルーグリーン デプロイメントや A/B テストなどのユースケース向けの VS/VSR を紹介します。
NGINX Ingress リソースに対する数多くの機能強化に加えて、今年の主なテーマはエコシステム ツールと NGINX 製品との統合です。
「NGINX と OpenShiftを使用した本番環境アプリのセキュリティ保護」では、テクニカル マーケティング エンジニアの Amir Rawdat が、NGINX Ingress Operator の使用方法、ロールベースのアクセス制御 (RBAC) を活用した機能横断的なプロビジョニングの方法、NGINX App Protect を使用したコンテナー化されたアプリのセキュリティ保護の方法、JWT を使用したクライアントの検証の方法を紹介します。
セキュリティは、エコシステムのさらなる統合とともに主要なテーマです。
NGINX Sprint 2.0セッション「エンドツーエンドの暗号化によるマイクロサービスのマスター」では、ソフトウェア エンジニアの Aidan Carson が、NGINX Ingress Controller を使用してエッジを保護し、NGINX Service Mesh を使用してサービス間の安全なアクセス制御を設定し、両方の製品を使用して mTLS で出力トラフィックを保護する方法を紹介します。
オープンソースの Ingress コントローラーがアプリに最適な選択であると判断した場合は、 GitHub リポジトリにある NGINX オープンソース ベースの NGINX Ingress コントローラーをすぐに使い始めることができます。
大規模な本番環境の展開には、NGINX Plus をベースにした商用の NGINX Ingress Controller をぜひお試しください。 NGINX App Protect を含む30 日間の無料トライアルをご利用いただけます。
「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"