You are browsing documentation for an outdated version.
See the latest documentation here.
Kong Ingress Controller Design
The Kong Ingress Controller configures Kong Gateway using Ingress
or Gateway API resources created inside a Kubernetes cluster.
The Kong Ingress Controller is made up of two high level components:
- Kong, the core proxy that handles all the traffic
- Controller Manager, a series of processes that synchronize the configuration from Kubernetes to Kong
The Kong Ingress Controller performs more than just proxying the traffic coming
into a Kubernetes cluster. It is possible to configure plugins,
load balancing, health checking and leverage all that Kong offers in a
The following figure shows how it works:
The Controller Manager listens for changes happening inside the Kubernetes
cluster and updates Kong in response to those changes to correctly
proxy all the traffic.
Kong is updated dynamically to respond to changes around scaling,
configuration changes, failures that are happening inside a Kubernetes
For more information on how Kong works with routes, services, and upstreams,
please see the proxy
and load balancing references.
Kubernetes resources are mapped to Kong resources to proxy traffic.
There exist 2 flavors of objects in Kubernetes that can be used with
Kong Ingress Controller in order to procure a working Kong Gateway.
Generic Kubernetes resources
In Kubernetes, there are several main concepts that are used to logically identify
workloads and route traffic between them. Some of them are:
- A Service inside Kubernetes is a way to abstract an application that is running on a set of pods.
This maps to two objects in Kong: Service and Upstream.
The service object in Kong holds the information on the protocol
to use to talk to the upstream service and various other protocol
specific settings. The Upstream object defines load-balancing
and health-checking behavior.
- Pods associated with a Service in Kubernetes map as a Target belonging
to the Upstream (the upstream corresponding to the Kubernetes
Service) in Kong. Kong load balances across the Pods of your service.
This means that all requests flowing through Kong are not directed via
kube-proxy but directly to the pod.
An Ingress resource in Kubernetes defines a set of rules for proxying traffic.
These rules correspond to the concept of a route in Kong.
The following image describes the relationship between Kubernetes concepts and Kong’s
Gateway API resources can also be used to produce running instances
and configurations for Kong Gateway.
The main concepts here are:
- A Gateway resource in Kubernetes describes how traffic
can be translated to services within the cluster.
- A GatewayClass defines a set of Gateways that share
a common configuration and behaviour.
Each GatewayClass will be handled by a single controller, although controllers
may handle more than one GatewayClass.
HTTPRoute can be attached to a Gateway which will
configure the HTTP routing behavior.
You can find more details about Gateway API concepts supported by Kong Ingress Controller