Kong for Kubernetes is an open-source Ingress Controller for Kubernetes that offers API management capabilities with a plugin architecture.
Giant Swarm offers a Kong Managed App which can be installed in workload clusters.
| Giant Swarm Chart Release | Upstream Chart Release | Kong Version | Kong IC Version | Kong-Gateway Enterprise container tag |
|---|---|---|---|---|
| Unreleased | 07ddc3d | 3.6.1 | 3.1.4 | 3.6.1.3-debian |
| v4.1.0 | 07ddc3d | 3.6.1 | 3.1.4 | 3.6.1.3-debian |
| v4.0.0 | 07ddc3d | 3.6.1 | 3.1.3 | 3.6.1.3-debian |
| v3.8.0 | 2.35.1 | 3.5.0 | 3.0.2 | 3.5.0.3-debian |
| v3.7.0 | 2.33.3 | 3.5.0 | 3.0.2 | 3.5.0.2-debian |
| v3.6.2 | 2.33.1 | 3.5.0 | 3.0.1 | 3.5.0.1-debian |
| v3.6.1 | 2.33.1 | 3.5.0 | 3.0.1 | 3.5.0.1-debian |
| v3.6.0 | 2.33.0 | 3.5.0 | 3.0.1 | 3.5.0.1-debian |
| v3.5.0 | 2.29.0 | 3.4.2 | 2.12.0 | 3.4.1.1-debian |
| v3.4.0 | 2.23.0 | 3.3.1 | 2.10.4 | 3.3.1.0-debian |
| v3.3.0 | 2.21.0 | 3.2.2 | 2.9.3 | 3.2.2.1-debian |
| v3.2.0 | 2.20.1 | 3.2.2 | 2.9.3 | 3.2.2.1-debian |
| v3.1.1 | 2.19.1 | 3.2.2 | 2.9.3 | 3.2.2.1-debian |
| v3.1.0 | 2.19.0 | 3.2.2 | 2.9.3 | 3.2.2.1-debian |
| v3.0.1 | 2.16.4 | 3.1.1 | 2.8.1 | 3.1.1.3-debian |
| v3.0.0 | 2.16.2 | 3.1.1 | 2.8.1 | 3.1.1.3-debian |
For older versions, please refer to the changelog
This Chart is configured to deploy Kong Enterprise. For instructions on how to deploy Kong Enterprise please read Kong Enterprise.
When supplying a set of custom configuration options, only include configuation you want to change. DO NOT copy the whole values.yaml file.
For detailed explanations of configuration options, please refer to the list of configuration options and
also the values.yaml file
Any key value put under the env section translates to environment variables
used to control Kong's configuration. Every key is prefixed with KONG_ and
upper-cased before setting the environment variable.
This app does not by default provide a database and if a database is required, then you will need to BYOD (Bring Your Own Database). For testing purposes, it is possible launch postgres alongside this App (described below).
The default installation of the App will use Kong Ingress Controller. The recommended way to configure plugins, consumers and services when using Kong for Kubernetes is by utilizing Kong annotations and Kong custom resources.
A basic installation of Kong for Kubernetes will require some custom values.
image:
repository: giantswarm/kong
tag: "3.6.1"
enterprise:
enabled: falseYou can change the container image registry by setting the following values in your values.yaml file
image:
registry: ®istry docker.io
ingressController:
image:
registry: *registry
# In case you've enabled the postgresql sub-chart
# postgresql:
# image:
# registry: *registry
# In case you've changed the default waitImage
# waitImage:
# registry: *registryKong enterprise requires a valid enterprise license Secret to be present in the target namespace for kong.
Save the license key to a plain text file named kong-enterprise-license.json.
Then create the Secret with name kong-enterprise-license in namespace kong-app by running the following command:
kubectl create secret generic kong-enterprise-license \
--namespace kong-app \
--from-file=license=./kong-enterprise-license.jsonKong supports PostgreSQL version 9.5 up to 15.
Example database configuration:
env:
database: "postgres" # can be "off" or "postgres"
pg_host: 127.0.0.1
pg_port: 12345
pg_user: postgres
pg_password: # This can also be a string value, but not recommended
valueFrom:
secretKeyRef:
name: postgres
key: kongnote: If pg_port is not set then it will default to 5432
For testing purposes, it is possible to install a PostgreSQL server alongside the App. To do this, you'll need to specify the following app configuration:
postgresql:
enabled: true(There is no need to add PostgreSQL configuration data to env, a default user
and password will be used.)
Please note: This configuration should only be used for testing and is not officially supported by Giant Swarm.
When using Kong Ingress Controller, a database is not required. However in some cases (for example, plugin support, Kong developer portal) a database is required. The Kong Ingress Controller does not communicate with the database directly. Instead, it uses the Admin API of the proxy container which then persists configuration either in memory or in the configured database.
Like in the case of using a database, Giant Swarm does not support the database and can only provide best efforts support with this configuration.
To configure, please see 'Using your own Database'.
But ensure that that ingressController.enabled is set to true.
Note:
Is it possible to create consumers using the Admin API?
From version 0.5.0 onwards, Kong Ingress Controller tags each entity that it manages inside Kong's database and only manages the entities that it creates. This means that if consumers and credentials are created dynamically, they won't be deleted by the Ingress Controller. (Taken from https://docs.konghq.com/kubernetes-ingress-controller/latest/faq/#is-it-possible-to-create-consumers-using-the-admin-api)
When installed through the Giant Swarm App platform, CRD installation is taken care of automatically.
The helm chart in this repository undergoes a series of automated tests running on a kind cluster (kind cluster config) executed by app-test-suite. (chart values used for tests)
Testing includes creation of Deployment, Service, and Ingress resources to check if reconciliation works as intended.
To execute tests on your machine, obtain a copy of the dats.sh helper script and a chart archive (helm pull https://giantswarm.github.io/giantswarm-catalog/kong-app-2.5.0.tgz or build an archive with your changes using app-build-suite), then execute
./dats.sh -c kong-app-2.5.0.tgz
Please check out file .ats/main.yaml for some additional hints configuring app-test-suite.
The repository includes resources to test this chart and chart upgrades in directory tests/manual.
Please visit https://www.giantswarm.io/responsible-disclosure for information on reporting security issues.