KongHQ

Read about Charts

helm repo add kong https://charts.konghq.com

# Install the Gateway API CRDs
# This command will install all resources that have graduated to GA or beta, including GatewayClass, Gateway, HTTPRoute, and ReferenceGrant.
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/standard-install.yaml

# Or, if you want to use experimental resources and fields such as TCPRoutes and UDPRoutes, please run this command.
kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.0.0/experimental-install.yaml

• Data Plane: The Kong Gateway data plane is responsible for processing incoming traffic. It receives the routing configuration from the control plane using the clustering endpoint. This is built over Nginx as the base
  • Gateway: This is proxy server which is node of Data plane
    • Admin API: Manage on-prem Kong Gateway entities via an API, url shows avaiable config syntaxes
• Control Plane: The control plane contains all Kong Gateway configurations. The configuration is stored in a PostgreSQL database.
  • The control plane is where operators access kong for pushing configs and fetching logs
  • Operating modes:
    • DB Less Mode: In this mode the entire configuration is managed in-memory loaded from a configuration file.
      • Some of the pulugins like rate limiting will not work fully in a DB less model.
    • DB Mode (Traditional): persists all the configurations in a DB with a couple of choices(Cassandra / PostgreSQL). It's also important to note that kong stores all the configuration in memory for better performance. DB is reached mostly to refresh config on change. Cassandra has its own advantage of horizontal scaling to match the horizontal scalability of Kong. The fully functional mode for Kong Gateway is traditional mode (also known as DB mode). in traditional mode, you cannot push configs using Kubernetes CRDs. CRDs are used with Kong Ingress Controller or Kong Gateway Operator in Kubernetes environments, not with traditional mode.
• Ingress Controller: Configure Kong Gateway using Kubernetes-native resources such as httproute and ingress.

CRDs (Custom Resource Definitions) are used to provide a Kubernetes-native way to configure Kong Gateway. Both the Kong Ingress Controller (KIC) and the Kong Gateway Operator use CRDs, but in different ways:

• Kong Ingress Controller: KIC uses CRDs to allow you to manage Kong Gateway configuration using Kubernetes resources like KongPlugin, KongConsumer, etc. This is the standard method for configuring Kong Gateway in Kubernetes with KIC Custom Resources.
• Kong Gateway Operator: The Operator is also Kubernetes-native and is driven entirely by CRDs. It allows you to deploy and configure Kong’s products in a fully declarative way using Kubernetes resources About Kong Gateway Operator.

NOTE kong/kong-operator is new name for kong/gateway-operator. Github page always redirects to kong-operator for both

Install Kong Ingress Controller (KIC)

This is the primary and recommended Helm chart for deploying Kong Gateway as an Ingress Controller within a Kubernetes cluster. It includes the Kong Ingress Controller, which acts as the control plane, translating Kubernetes Ingress and other custom resources (like KongPlugin, KongConsumer, etc.) into a configuration that the Kong Gateway (data plane) can understand and apply. The kong/ingress chart essentially sets up Kong to manage inbound traffic for your Kubernetes services using Kubernetes-native APIs.

In essence: provides the complete solution for running Kong as an Ingress Controller in Kubernetes, including both the control plane (Ingress Controller) and the data plane (Kong Gateway).

Therefore, when deploying Kong to manage traffic in a Kubernetes environment, the kong/ingress Helm chart is the appropriate choice as it automates the integration with Kubernetes Ingress and other resources.

• The Kong Ingress Controller configures Kong Gateway using Ingress or Gateway API resources created inside a Kubernetes cluster.
• KIC does not handle traffic directly; it only updates Kong Gateway’s configuration in response to changes in the Kubernetes cluster.
• CRDs are used with Kong Ingress Controller or Kong Gateway Operator in Kubernetes environments, not with traditional mode.

Deploy Kong Gateway on Kubernetes

This chart is a dependency of the kong/ingress chart. It specifically deploys the Kong Gateway itself, which is the data plane responsible for proxying and managing API traffic. While you could theoretically deploy just the kong/kong chart, it would require manual configuration of Kong Gateway, as it wouldn't be integrated with the Kubernetes Ingress mechanism without the Kong Ingress Controller.

In essence: provides only the Kong Gateway data plane, and is leveraged by the kong/ingress chart to deploy the core proxy functionality.

Kong Gateway is the API gateway that proxies and manages traffic.

REFERENCE

• Kong Gateway
  • All Gateway docs
  • All KIC docs
• Kong Ingress Controller
• Plugins
  • Kong Gateway entities: Plugins
  • Kong Gateway Plugins Compatibility
• Tools
  • decK CLI: Manage Kong Gateway configuration through declarative state files
  • terraform
• Kong Manager configuration
• Upgrade