Kubernetes環境におけるIngress管理は、サービスの外部アクセスを効率化し、柔軟なルーティングを実現するための核となる技術です。しかし、従來のIngressアーキテクチャは複雑な依存関係や制限により、運用コストと信頼性の課題を抱えていました。本記事では、Dockerが採用した新たなIngressアーキテクチャの設計思想、技術的選択肢、実裝戦略、および移行プロセスを詳細に解説します。Envoy GatewayやHAProxy、EngineXといった技術の選択理由や、CNCF（Cloud Native Computing Foundation）の枠組みにおける位置づけについても説明します。
舊システムでは、制御臺クライアント/サーバーを介したKeyValueストレージや動的再構成、サービスディスカバリーに依存していました。これにより、制御臺サービスの高可用性を確保する必要があり、システム全體の脆弱性が増加しました。
EngineXは10年前に開発され、HAProxyでは実現できない機能を補うために設計されました。しかし、これにより追加のプロキシレイヤーが導入され、レイテンシーと複雑性が増加しました。LuaスクリプトによるJWT認証やレート制限、セッション管理の処理は、複數のレイヤーで重複され、故障リスクとリソース消費が増加しました。
HAProxyはOpen Telemetryのサポートが不足しており、観測性の欠如が課題でした。また、複雑なSidecarエコシステムの必要性により、運用が困難になっていました。
Envoy Gatewayは動的XDS再構成をサポートし、強力なコミュニティとGo言語による拡張性を備えています。Kubernetesネイティブなソリューションとして、自サービスルーティングを実現し、Gateway APIを通じて豊富なルーティングモデルと操作の簡素化を提供します。
NLB（L4）からALB（L7）への移行を行い、Route 53 DNSウェイト調整を用いて段階的に切り替えます。ALBが追加するX-Forwarded-Forヘッダーのアプリケーションレイヤー調整を解決し、ALBの即時トラフィックスイッチ機能によりサービスごとに移行を実現します。
Helmチャートを用いてルート構成を管理し、Kubernetes注釈でトラフィックルールを定義します。例として、http.routeとtrafficPolicyの構成でトラフィック比率とルート目標を指定します。Canaryデプロイをサポートし、90%はHAProxy、10%はEnvoyにトラフィックを導きます。
一部の機能（グローバルレート制限、IPタグ）は未実裝であり、XDS APIによるパッチを用いて拡張します。コントロールプレーン拡張により、カスタム戦略の統合を実現します。
ALBのウェイトルーティングにより、トラフィックスイッチとロールバックを実現します。OPA戦略検証により、構成エラー（重複ドメイン/パス）を防止します。Helmチャートによる構成プロセスの標準化により、人為的エラーのリスクを低減します。
本記事では、Dockerが採用したIngressアーキテクチャの再設計プロセスと技術的選択肢を詳細に解説しました。Envoy Gatewayの選択により、動的XDS再構成、Kubernetesネイティブな機能、豊富なルーティングモデルが実現され、運用効率と信頼性が向上しました。また、HAProxyやEngineXの制限を克服し、Open Telemetryによる観測性の向上により、システムの可視性が強化されました。今後の課題として、Gateway APIの制限を克服するためのXDSパッチや、コントロールプレーンのグレースフルデプロイの実裝が挙げられます。これらの技術は、CNCFの枠組みにおいても重要な役割を果たしており、今後のクラウドネイティブアーキテクチャの進化に貢獻するでしょう。