NGINX Ingress Controllerバージョン2.0：知っておくべきこと

NGINX | 2021年12月27日

10月に、F5 NGINX Ingress Controllerバージョン2.0（nginxinc/kubernetes-ingress）をリリースし、Kubernetes 1.22およびIngress APIのバージョン1（networking.k8s.io/v1）への対応を追加しました。では、それがなぜ重要なのでしょうか？

この「それが何を意味するのか」という問いへの答えは一筋縄ではいきません。そこで、相互に関連する3つの質問に答えながら、その意味を明らかにします。

Kubernetesのリリースが重要なのはなぜでしょうか？
Ingress APIとは何ですか。また、networking.k8s.io/v1へのアップグレードが重要なのはなぜですか？
NGINX Ingress Controller 2.0は既存のお客さまにどのような影響を与えますか？

答えについては、この先をお読みください。また、2022年1月11日には「Kubernetesのバージョン攻撃に備えるための戦略」をご視聴ください。

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

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

Kubernetesプラットフォーム自体 – 新しいリリースが公開されるたびに、Kubernetesチームは旧バージョンのメンテナンスを終了します。このようなバージョンを使い続けると、リスク管理戦略上の問題となるほか、Kubernetesチームのサポートを受けられなくなるため、トラブルシューティングも難しくなります。現在、Kubernetesプロジェクトでは、直近3つのマイナーリリース（1.20、1.21、1.22）のリリースブランチをメンテナンスしています。Kubernetes 1.19以降では約1年間、1.18以前では約9か月間、パッチサポートが提供されました。（1.18以前のサポート期間が短いのは、現在の年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つのコンポーネントすべてに相互互換性がなければ……残念ながら、アプリは動かなくなってしまいます。

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だけでなく、お客さまにも大きな影響を及ぼしました。そのため、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リリース以降、Kubernetes 1.18はサポートされなくなるため、今後数か月以内に新しいバージョンの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」フィールドへの切り替えを推奨します。
  - F5のドキュメントと例（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 Controllerの（それほど短くない）歴史

2016年の初リリース以来、NGINX Ingress Controllerは、登場したばかりのツールからKubernetesネットワーキングを支える強力な存在へと成長してきました。リリースから現在までの進化を振り返ります。

2016年（v0.5.0）

NGINXエンジニアのMichael Pleshakovが、F5の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上のアプリケーションの負荷分散にNGINX PlusをIngress Controllerとして使用する」において、高度な負荷分散を含む本番環境向けの機能を実演しています。

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 Release 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 Controllerとして使用する方法」と題した講演で、Helmを使用したNGINX Ingress Controllerのデプロイ、HTTPおよびTCP/UDPロードバランシングの設定、Prometheusによる監視、トラブルシューティングの方法を紹介します。

2019

標準のKubernetes Ingressリソースに代わる選択肢を発表し、高度な機能をより簡単かつ確実に実行できるようにしました。

5月（v1.5.0） – 新しい構成アプローチとして、VirtualServerおよびVirtualServerRoute（VS/VSR）リソースが導入されました。VS/VSRは初のNGINX Ingressリソースであり、ネイティブかつ型安全で、インデントを使用した構成形式により、Ingressロードバランシングの実装を簡素化します（「NGINX Ingress Controller for Kubernetes Release 1.5.0の発表<.htmla>」を参照）。
12月（v1.6.0） – ドキュメントがdocs.nginx.comに公開されました。VS/VSRリソースでは、より充実したロードバランシング機能がサポートされ、本番環境で利用できるようになりました。監視とデバッグを強化するためにOpenTracingのサポートが追加され、セキュリティ向上のために非rootユーザーとして実行できるようになりました（「NGINX Ingress Controller for Kubernetes Release 1.6.0の発表」を参照）。

「次世代の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 Release 1.7.0の発表」を参照）。
7月（v1.8.0） – F5 NGINX App Protect WAFとの統合により、軽量で柔軟なWAFをIngress Controllerと同じコンテナにデプロイできます。さらに、スニペットまたはカスタムテンプレートを使用してNGINX Ingressリソースをカスタマイズできるようになり、URI書き換えやアクセス制御リストなどの機能により、さらにきめ細かな制御が可能になります（「NGINX Ingress Controller for Kubernetes Release 1.8.0の発表」を参照）。
10月（v1.9.0） – F5 NGINX Service Meshとの統合により、同じ構成でノースサウストラフィックとイーストウェストトラフィックを管理できます。また、履歴データを簡単に可視化できるGrafanaダッシュボードが追加されました（「NGINX Ingress Controllerリリース1.9.0の発表」を参照）。

In NGINXとOpenShiftによる本番アプリの保護では、テクニカルマーケティングエンジニアのAmir Rawdatが、NGINX Ingress Operatorの使用方法、ロールベースのアクセス制御（RBAC）を活用した部門横断的なプロビジョニング、NGINX App Protectによるコンテナ化アプリの保護、JWTによるクライアントの検証について実演します。

2021

セキュリティが主要テーマとなり、エコシステムとの統合もさらに拡充されました。

2月（v1.10.0） – 主な追加機能はOpenID Connect（OIDC）認証です。JWT認証を簡単に利用でき、堅牢なシングルサインオン（SSO）オプションを提供できます（「OpenID ConnectとNGINX Ingress Controllerによる簡単で堅牢なシングルサインオン」を参照）。
3月（v1.11.0） – WAFおよび負荷分散ポリシーの大幅な機能強化により、ヘルスチェックやステータスレポートなど、機能と柔軟性がさらに向上しました（「Enhanced TCP/UDP Load Balancing and WAF Configuration with NGINX Ingress Controller」を参照）。
7月（v1.12.0） – このリリースでは、導入の容易さが大きく向上しています。AWS Container Marketplaceでの購入に加え、F5 Container Registryからビルド済みイメージをプルできるようになりました（「NGINXがAWS Marketplace for Containersで利用可能に」を参照）。
10月（v2.0.3） – 機能面では大きな節目ではないものの、このリリースはKubernetes APIとの相互運用性とIngressオブジェクトの進化における重要な節目となります。この変更により、NGINX Ingress Controller 2.0以降はKubernetes 1.19以降と互換性があります。また、Kubernetes 1.22以降にデプロイできるのは、NGINX Ingress Controller 2.0以降のみです。

NGINX Sprint 2.0のセッション「エンドツーエンド暗号化でマイクロサービスを使いこなす」では、ソフトウェアエンジニアのAidan Carsonが、NGINX Ingress Controllerでエッジを保護する方法、NGINX Service Meshでサービス間のセキュアなアクセス制御を設定する方法、さらに両製品を使用してmTLSでエグレストラフィックを保護する方法を実演します。