はじめに
プラットフォームエンジニアリングは、近年複雑化するソフトウェア開発において開発者体験や生産性の向上、ビジネス価値の迅速な提供を目指しています。プラットフォームエンジニアリングでは、プラットフォームを通じて共通のインフラストラクチャやサービスを提供し、開発者がアプリケーションの構築に集中できるようにします。また、プラットフォームとしてKubernetesが広く採用されています。
今回、プラットフォームエンジニアリングという観点で見た場合のIngressの課題と、なぜGateway APIを検討すべきかについて簡単にまとめます。
Ingress NGINXのメンテナンスが2026年3月に終了するということで、今後の代替としてGateway APIの検討をしている方にも参考にしていただけると嬉しいです。
プラットフォームエンジニアリングとは何か、という方は、先に「プラットフォームエンジニアリング」の基礎と「Kubernetes」開発基盤の要点を整理するを見てから読むことをお勧めします。
Ingressの課題
IngressはKubernetesの標準的なネットワークAPIであり、外部からのトラフィックをKubernetesクラスター内のサービスにルーティングするために使用されます。単純にアプリケーションを公開したいだけであればシンプルで使いやすいリソースなのですが、プラットフォームエンジニアリングという観点では、以下のようにプラットフォームチームとプロダクトチームの権限分離に課題が出てきます。
- プロダクトチームがIngressを管理する場合、プラットフォームチームはIngressの設定に干渉できないため、共有Ingressコントローラー上でホスト名の競合が発生したり、TLS必須化などのポリシーを強制することが難しいです。
- プラットフォームチームがIngressを管理する場合、アプリケーションのふるまいに近いルーティングをプロダクトチームが設定できません。結果として、プロダクトチームがプラットフォームチームに依頼して設定してもらう必要があり、効率が悪くなります。
Gateway APIが権限分離を可能にする仕組み
Gateway APIはIngressに代わるKubernetesの新しいネットワークAPIであり、より柔軟で拡張性の高いトラフィック管理を提供します。Gateway APIはロール指向で設計されており、プラットフォームチームとプロダクトチームの管理するリソースを分けられるようになっています。
以下はGateway APIの主要なリソースと、それぞれの管理者と役割の例です。
| リソース | 管理者 | 役割 |
|---|---|---|
| Gateway | プラットフォームチーム | ロードバランサーの管理 |
| HTTPRoute | プロダクトチーム | トラフィックのルーティングを定義 |
これにより、プラットフォームチームがロードバランサーを管理し、プロダクトチームが自分たちのアプリケーションのトラフィックルーティングを柔軟に設定できるようになります。
また、以下のようなメリットがあります。
- Gatewayの設定で各テナントで利用可能なホスト名を指定できるので、各テナント間でルーティングが競合するのを防止できます。
- Gatewayの設定でTLS必須のポリシーを強制できます。
まとめ
プラットフォームエンジニアリングにおいて、Gateway APIはIngressに比べて権限分離が容易であり、プラットフォームチームとプロダクトチームの両方にとって利便性が高いです。これにより、開発者体験の向上やセキュリティの強化が期待できます。プラットフォームエンジニアリングを検討している場合は、Gateway APIの採用を検討してみてはいかがでしょうか？
さらに、Kuadrantを利用することで、認証認可などのセキュリティポリシーの設定をGatewayにかけて、デフォルトでセキュリティを強化することも可能です。Kuadrantについてもどこかでまとめたいと思います。
※本記事は大西配列で書かれました。