Kthena Router Adds Gateway API Inference Extension Support

Kthena Router now supports the Kubernetes Gateway API and the Gateway API Inference Extension, according to a contributed blog post on Cloud Native Now and Kthena's product documentation. The Cloud Native Now article describes the Inference Extension as introducing inference-specific resources including InferencePool and InferenceObjective, and says those resources enable model-aware routing and OpenAI API compatibility. Kthena's own architecture page documents the router as a standalone component that integrates with gateway infrastructure, supports external AI providers and privately deployed models, and continuously collects model runtime metrics via a Metrics Fetcher. A GitHub issue in the volcano-sh/kthena repository shows a feature request to add Gateway API fields to the router access log, listing Gateway, HTTPRoute, and InferencePool as proposed log fields.

Kthena's architecture documentation lists core components including a Router, Listener, Controller, Filters (Auth and RateLimit), Backend abstraction, and Metrics Fetcher; the docs also note support for inference frameworks such as vLLM and SGLang. The Cloud Native Now coverage explains that the Gateway API separates routing responsibilities into role-oriented resources and that the Inference Extension standardizes inference exposure and routing through resources like InferencePool and InferenceObjective. The GitHub issue proposes developer-level changes to access logging to record Gateway API association for model requests.

Standardizing inference routing on the Gateway API plus an inference-focused extension reduces ambiguity that arises from cluster-global model identifiers. Companies and projects deploying model inference at scale commonly face multitenant name collisions and cross-namespace routing needs; using gateway-scoped routing spaces and explicit inference resources is a pattern that addresses those operational concerns. For practitioners, the combination of runtime metric collection described in Kthena's docs and gateway-scoped routing allows more informed routing decisions without embedding that logic into application code.

Industry reporting frames this integration as part of a broader effort to make AI/ML deployment tooling first-class citizens in Kubernetes networking. The Gateway API has been adopted to replace limited Ingress semantics for teams that need cross-namespace routing, protocol diversity, and role separation. The Inference Extension adds schema-level primitives for model routing, which the article suggests can simplify interoperability between gateway implementations and inference backends. For operators of inference fleets, aligning router behavior with cluster networking standards reduces bespoke configuration and can make audits, logging, and multi-team tenancy easier to reason about.

• •Adoption indicators: whether other gateway implementations or vendors cite the Inference Extension in release notes or examples.
• •Observability changes: the volcano-sh/kthena GitHub issue indicates proposed access-log schema changes; watchers should check the repo for merged PRs and released log formats.
• •Interop tests: look for example manifests or conformance suites that demonstrate InferencePool and InferenceObjective working across gateways and backends.

Integrating a router that understands Gateway API inference primitives can reduce custom routing glue and surface model-level telemetry for routing decisions. Teams planning multitenant inference deployments should evaluate whether gateway-scoped routing and standardized inference CRs match their tenancy and compliance needs.