In Kubernetes, there are several concepts that are used to logically identify workloads and route traffic between them.
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 Gateway: Gateway Service and Upstream.
The Gateway Service object in Kong Gateway holds the information of the protocol needed to talk to the upstream service and various other protocol-specific settings. The Upstream object defines load balancing and health-checking behavior.
Each Kubernetes Service is defined as an Upstream in Kong Gateway. Each Pod associated with the Kubernetes Service is added as a Target within the Upstream. Kong Gateway load balances across the Pods of your service. This means that all requests flowing through Kong Gateway are not directed through kube-proxy but directly to the Pod.
Gateway API resources can also be used to produce running instances and configurations for Kong Gateway.
The main concepts of the Gateway API 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 is handled by a single controller, although controllers
may handle more than one GatewayClass.
-
HTTPRoute can be attached to a Gateway which
configures the HTTP routing behavior.
For more information about Gateway API resources and features supported by Kong Ingress Controller, see
Gateway API.
An Ingress resource in Kubernetes defines a set of rules for proxying traffic. These rules correspond to the concept of a Route in Kong Gateway.
The following diagram describes the relationship between Kubernetes concepts and Kong’s Ingress configuration. The colored boxes represent Kong concepts, and the outer boxes represent Kubernetes concepts.
flowchart LR
H(Request traffic)
subgraph Pods
direction LR
E(Target)
F(Target)
G(Target)
end
subgraph Kubernetes Service
direction TB
C(Service)
D(Upstream)
end
subgraph Ingress / Gateway API
direction LR
A(Route)
B(Route)
end
A --> C
B --> C
C --> D
D --> E
D --> F
D --> G
H --> A