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.8.x (latest)
  • 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
    • FAQ
    • Version Support Policy
    • Stages of Software Availability
    • Changelog
    • Architecture
    • Custom Resources
    • Deployment Methods
    • Kong for Kubernetes with Kong Enterprise
    • High-Availability and Scaling
    • Resource Classes
    • Security
    • Ingress Resource API Versions
    • Gateway API
    • Kong Ingress on Minikube
    • Kong for Kubernetes
    • Kong for Kubernetes Enterprise
    • Kong for Kubernetes with Kong Enterprise
    • Kong Ingress on AKS
    • Kong Ingress on EKS
    • Kong Ingress on GKE
    • Admission Webhook
    • Installing Gateway APIs
    • Getting Started with KIC
    • Upgrading from previous versions
    • Upgrading to Kong 3.x
    • Getting Started using Istio
      • Using the KongPlugin Resource
      • Using the KongIngress Resource
      • Using KongConsumer and KongCredential Resources
      • Using the TCPIngress Resource
      • Using the UDPIngress Resource
    • Using the ACL and JWT Plugins
    • Using cert-manager with Kong
    • Allowing Multiple Authentication Methods
    • Configuring a Fallback Service
    • Using an External Service
    • Configuring HTTPS Redirects for Services
    • Using Redis for Rate Limiting
    • Integrate KIC with Prometheus/Grafana
    • Configuring Circuit-Breaker and Health-Checking
    • Setting up a Custom Plugin
    • Using Ingress with gRPC
    • Setting up Upstream mTLS
    • Exposing a TCP Service
    • Exposing a UDP Service
    • Using the mTLS Auth Plugin
    • Configuring Custom Entities
    • Using the OpenID Connect Plugin
    • Rewriting Hosts and Paths
    • Preserving Client IP Address
    • Using Kong with Knative
    • Using Multiple Backend Services
    • KIC Annotations
    • CLI Arguments
    • Custom Resource Definitions
    • Plugin Compatibility
    • Version Compatibility
    • Supported Kong Router Flavors
    • Troubleshooting
    • Prometheus Metrics
    • Feature Gates
    • Supported Gateway API Features

github-edit-pageEdit this page

report-issueReport an issue

enterprise-switcher-iconSwitch to OSS

On this page
  • High availability
    • Leader election (database-backed clusters only)
  • Scaling
Kubernetes Ingress Controller
2.8.x (latest)
  • Home
  • Kubernetes Ingress Controller
  • Concepts
  • High-availability and Scaling

High-availability and Scaling

High availability

The Kubernetes Ingress Controller is designed to be reasonably easy to operate and be highly available, meaning, when some expected failures do occur, the Controller should be able to continue to function with minimum possible service disruption.

The Kubernetes Ingress Controller is composed of two parts: 1. Kong, which handles the requests, 2. Controller, which configures Kong dynamically.

Kong itself can be deployed in a highly-available manner by deploying multiple instances (or pods). Kong nodes are state-less, meaning a Kong pod can be terminated and restarted at any point of time.

The controller itself can be stateful or stateless, depending on if a database is being used or not.

If a database is not used, then the Controller and Kong are deployed as co-located containers in the same pod and each controller configures the Kong container that it is running with.

For cases when a database is necessary, the Controllers can be deployed on multiple zones to provide redundancy. In such a case, a leader election process will elect one instance as a leader, which will manipulate Kong’s configuration.

Leader election (database-backed clusters only)

Multiple Kubernetes Ingress Controller instances elect a leader when connected to a database-backed cluster. This ensures that only a single controller pushes configuration to Kong’s database to avoid potential conflicts and race conditions. When a leader controller shuts down, other instances will detect that there is no longer a leader, and one will promote itself to the leader.

For this reason, the controller needs permission to create a ConfigMap. By default, the permission is given at Cluster level, but it can be narrowed down to a single namespace (using Role and RoleBinding) for a stricter RBAC policy.

It also needs permission to read and update this ConfigMap. This permission can be specific to the ConfigMap that is being used for leader-election purposes. The name of the ConfigMap is derived from the value of election-id CLI flag (default: ingress-controller-leader) and ingress-class (default: kong) as: “-". For example, the default ConfigMap that is used for leader election will be `ingress-controller-leader-kong`, and it will be present in the same namespace that the controller is deployed in.

Scaling

Kong is designed to be horizontally scalable, meaning as traffic increases, multiple instances of Kong can be deployed to handle the increase in load.

The configuration is either pumped into Kong directly via the Ingress Controller or loaded via the database. Kong containers can be considered stateless as the configuration is either loaded from the database (and cached heavily in-memory) or loaded in-memory directly via a config file.

One can use a HorizontalPodAutoscaler (HPA) based on metrics like CPU utilization, bandwidth being used, total request count per second to dynamically scale Kubernetes Ingress Controller as the traffic profile changes.

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