Architecture

The Kong Ingress Controller configures Kong Gateway using Ingress or Gateway API resources created inside a Kubernetes cluster.

Kong Ingress Controller enables you to configure plugins, load balance the services, check the health of the Pods, and leverage all that Kong offers in a standalone installation.

The Kong Ingress Controller does not proxy any traffic directly. It configures Kong Gateway using Kubernetes resources.

The figure illustrates how Kong Ingress Controller works:

 
flowchart LR
    subgraph Kubernetes cluster
        direction LR
        A( API server) --> |events| B(Controller)
        B --> |configuration| C(Kong)
        C --> D(services)
    end

    E(Request traffic)
    E --> C

    %% Change the arrow colors
    linkStyle 0,1 stroke:#d44324,color:#d44324  
    linkStyle 2,3 stroke:#b6d7a8
  

The Controller listens for changes inside the Kubernetes cluster and dynamically updates Kong Gateway in response to those changes. In this setup, Kong Gateway can respond to changes around scaling, configuration, and failures that occur inside a Kubernetes cluster in real time.

For more information on how Kong Gateway works with Routes, Gateway Services, and Upstreams, please see the proxy and load balancing documentation.

In Kubernetes, there are several concepts that are used to logically identify workloads and route traffic between them.

Service / Pods

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

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.

Ingress

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