{"slug": "announcing-kong-operator-2-3", "title": "Announcing Kong Operator 2.3", "summary": "Kong released Kong Operator 2.3, adding full Kubernetes CRD support for Kong AI Gateway so teams can declare AI Gateway control planes, model providers, models, policies, authentication, and consumers as Kubernetes resources managed through GitOps workflows. The release also adds Gateway API support for TCPRoute, UDPRoute, and GRPCRoute for on-prem and Konnect-based gateway deployments, extends the konghq.com/tags annotation to Gateway API resources under Hybrid Gateway for attribution in Konnect, and adds native HorizontalPodAutoscaler support for AI and Event Gateway data planes via spec.deployment.scaling.horizontal.", "body_md": "# Introducing Kong Operator 2.3: AI Gateway & More\n\nJustin Davies\n\nProduct Manager, Mesh and Kubernetes, Kong\n\nToday we're announcing Kong Operator 2.3. Building on 2.2's expansion into supporting Event Gateway and Dev Portal, this release significantly broadens our feature set. While 2.2 introduced foundational event-driven capabilities, 2.3 brings Kong **AI Gateway** fully into the Kubernetes-native fold, enabling teams to manage LLM routing and policies through familiar GitOps workflows. This update also rounds out Gateway API coverage with `TCPRoute`, `UDPRoute`, and `GRPCRoute`.\n\n## Kong AI Gateway on Kubernetes\n\nWe have full Kubernetes CRD support for Kong AI Gateway. You can now declare an entire AI Gateway deployment; control plane, providers, models, policies, authentication, and consumers as Kubernetes resources, and manage it with the same GitOps workflows you already use for the rest of your Kong estate.\n\n**This content contains a video which can not be displayed in Agent mode**\n\nA `KonnectAIGateway` provisions the AI Gateway control plane in Konnect and acts as the controller for everything else. From there, `AIGatewayModelProvider` and `AIGatewayModel` connect upstream LLM providers; OpenAI, Anthropic, Azure, Bedrock, Gemini, and a dozen others and exposes them as routes, with support for weighted round-robin, priority, latency usage-based, and semantic load balancing across targets:\n\nyaml\n\n## yaml\n\n```\napiVersion: aiconfiguration.konghq.com/v1alpha1\nkind: AIGatewayModel\nmetadata:\n  name: gpt-4o-mini\nspec:\n  aiGatewayRef:\n    type: namespacedRef\n    namespacedRef:\n      name: my-ai-gateway-cp\n  apiSpec:\n    type: model\n    model:\n      name: gpt-4o-mini\n      formats:\n        - type: openai\n      capabilities:\n        - generate\n      config:\n        route:\n          paths:\n            - /v1\n      targets:\n        - name: gpt-4o-mini\n          provider:\n            name: openai-provider\n          config:\n            type: openai\n            openai:\n              upstreamURL: https://api.openai.com/v1/chat/completions\n```\n\nBecause Kong Operator natively understands these AI Gateway CRDs, you can easily configure provider-specific rules, such as setting up Azure OpenAI latency-based load balancing or configuring dynamic Bedrock model routing directly within your Kubernetes manifests.\n\n`AIGatewayPolicy` applies guardrails like prompt injection detection and topic allowlisting before a request ever reaches a model. AIGatewayAuthStrategy and the `AIGatewayConsumer` family add per-team API key authentication, consumer grouping, and usage attribution, all enforced at the Gateway.\n\nKong Operator has supported `HTTPRoute` and `TLSRoute` for a while. 2.3 fills out the rest of the Gateway API route kinds, `TCPRoute`, `UDPRoute`, and `GRPCRoute `are now supported both for on-prem gateways and for Konnect based Gateway deployments.\n\n## Tag Gateway API resources for attribution in Konnect\n\nPlatform teams running multi-tenant clusters need a way to answer \"whose traffic is this?\" without leaving Kubernetes. Kong Operator 2.3 extends Kong Operator's existing konghq.com/tags annotation to Gateway API resources under Hybrid Gateway: tag an HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, or UDPRoute or the backend Service etc. and that tag now propagates through to Konnect.\n\nyaml\n\n## yaml\n\n```\napiVersion: gateway.networking.k8s.io/v1\nkind: HTTPRoute\nmetadata:\n  name: checkout-service\n  annotations:\n    konghq.com/tags: \"team-checkout,cost-center-4210\"\nspec:\n  # ...\n```\n\n## Autoscaling and production readiness\n\nRunning AI Gateway and Event Gateway data planes in production means being able to scale them the same way you'd scale anything else in Kubernetes. 2.3 adds native `HorizontalPodAutoscaler` support for AI and Event Gateway Dataplanes. Just set `spec.deployment.scaling.horizontal`, and the operator creates and manages the HPA for you, removing it cleanly if you switch back to a static replica count, which prevents the common issue where the Kong Operator HPA gets deleted or orphaned when replicas are fixed manually.\n\n## Kubernetes as the control plane for more of Kong\n\nWith 2.3, Kong Operator now manages API Gateway, AI Gateway, Event Gateway, and Dev Portal resources through the same declarative, Kubernetes-native model, version-controlled, reviewed, and deployed through the same GitOps pipelines you already run everything else through.\n\nWhether you're routing HTTP, TCP, UDP, or gRPC traffic, proxying to an LLM, or exposing MCP tools, it's all the same operational pattern within Kubernetes.\n\n**Q: What are the main differences between Kong Operator 2.2 vs 2.3?** A: While Kong Operator 2.2 introduced support for Event Gateway and Dev Portal, version 2.3 expands heavily into AI and advanced routing. The biggest differences in 2.3 are native Kubernetes AI Gateway support (enabling GitOps for LLM routing) and full Gateway API protocol coverage, including TCPRoute, UDPRoute, and GRPCRoute.\n\n**Q: Why is my AIGatewayPolicy not enforcing the topic allowlist?** A: If your topic allowlist isn't being enforced, verify that your `AIGatewayPolicy `is correctly bound to the targeted route or service. Also, ensure the LLM provider configuration in your `AIGatewayModelProvider` supports the necessary inspection capabilities. Misconfigurations here are the most common reason a request bypasses guardrails.\n\n**Q: What is semantic load balancing in an LLM gateway?** A: Semantic load balancing is an advanced routing strategy where Kong AI Gateway analyzes the actual meaning or context of an incoming prompt—not just traditional HTTP metrics—to route the request to the most appropriate, cost-effective, or performant LLM target.\n\n**Q: How do I fix a \"Gateway API GRPCRoute unsupported\" error in Kong Operator?** A: This error occurs when using an older version of the Kong Operator that only supported HTTPRoute and TLSRoute. To fix it, upgrade to Kong Operator 2.3, which introduces full native support for GRPCRoute, as well as TCPRoute and UDPRoute.\n\nJustin Davies\n\nProduct Manager, Mesh and Kubernetes, Kong\n\nRecommended posts\n\n# Kong Introduces the Portal MCP Server for Developer Portal\n\nYour developer portal was built for a developer scanning docs in a browser: reading a page, copying a curl command, moving on. Increasingly, the thing reading those docs isn't a person. It's an agent, working through an API integration on someone's\n\nThere are two key concepts when a developer works with an API. The OpenAPI Spec describes how the API should work, and helps agents discover what is possible. The Collection and Requests help debug and verify how the endpoints currently function. P\n\nCameron HayGlass\n\n# Kong API Gateway 3.16: From Debugging to Billing to Compliance\n\nTwo kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan\n\nFIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va\n\nIf you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access\n\nA Git Sync experience that fits your API testing workflow, not the other way around. Insomnia 13.1 now reads your .gitconfig, syncing the native git credentials you’ve already configured, so now you just need to connect once, and you’re all set. Fr\n\nHaley Giuliano\n\n# Kong Introduces the Portal MCP Server for Developer Portal\n\nYour developer portal was built for a developer scanning docs in a browser: reading a page, copying a curl command, moving on. Increasingly, the thing reading those docs isn't a person. It's an agent, working through an API integration on someone's\n\nThere are two key concepts when a developer works with an API. The OpenAPI Spec describes how the API should work, and helps agents discover what is possible. The Collection and Requests help debug and verify how the endpoints currently function. P\n\nCameron HayGlass\n\n# Kong API Gateway 3.16: From Debugging to Billing to Compliance\n\nTwo kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan\n\nFIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va\n\nIf you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access\n\nA Git Sync experience that fits your API testing workflow, not the other way around. Insomnia 13.1 now reads your .gitconfig, syncing the native git credentials you’ve already configured, so now you just need to connect once, and you’re all set. Fr\n\nHaley Giuliano\n\n# Kong Introduces the Portal MCP Server for Developer Portal\n\nYour developer portal was built for a developer scanning docs in a browser: reading a page, copying a curl command, moving on. Increasingly, the thing reading those docs isn't a person. It's an agent, working through an API integration on someone's\n\nThere are two key concepts when a developer works with an API. The OpenAPI Spec describes how the API should work, and helps agents discover what is possible. The Collection and Requests help debug and verify how the endpoints currently function. P\n\nCameron HayGlass\n\n# Kong API Gateway 3.16: From Debugging to Billing to Compliance\n\nTwo kinds of problems only show up once an API is already live. Something breaks, and a team needs visibility into one specific node right now — not after a redeploy. Or the right behavior for a request depends on who's calling it: a consumer's plan\n\nFIPS 140-3 is the U.S. and Canadian government standard for validating cryptographic modules - the code that does encryption, key generation, and digital signatures. It's issued by NIST and CCCS and enforced through CMVP, the Cryptographic Module Va\n\nIf you're running agents in production, you've felt this problem: every agent, every LLM application, every MCP client needs to be configured against a growing sprawl of MCP servers, each with its own endpoint, its own handshake, and its own access\n\nA Git Sync experience that fits your API testing workflow, not the other way around. Insomnia 13.1 now reads your .gitconfig, syncing the native git credentials you’ve already configured, so now you just need to connect once, and you’re all set. Fr\n\nHaley Giuliano\n\n## Ready to see Kong in action?\n\nGet a personalized walkthrough of Kong's platform tailored to your architecture, use cases, and scale requirements.", "url": "https://wpnews.pro/news/announcing-kong-operator-2-3", "canonical_source": "https://konghq.com/blog/product-releases/kong-operator-2-3", "published_at": "2026-09-25 16:12:00+00:00", "updated_at": "2026-09-25 16:32:15.702260+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-products", "developer-tools", "mlops", "ai-agents"], "entities": ["Kong", "Kong Operator 2.3", "Kong AI Gateway", "Konnect", "Justin Davies", "OpenAI", "Anthropic", "Azure OpenAI"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/announcing-kong-operator-2-3", "markdown": "https://wpnews.pro/news/announcing-kong-operator-2-3.md", "text": "https://wpnews.pro/news/announcing-kong-operator-2-3.txt", "jsonld": "https://wpnews.pro/news/announcing-kong-operator-2-3.jsonld"}}