API management · Guide
Kubernetes ingress controller: Ingress, Gateway API or an API gateway, and where Kong fits
A Kubernetes ingress controller is the component that takes requests from outside a cluster and routes them to the right service inside it. Every production cluster needs one, and the choice is wider than it looks: the older Ingress resource, the newer Kubernetes Gateway API, or a full API gateway running on the cluster. This guide explains the three in plain words, how an ingress differs from an API gateway, and how Interkey sets up Kong Ingress Controller for organisations in Saudi Arabia.
Published 10 min read
In short, for executives
- What it is: the front door of a Kubernetes cluster. It decides which outside request reaches which service, and usually ends TLS encryption there.
- Why it matters: every outside call passes through it, so it sets availability, security and where encryption keys and logs live.
- The choice: basic routing through the Ingress resource, richer routing through the Gateway API, or gateway policies such as authentication and rate limits on the same component.
- Where Kong fits: Kong Ingress Controller runs Kong Gateway as the cluster's ingress, so one component can route traffic and apply gateway policies.
At a glance
| Question | Answer |
|---|---|
| What it does | Routes requests from outside the cluster to services inside it, by host name and path or by protocol |
| Traffic it handles | North-south: into and out of the cluster. Traffic between services inside it is a separate design |
| How routes are written | As Kubernetes resources: Ingress, or the Gateway API's Gateway and route resources |
| Ingress or API gateway | An ingress routes; an API gateway also identifies callers and applies policies per consumer |
| Kong option | Kong Ingress Controller, which runs Kong Gateway as the ingress and supports both Ingress and the Gateway API |
| From Interkey | Design, setup as code, migration of existing routes, monitoring and support from Riyadh |
What a Kubernetes ingress controller does, in plain words
Inside a cluster, services find each other by internal names and addresses that change as pods start and stop. Nothing outside the cluster can use those addresses. Someone has to stand at the edge, accept the request for api.example.sa/orders, and pass it to whichever pods run the orders service right now. That is the job of the ingress controller.
Read more
Kubernetes splits the job in two. A routing resource in the cluster's configuration says what should happen: this host and path go to that service. The controller is the software that reads those resources and configures a proxy to match. A route without a controller does nothing.
Why k8s ingress design matters for organisations in the Kingdom
The ingress is usually where TLS encryption ends, which means it holds certificates and private keys and sees requests in clear text. For organisations whose data classification requires payloads to stay in Saudi Arabia, where that happens is part of the residency answer, not a detail. Its logs are also what operations teams read first during an incident.
Many teams meet the question during a Kubernetes migration: the applications move onto the cluster, and the routing that used to live in a load balancer, a reverse proxy or an API gateway in front of virtual machines has to be rebuilt for the cluster.
Ingress, Kubernetes Gateway API or a full API gateway: the options
These options are layers rather than opposites. Each adds something to the one before it, and each adds something to operate.
| Option | What it gives you | Good fit | Watch for |
|---|---|---|---|
| Ingress resource | HTTP and HTTPS routing by host name and path, with TLS ending at the controller | Clusters with a handful of web applications and simple routing | Anything beyond host and path is written as product-specific annotations that do not move between controllers |
| Kubernetes Gateway API | Routing split into separate resources for the platform team (the gateway) and application teams (the routes), with richer matching and protocols beyond HTTP | Shared clusters where several teams publish their own routes; new clusters | A newer API: check which resources and features your controller supports before you design around them |
| API gateway on the cluster | Routing plus authentication, rate limits per consumer, request transformation and per-consumer logs, on the same component | APIs used by partners, mobile apps or other organisations | More to configure and own; policies need an owner and a change process |
Which Gateway API resources a controller supports, and how fully, changes from release to release. For Kong we confirm the current list against Kong's documentation before design, rather than relying on a summary.
The Kubernetes Gateway API, and why new clusters lean towards it
The Ingress resource was designed for one team routing web traffic. In a shared cluster, every application team needs to change routes, while the settings the platform team cares about, such as ports and certificates, sit in the same object, and richer features end up in annotations each controller defines its own way. The Gateway API, a Kubernetes project, splits those concerns into separate resources.
| Resource | Owned by | What it holds |
|---|---|---|
| GatewayClass | The platform team, with the controller vendor | The kind of controller that does the work |
| Gateway | The platform team | Listeners, ports and certificates at the edge of the cluster |
| Routes, such as HTTPRoute | Application teams | Matching rules and the services requests go to; each route attaches to a gateway it is allowed to use |
An application team can then change its routes without touching the edge, and the platform team decides which namespaces may attach to which gateway. Header matching, weighted traffic splitting for gradual releases and protocols other than HTTP are part of the specification, not annotations.
A cluster that runs well on Ingress need not move at once. Most controllers that support the Gateway API also read Ingress, so routes can move service by service.
Ingress vs API gateway: where routing ends and API management begins
An ingress controller answers one question: where does this request go? An API gateway also asks who is calling, whether they may call this route, whether they have used up their allowance, and which consumer each log line belongs to.
A cluster serving only its own web front end often needs just routing and TLS. Once it publishes APIs to partners, government platforms or a mobile app, the second set of questions arrives, and the controls go either inside each service, spreading security code across teams, or at the edge, which is what a gateway is for. Our API gateway page sets out its functions, and our API security page covers what a gateway can and cannot enforce.
The two need not be separate products. When the ingress controller is itself an API gateway, routing and policies live in one configuration, reviewed and deployed with the applications they protect.
A checklist before you choose a Kubernetes ingress controller
- Every host name and route the cluster must serve is listed, with an owner for each.
- It is decided where TLS ends, who manages the certificates and how they are renewed.
- It is decided whether routes are written as Ingress, as Gateway API resources, or both during a transition.
- Rules in today's load balancer, reverse proxy or gateway are listed, and each is kept, changed or dropped on purpose.
- The ingress runs more than one replica, with resource limits and a tested upgrade path.
- Access logs and metrics per route reach your monitoring, and someone is alerted when error rates rise.
- The configuration lives in version control and changes through review, never by hand in the cluster.
- Where payloads, keys and logs are processed is checked against your data classification.
Where Kong Ingress Controller fits, and where it does not
Kong is the gateway Interkey implements. Kong Ingress Controller runs Kong Gateway as the cluster's ingress and configures it from Kubernetes resources, so the gateway is managed the same way as the applications.
| Need | With Kong Ingress Controller | What to know |
|---|---|---|
| Routing with the Ingress resource | Supported | Existing Ingress routes can be read as they are, then moved over time |
| Routing with the Gateway API | Supported, including HTTPRoute, TCPRoute and UDPRoute | We confirm the current resource list and features in Kong's documentation at design time |
| Gateway policies at the ingress | Kong plugins, configured through Kubernetes custom resources | Some plugins, such as Rate Limiting Advanced, are Enterprise only; Rate Limiting is not |
| Same policies outside the cluster | Kong Gateway in front of virtual machines, with the same plugin model | One way of writing policies for services inside and outside Kubernetes |
| Traffic between services inside the cluster | Not the ingress's job | East-west traffic is a separate design decision |
Where it does not fit. If the cluster only serves a web front end with a few host names and no outside consumers, a full API gateway may be more than you need to operate, and plain routing is the honest scope. Kong Ingress Controller also does not replace protection against large network floods in front of the cluster. Our Kong implementation page explains the deployment shapes, including running the gateway as the Kubernetes ingress beside a self-managed or hybrid deployment.
Ingress in a Kubernetes migration
In Interkey's migration work, the ingress is built with the cluster, not after it: cluster, ingress, secrets, observability hooks and the deployment pipeline are one scoped piece of work. Routes are moved in the same dependency order as the applications, so the old entry point and the new one run side by side, and each service switches when it is ready.
Read more
It goes smoothly when today's routing rules are written down and the applications can run as several identical instances behind the ingress. The wider picture of the platform is set out in our guide to Kubernetes container orchestration, and monitoring of the cluster and its ingress on our Kubernetes monitoring page.
What drives cost and timeline
Installing a controller is quick; the effort sits around it, and we estimate it after reading your current routing. What drives it: how many routes exist and whether they are documented, how many teams publish routes, whether gateway policies are in scope, how many clusters need the same setup, and whether traffic must move without downtime.
Where Kong Enterprise plugins are needed, Kong licensing is quoted at Kong's terms, on a separate line from Interkey's work.
How Interkey helps with your Kubernetes ingress
-
Read the current edge.
List today's routes, certificates and gateway rules, with an owner for each.
-
Choose the design.
Ingress, Gateway API or both; whether gateway policies sit at the ingress; where TLS ends.
-
Set up as code.
Kong Ingress Controller and its resources in version control, reviewed and tested before production.
-
Move route by route.
Old and new entry points side by side, each service switched when it is ready.
-
Monitor and support.
Per-route logs and alerts, support from Riyadh in Arabic and English, or operation under a written managed services scope.
Questions buyers ask about Kubernetes ingress controllers
What does a Kubernetes ingress controller actually do?
It watches the routing resources in the cluster and configures a proxy to match them, so a request for a host name and path reaches the right service. In most designs it also ends TLS encryption and writes the access logs for outside traffic.
Should a new cluster use Ingress or the Gateway API?
For a new shared cluster, the Gateway API is usually the better start, because platform and application teams own separate resources and richer routing is part of the standard. A small cluster with simple web routing can stay on Ingress. Many controllers, Kong's included, read both.
Is an ingress controller enough, or do we also need an API gateway?
An ingress is enough when the cluster only serves its own front end. Once partners, mobile apps or other organisations call its APIs, you need caller identity, rate limits and per-consumer logs. With Kong Ingress Controller those gateway policies can run on the ingress itself.
Do we need a Kong Enterprise licence for an ingress in KSA?
It depends on the plugins you need. Basic routing and plugins such as Rate Limiting are not marked Enterprise only; plugins such as Rate Limiting Advanced are. We check your requirements against Kong's current plugin list, and licensing is quoted at Kong's terms.
Can TLS keys, payloads and ingress logs stay inside Saudi Arabia?
Yes, when the cluster runs in the Kingdom, on your servers or in a cloud region inside Saudi Arabia: the ingress ends TLS and processes requests where the cluster is. Where logs and metrics are sent afterwards is a separate decision for your data classification.
How long does it take to move our routes to a new ingress controller?
It depends on how many routes and host names you have, whether they are documented and whether traffic must move without downtime. Installing the controller is quick; listing and testing routes takes longer, and we estimate it once we have read them.
Next
Read next
Next step
Plan your cluster ingress with us
Tell us about your clusters, the applications they serve, how traffic reaches them today and who calls your APIs. We will propose an ingress design, whether gateway policies belong at the edge, and the steps to move without breaking anyone.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia