Skip to content
Kong Logo | Kong Docs Logo
search
  • We're Hiring!
  • Docs
    • Kong Gateway
    • Kong Konnect
    • Kong Mesh
    • Plugin Hub
    • decK
    • Kubernetes Ingress Controller
    • Insomnia
    • Kuma

    • Docs contribution guidelines
  • Plugin Hub
  • Support
  • Community
  • Kong Academy
Get a Demo Start Free Trial
  • Kong Gateway
  • Kong Konnect
  • Kong Mesh
  • Plugin Hub
  • decK
  • Kubernetes Ingress Controller
  • Insomnia
  • Kuma

  • Docs contribution guidelines
  • 2.9.x (latest)
  • 2.8.x
  • 2.7.x
  • 2.6.x
  • 2.5.x
  • 2.4.x
  • 2.3.x
  • 2.2.x
  • 2.1.x
  • 2.0.x
  • 1.3.x
  • 1.2.x
  • 1.1.x
  • 1.0.x

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this pageOn this page
  • Overview
  • Translation
Kubernetes Ingress Controller
1.2.x
  • Home
  • Kubernetes Ingress Controller
  • Concepts
  • Kubernetes Ingress Controller Design
You are browsing documentation for an outdated version. See the latest documentation here.

Kubernetes Ingress Controller Design

Overview

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

The Kubernetes Ingress Controller is made up of two components:

  • Kong, the core proxy that handles all the traffic
  • Controller, a process that syncs the configuration from Kubernetes to Kong

The Kubernetes 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 standalone installation.

The following figure shows how it works:

high-level-design

The Controller 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 cluster.

Translation

Kubernetes resources are mapped to Kong resources to correctly proxy all the traffic.

The following figure describes the mapping between Kubernetes concepts to Kong’s configuration:

translating k8s to kong

Let’s go through how Kubernetes resources are being mapped to Kong’s configuration:

  • An Ingress resource in Kubernetes defines a set of rules for proxying traffic. These rules corresponds to the concept of Route in Kong.
  • 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 healthchecking 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.

For more information on how Kong works with Routes, Services, and Upstreams, please see the Proxy and Load balancing references.

Thank you for your feedback.
Was this page useful?
  • Kong
    THE CLOUD CONNECTIVITY COMPANY

    Kong powers reliable digital connections across APIs, hybrid and multi-cloud environments.

    • Company
    • Customers
    • Events
    • Investors
    • Careers Hiring!
    • Partners
    • Press
    • Contact
  • Products
    • Kong Konnect
    • Kong Gateway
    • Kong Mesh
    • Get Started
    • Pricing
  • Resources
    • eBooks
    • Webinars
    • Briefs
    • Blog
    • API Gateway
    • Microservices
  • Open Source
    • Install Kong Gateway
    • Kong Community
    • Kubernetes Ingress
    • Kuma
    • Insomnia
  • Solutions
    • Decentralize
    • Secure & Govern
    • Create a Dev Platform
    • API Gateway
    • Kubernetes
    • Service Mesh
Star
  • Terms•Privacy
© Kong Inc. 2023