2023年10月、Kubernetes Gateway APIがGAとなりました。
引用： https://kubernetes.io/blog/2023/10/31/gateway-api-ga/
Gateway APIは、高度なユースケースを構成し、同じ環境でマルチテナントチームをサポートする際の複雑さやエラー発生のしやすさなど、運用環境でIngressオブジェクトを使用する際の課題に対処するため、Kubernetes Ingress APIから進化した機能となります。さらにGateway APIは、Service Meshのユースケース向けGateway API仕様の機能とリソースを調査および定義するために、Gateway API for Mesh Management and Administration (GAMMA) サブグループを形成しています。
Gateway API v1.0 では、Blue-Greenデプロイメント、TLS終端、SNIルーティングなど、Kubernetesクラスターにおける高度な接続ユースケースに焦点を当てています。将来のロードマップでは、Service間通信のユースケースへの対応など、セキュリティと可観測性の機能をさらに追加してこれらの機能を拡張する計画があります。
Gateway APIは、Kubernetesでのアプリとサービスネットワーキングの標準化と改善を目的としたクロスベンダーのオープンソースプロジェクトであり、NGINXはこのプロジェクトに積極的に参加しています。そしてこのGateway API仕様に準拠した実装として、NGINX Gateway Fabric v1.0を2023年11月にリリースしています。NGINX Gateway Fabricは、世界で最も広く使用されているデータプレーンの 1 つであるNGINXを活用して、高速で信頼性が高く、安全なKubernetesアプリ接続を実現します。
NGINX Gateway Fabricとは
NGINX Gateway FabricはGateway API v1に準拠し、Red Hat OpenShiftを始めとした様々なKubernetes環境で動作することができます。
製品ページ： https://www.nginx.com/products/nginx-gateway-fabric/
オープンソースプロジェクトとして公開しており、F5からのエンタープライズサポートの提供も可能です。
GitHub： https://github.com/nginxinc/nginx-gateway-fabric
Gateway API仕様での重要な機能の 1 つに、関連するロール (インフラストラクチャプロバイダー、クラスターオペレーター、アプリケーション開発者) へのロールベースのアクセス制御 (RBAC) マッピングを備えた 3 つの主要なゲートウェイ API リソース (GatewayClass、Gateway、および Routes) の標準化があります。
引用：https://gateway-api.sigs.k8s.io/
NGINX Gateway Fabricはこの仕様に準拠しており、上図をNGINX Gateway Fabricにあてはめると下図になります。
RBAC機能により責任範囲を明確に定義し、さまざまな役割を分離することで、管理が合理化・簡素化されます。具体的には、インフラストラクチャプロバイダーはKubernetesクラスターの GatewayClassを定義し、クラスターオペレーターはクラスター内にGatewayを展開して構成します。アプリケーション開発者は、同じ基盤を共有しながら、GatewayにRoutesを自由に接続してアプリケーションを外部に公開することができます。クライアントがアプリに接続すると、NGINX Gateway Fabricはこれらのリクエストをそれぞれのアプリケーションにルーティングします。
さらなる情報として、NGINX Gateway Fabricの利点やアーキテクチャについてご興味のある方は、オリジナルのブログ「Announcing NGINX Gateway Fabric Version 1.0 」をぜひご参照ください。
NGINX Gateway Fabricを使用した複雑なルーティングルール設定については、ブログ「How NGINX Gateway Fabric Implements Complex Routing Rules 」 をぜひご参照ください。
NGINX Ingress Controllerで実現するRBACなリソース管理
Gateway APIでは、Ingress APIで未定義であったRBACなリソース管理を定義していますが、NGINX Ingress ControllerのCRD (Custom Resource Definitions) により、近しい機能を実現することが可能です。
NGINX Gateway Fabricの最初のバージョンが2023年にリリースされたのに対し、NGINX Ingress Controllerの最初のバージョンは2017年にリリースされました。NGINX Ingress Controllerのリリース後、その導入と構成の容易さ、高負荷時におけるリソース使用率の低さ、高速で信頼性の高い操作によりすぐに注目を集め、世界で最も使用される Ingress となっています。
引用：https://www.cncf.io/wp-content/uploads/2020/11/CNCF_Survey_Report_2020.pdf
NGINX Ingress Controller では、多くのNGINXユーザの皆様からの要望に応える形で、HTTP以外のプロトコルのサポート、セキュリティポリシーやカスタマイズされたリクエストルーティングポリシーのアタッチ等、様々なユースケースを実現可能にするための CRD を開発し、提供しています。
CRD である VirtualServer、VirtualServerRoute、TransportServer、Policy 等を活用してより高度なユースケースを実現しながら、RBACなリソース管理を実現することが可能です。
上図のように、Gateway API での実装はこれからとなるセキュリティの実装についても、NGINX Ingress Controller CRD で実現することが可能です。セキュリティポリシーをKubernetesリソースファイルとしてCI/CDツールでセキュリティチームが管理し、Security as Codeをスムーズに実現し、開発初期段階からセキュリティを含めた開発を行うシフトレフトを容易に実現することができるようになります。
Gateway API仕様はIngress API仕様での不足機能を補う形でリリースされ、まだまだこれから進化していく予定です。その進化に合わせ、NGINX Gateway Fabricでも様々な機能が実装されていきます。
どちらを使用すべきか悩まれているユーザの皆様、まずはNGINX Ingress Controller CRDにてRBACや高度な通信制御、セキュリティポリシーの実装を実現し、今後必要な機能がGateway API仕様で実装された際に、同じくNGINXシリーズであるNGINX Gateway Fabricの使用を始める、という方法も 1 つの選択肢になるかと思います。
NGINXがユーザの皆様のアプリケーションモダナイゼーションをご支援できることを願っております。
