X-Git-Url: https://gerrit.o-ran-sc.org/r/gitweb?a=blobdiff_plain;f=helm%2Finfrastructure%2Fsubcharts%2Fkong%2FREADME.md;h=83b665df320ce3ad8df73a144575ad544ae86f26;hb=7a43fbd4642448783aaf708d07ca883bf9bc5afd;hp=be6bc157cd2a916475bde1ace0c371645f32423e;hpb=38dc857062b14145f5b9db89d10eba0ae5b90d11;p=ric-plt%2Fric-dep.git diff --git a/helm/infrastructure/subcharts/kong/README.md b/helm/infrastructure/subcharts/kong/README.md index be6bc15..83b665d 100755 --- a/helm/infrastructure/subcharts/kong/README.md +++ b/helm/infrastructure/subcharts/kong/README.md @@ -1,46 +1,70 @@ -## Kong +# DEPRECATED -[Kong](https://KongHQ.com/) is an open-source API Gateway and Microservices -Management Layer, delivering high performance and reliability. +This chart has been deprecated in favor of +Kong's official chart [repository](https://github.com/kong/charts). + +All users are advised to immediately migrate over to the new repository. + +## Kong for Kubernetes + +[Kong for Kubernetes](https://github.com/Kong/kubernetes-ingress-controller) +is an open-source Ingress Controller for Kubernetes that offers +API management capabilities with a plugin architecture. + +This chart bootstraps all the components needed to run Kong on a +[Kubernetes](http://kubernetes.io) cluster using the +[Helm](https://helm.sh) package manager. ## TL;DR; ```bash +$ helm repo update $ helm install stable/kong ``` -## Introduction - -This chart bootstraps all the components needed to run Kong on a [Kubernetes](http://kubernetes.io) -cluster using the [Helm](https://helm.sh) package manager. +## Table of content + +- [Prerequisites](#prerequisites) +- [Install](#install) +- [Uninstall](#uninstall) +- [Kong Enterprise](#kong-enterprise) +- [FAQs](#faqs) +- [Deployment Options](#deployment-options) + - [Database](#database) + - [Runtime package](#runtime-package) + - [Configuration method](#configuration-method) +- [Configuration](#configuration) + - [Kong Parameters](#kong-parameters) + - [Ingress Controller Parameters](#ingress-controller-parameters) + - [General Parameters](#general-parameters) + - [The `env` section](#the-env-section) +- [Kong Enterprise Parameters](#kong-enterprise-parameters) + - [Prerequisites](#prerequisites-1) + - [Kong Enterprise License](#kong-enterprise-license) + - [Kong Enterprise Docker registry access](#kong-enterprise-docker-registry-access) + - [Service location hints](#service-location-hints) + - [RBAC](#rbac) + - [Sessions](#sessions) + - [Email/SMTP](#emailsmtp) +- [Changelog](#changelog) +- [Seeking help](#seeking-help) ## Prerequisites -- Kubernetes 1.8+ with Beta APIs enabled. +- Kubernetes 1.12+ - PV provisioner support in the underlying infrastructure if persistence is needed for Kong datastore. -## Installing the Chart +## Install To install the chart with the release name `my-release`: ```bash +$ helm repo update $ helm install --name my-release stable/kong ``` -If using Kong Enterprise, several additional steps are necessary before -installing the chart. At minimum, you must: -* Create a [license secret](#license). -* Set `enterprise.enabled: true` in values.yaml. -* Update values.yaml to use a Kong Enterprise image. If needed, follow the -instructions in values.yaml to add a registry pull secret. - -Reading through [the full list of Enterprise considerations](#kong-enterprise-specific-parameters) -is recommended. - -> **Tip**: List all releases using `helm list` - -## Uninstalling the Chart +## Uninstall To uninstall/delete the `my-release` deployment: @@ -51,12 +75,122 @@ $ helm delete my-release The command removes all the Kubernetes components associated with the chart and deletes the release. -## Configuration +> **Tip**: List all releases using `helm list` + +## FAQs + +Please read the +[FAQs](https://github.com/helm/charts/blob/master/stable/kong/FAQs.md) +document. + +## Kong Enterprise + +If using Kong Enterprise, several additional steps are necessary before +installing the chart: + +- set `enterprise.enabled` to `true` in `values.yaml` file +- Update values.yaml to use a Kong Enterprise image +- Satisfy the two prerequsisites below for + [Enterprise License](#kong-enterprise-license) and + [Enterprise Docker Registry](#kong-enterprise-docker-registry-access) + +Once you have these set, it is possible to install Kong Enterprise + +Please read through +[Kong Enterprise considerations](#kong-enterprise-parameters) +to understand all settings that are enterprise specific. + +## Deployment Options + +Kong is a highly configurable piece of software that can be deployed +in a number of different ways, depending on your use-case. + +All combinations of various runtimes, databases and configuration methods are +supported by this Helm chart. +The recommended approach is to use the Ingress Controller based configuration +along-with DB-less mode. + +Following sections detail on various high-level architecture options available: + +### Database -### General Configuration Parameters +Kong can run with or without a database (DB-less). +By default, this chart installs Kong without a database. -The following table lists the configurable parameters of the Kong chart -and their default values. +Although Kong can run with Postgres and Cassandra, the recommended database, +if you would like to use one, is Postgres for Kubernetes installations. +If your use-case warrants Cassandra, you should run the Cassandra cluster +outside of Kubernetes. + +The database to use for Kong can be controlled via the `env.database` parameter. +For more details, please read the [env](#the-env-section) section. + +Furthermore, this chart allows you to bring your own database that you manage +or spin up a new Postgres instance using the `postgres.enabled` parameter. + +> Cassandra deployment via a sub-chart was previously supported but +the support has now been dropped due to stability issues. +You can still deploy Cassandra on your own and configure Kong to use +that via the `env.database` parameter. + +#### DB-less deployment + +When deploying Kong in DB-less mode(`env.database: "off"`) +and without the Ingress Controller(`ingressController.enabled: false`), +you have to provide a declarative configuration for Kong to run. +The configuration can be provided using an existing ConfigMap +(`dblessConfig.configMap`) or or the whole configuration can be put into the +`values.yaml` file for deployment itself, under the `dblessConfig.config` +parameter. See the example configuration in the default values.yaml +for more details. + +### Runtime package + +There are three different packages of Kong that are available: + +- **Kong Gateway** + This is the [Open-Source](https://github.com/kong/kong) offering. It is a + full-blown API Gateway and Ingress solution with a wide-array of functionality. + When Kong Gateway is combined with the Ingress based configuration method, + you get Kong for Kubernetes. This is the default deployment for this Helm + Chart. +- **Kong Enterprise K8S** + This package builds up on top of the Open-Source Gateway and bundles in all + the Enterprise-only plugins as well. + When Kong Enterprise K8S is combined with the Ingress based + configuration method, you get Kong for Kubernetes Enterprise. + This package also comes with 24x7 support from Kong Inc. +- **Kong Enterprise** + This is the full-blown Enterprise package which packs with itself all the + Enterprise functionality like Manager, Portal, Vitals, etc. + This package can't be run in DB-less mode. + +The package to run can be changed via `image.repository` and `image.tag` +parameters. If you would like to run the Enterprise package, please read +the [Kong Enterprise Parameters](#kong-enterprise-parameters) section. + +### Configuration method + +Kong can be configured via two methods: +- **Ingress and CRDs** + The configuration for Kong is done via `kubectl` and Kubernetes-native APIs. + This is also known as Kong Ingress Controller or Kong for Kubernetes and is + the default deployment pattern for this Helm Chart. The configuration + for Kong is managed via Ingress and a few + [Custom Resources](https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/concepts/custom-resources.md). + For more details, please read the + [documentation](https://github.com/Kong/kubernetes-ingress-controller/tree/master/docs) + on Kong Ingress Controller. + To configure and fine-tune the controller, please read the + [Ingress Controller Parameters](#ingress-controller-parameters) section. +- **Admin API** + This is the traditional method of running and configuring Kong. + By default, the Admin API of Kong is not exposed as a Service. This + can be controlled via `admin.enabled` and `env.admin_listen` parameters. + +## Configuration + +### Kong parameters | Parameter | Description | Default | | ---------------------------------- | ------------------------------------------------------------------------------------- | ------------------- | @@ -65,6 +199,7 @@ and their default values. | image.pullPolicy | Image pull policy | `IfNotPresent` | | image.pullSecrets | Image pull secrets | `null` | | replicaCount | Kong instance count | `1` | +| admin.enabled | Create Admin Service | `false` | | admin.useTLS | Secure Admin traffic | `true` | | admin.servicePort | TCP port on which the Kong admin service is exposed | `8444` | | admin.containerPort | TCP port on which Kong app listens for admin traffic | `8444` | @@ -88,7 +223,9 @@ and their default values. | proxy.tls.servicePort | Service port to use for TLS | 8443 | | proxy.tls.nodePort | Node port to use for TLS | 32443 | | proxy.tls.hostPort | Host port to use for TLS | | -| proxy.type | k8s service type. Options: NodePort, ClusterIP, LoadBalancer | `NodePort` | +| proxy.tls.overrideServiceTargetPort| Override service port to use for TLS without touching Kong containerPort | | +| proxy.type | k8s service type. Options: NodePort, ClusterIP, LoadBalancer | `LoadBalancer` | +| proxy.clusterIP | k8s service clusterIP | | | proxy.loadBalancerSourceRanges | Limit proxy access to CIDRs if set and service type is `LoadBalancer` | `[]` | | proxy.loadBalancerIP | To reuse an existing ingress static IP for the admin service | | | proxy.externalIPs | IPs for which nodes in the cluster will also accept traffic for the proxy | `[]` | @@ -98,9 +235,44 @@ and their default values. | proxy.ingress.hosts | List of ingress hosts. | `[]` | | proxy.ingress.path | Ingress path. | `/` | | proxy.ingress.annotations | Ingress annotations. See documentation for your ingress controller for details | `{}` | -| updateStrategy | update strategy for deployment | `{}` | +| plugins | Install custom plugins into Kong via ConfigMaps or Secrets | `{}` | | env | Additional [Kong configurations](https://getkong.org/docs/latest/configuration/) | | | runMigrations | Run Kong migrations job | `true` | +| waitImage.repository | Image used to wait for database to become ready | `busybox` | +| waitImage.tag | Tag for image used to wait for database to become ready | `latest` | +| waitImage.pullPolicy | Wait image pull policy | `IfNotPresent` | +| postgresql.enabled | Spin up a new postgres instance for Kong | `false` | +| dblessConfig.configMap | Name of an existing ConfigMap containing the `kong.yml` file. This must have the key `kong.yml`.| `` | +| dblessConfig.config | Yaml configuration file for the dbless (declarative) configuration of Kong | see in `values.yaml` | + +### Ingress Controller Parameters + +All of the following properties are nested under the `ingressController` +section of `values.yaml` file: + +| Parameter | Description | Default | +| ---------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | +| enabled | Deploy the ingress controller, rbac and crd | true | +| replicaCount | Number of desired ingress controllers | 1 | +| image.repository | Docker image with the ingress controller | kong-docker-kubernetes-ingress-controller.bintray.io/kong-ingress-controller | +| image.tag | Version of the ingress controller | 0.7.0 | +| readinessProbe | Kong ingress controllers readiness probe | | +| livenessProbe | Kong ingress controllers liveness probe | | +| env | Specify Kong Ingress Controller configuration via environment variables | | +| ingressClass | The ingress-class value for controller | kong | +| admissionWebhook.enabled | Whether to enable the validating admission webhook | false | +| admissionWebhook.failurePolicy | How unrecognized errors from the admission endpoint are handled (Ignore or Fail) | Fail | +| admissionWebhook.port | The port the ingress controller will listen on for admission webhooks | 8080 | + +For a complete list of all configuration values you can set in the +`env` section, please read the Kong Ingress Controller's +[configuration document](https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/references/cli-arguments.md). + +### General Parameters + +| Parameter | Description | Default | +| ---------------------------------- | ------------------------------------------------------------------------------------- | ------------------- | +| updateStrategy | update strategy for deployment | `{}` | | readinessProbe | Kong readiness probe | | | livenessProbe | Kong liveness probe | | | affinity | Node/pod affinities | | @@ -111,178 +283,139 @@ and their default values. | podDisruptionBudget.enabled | Enable PodDisruptionBudget for Kong | `false` | | podDisruptionBudget.maxUnavailable | Represents the minimum number of Pods that can be unavailable (integer or percentage) | `50%` | | podDisruptionBudget.minAvailable | Represents the number of Pods that must be available (integer or percentage) | | +| podSecurityPolicy.enabled | Enable podSecurityPolicy for Kong | `false` | | serviceMonitor.enabled | Create ServiceMonitor for Prometheus Operator | false | | serviceMonitor.interval | Scrapping interval | 10s | | serviceMonitor.namespace | Where to create ServiceMonitor | | +| secretVolumes | Mount given secrets as a volume in Kong container to override default certs and keys. | `[]` | +| serviceMonitor.labels | ServiceMonito Labels | {} | -### Admin/Proxy listener override +#### The `env` section -If you specify `env.admin_listen` or `env.proxy_listen`, this chart will use -the value provided by you as opposed to constructing a listen variable -from fields like `proxy.http.containerPort` and `proxy.http.enabled`. This allows -you to be more prescriptive when defining listen directives. +The `env` section can be used to configured all properties of Kong. +Any key value put under this 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. -**Note:** Overriding `env.proxy_listen` and `env.admin_listen` will potentially cause -`admin.containerPort`, `proxy.http.containerPort` and `proxy.tls.containerPort` to become out of sync, -and therefore must be updated accordingly. - -I.E. updatating to `env.proxy_listen: 0.0.0.0:4444, 0.0.0.0:4443 ssl` will need -`proxy.http.containerPort: 4444` and `proxy.tls.containerPort: 4443` to be set in order -for the service definition to work properly. - -### Kong-specific parameters - -Kong has a choice of either Postgres or Cassandra as a backend datatstore. -This chart allows you to choose either of them with the `env.database` -parameter. Postgres is chosen by default. - -Additionally, this chart allows you to use your own database or spin up a new -instance by using the `postgres.enabled` or `cassandra.enabled` parameters. -Enabling both will create both databases in your cluster, but only one -will be used by Kong based on the `env.database` parameter. -Postgres is enabled by default. - -| Parameter | Description | Default | -| ------------------------------| ------------------------------------------------------------------------| ----------------------| -| cassandra.enabled | Spin up a new cassandra cluster for Kong | `false` | -| postgresql.enabled | Spin up a new postgres instance for Kong | `true` | -| waitImage.repository | Image used to wait for database to become ready | `busybox` | -| waitImage.tag | Tag for image used to wait for database to become ready | `latest` | -| env.database | Choose either `postgres`, `cassandra` or `"off"` (for dbless mode) | `postgres` | -| env.pg_user | Postgres username | `kong` | -| env.pg_database | Postgres database name | `kong` | -| env.pg_password | Postgres database password (required if you are using your own database)| `kong` | -| env.pg_host | Postgres database host (required if you are using your own database) | `` | -| env.pg_port | Postgres database port | `5432` | -| env.cassandra_contact_points | Cassandra contact points (required if you are using your own database) | `` | -| env.cassandra_port | Cassandra query port | `9042` | -| env.cassandra_keyspace | Cassandra keyspace | `kong` | -| env.cassandra_repl_factor | Replication factor for the Kong keyspace | `2` | -| dblessConfig.configMap | Name of an existing ConfigMap containing the `kong.yml` file. This must have the key `kong.yml`.| `` | -| dblessConfig.config | Yaml configuration file for the dbless (declarative) configuration of Kong | see in `values.yaml` | - -All `kong.env` parameters can also accept a mapping instead of a value to ensure the parameters can be set through configmaps and secrets. +Furthermore, all `kong.env` parameters can also accept a mapping instead of a +value to ensure the parameters can be set through configmaps and secrets. An example : ```yaml kong: - env: + env: # load PG password from a secret dynamically pg_user: kong pg_password: valueFrom: secretKeyRef: key: kong name: postgres + nginx_worker_processes: "2" ``` +For complete list of Kong configurations please check the +[Kong configuration docs](https://docs.konghq.com/latest/configuration). -For complete list of Kong configurations please check https://getkong.org/docs/latest/configuration/. +> **Tip**: You can use the default [values.yaml](values.yaml) -Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, +##### Admin/Proxy listener override -```console -$ helm install stable/kong --name my-release \ - --set=image.tag=1.3,env.database=cassandra,cassandra.enabled=true -``` +If you specify `env.admin_listen` or `env.proxy_listen`, this chart will use +the value provided by you as opposed to constructing a listen variable +from fields like `proxy.http.containerPort` and `proxy.http.enabled`. +This allows you to be more prescriptive when defining listen directives. -Alternatively, a YAML file that specifies the values for the above parameters -can be provided while installing the chart. For example, +**Note:** Overriding `env.proxy_listen` and `env.admin_listen` will +potentially cause `admin.containerPort`, `proxy.http.containerPort` and +`proxy.tls.containerPort` to become out of sync, +and therefore must be updated accordingly. -```console -$ helm install stable/kong --name my-release -f values.yaml -``` +For example, updating to `env.proxy_listen: 0.0.0.0:4444, 0.0.0.0:4443 ssl` +will need `proxy.http.containerPort: 4444` and `proxy.tls.containerPort: 4443` +to be set in order for the service definition to work properly. -> **Tip**: You can use the default [values.yaml](values.yaml) +## Kong Enterprise Parameters -### Kong Enterprise-specific parameters +### Overview Kong Enterprise requires some additional configuration not needed when using -Kong OSS. Some of the more important configuration is grouped in sections -under the `.enterprise` key in values.yaml, though most enterprise-specific -configuration can be placed under the `.env` key. +Kong Open-Source. To use Kong Enterprise, at the minimum, +you need to do the following: -To use Kong Enterprise, change your image to a Kong Enterprise image and set -`.enterprise.enabled: true` in values.yaml to render Enterprise sections of the -templates. Review the sections below for other settings you should consider -configuring before installing the chart. +- set `enterprise.enabled` to `true` in `values.yaml` file +- Update values.yaml to use a Kong Enterprise image +- Satisfy the two prerequsisites below for Enterprise License and + Enterprise Docker Registry -#### Service location hints +Once you have these set, it is possible to install Kong Enterprise, +but please make sure to review the below sections for other settings that +you should consider configuring before installing Kong. -Kong Enterprise add two GUIs, Kong Manager and the Kong Developer Portal, that -must know where other Kong services (namely the admin and files APIs) can be -accessed in order to function properly. Kong's default behavior for attempting -to locate these absent configuration is unlikely to work in common Kubernetes -environments. Because of this, you should set each of `admin_gui_url`, -`admin_api_uri`, `proxy_url`, `portal_api_url`, `portal_gui_host`, and -`portal_gui_protocol` under the `.env` key in values.yaml to locations where -each of their respective services can be accessed to ensure that Kong services -can locate one another and properly set CORS headers. See the [Property Reference documentation](https://docs.konghq.com/enterprise/0.35-x/property-reference/) -for more details on these settings. +Some of the more important configuration is grouped in sections +under the `.enterprise` key in values.yaml, though most enterprise-specific +configuration can be placed under the `.env` key. -#### License +### Prerequisites + +#### Kong Enterprise License All Kong Enterprise deployments require a license. If you do not have a copy of yours, please contact Kong Support. Once you have it, you will need to store it in a Secret. Save your secret in a file named `license` (no extension) and then create and inspect your secret: -``` +```bash $ kubectl create secret generic kong-enterprise-license --from-file=./license -$ kubectl get secret kong-enterprise-license -o yaml -apiVersion: v1 -data: - license: eyJsaWNlbnNlIjp7InNpZ25hdHVyZSI6IkhFWSBJIFNFRSBZT1UgUEVFS0lORyBJTlNJREUgTVkgQkFTRTY0IEVYQU1QTEUiLCJwYXlsb2FkIjp7ImN1c3RvbWVyIjoiV0VMTCBUT08gQkFEIiwibGljZW5zZV9jcmVhdGlvbl9kYXRlIjoiMjAxOC0wNi0wNSIsInByb2R1Y3Rfc3Vic2NyaXB0aW9uIjoiVEhFUkVTIE5PVEhJTkcgSEVSRSIsImFkbWluX3NlYXRzIjoiNSIsInN1cHBvcnRfcGxhbiI6IkZha2UiLCJsaWNlbnNlX2V4cGlyYXRpb25fZGF0ZSI6IjIwMjAtMjAtMjAiLCJsaWNlbnNlX2tleSI6IlRTT0kgWkhJViJ9LCJ2ZXJzaW9uIjoxfX0K -kind: Secret -metadata: - creationTimestamp: "2019-05-17T21:45:16Z" - name: kong-enterprise-license - namespace: default - resourceVersion: "48695485" - selfLink: /api/v1/namespaces/default/secrets/kong-enterprise-license - uid: 0f2e8903-78ed-11e9-b1a6-42010a8a02ec -type: Opaque ``` -Set the secret name in values.yaml, in the `.enterprise.license_secret` key. -#### RBAC +Set the secret name in `values.yaml`, in the `.enterprise.license_secret` key. +Please ensure the above secret is created in the same namespace in which +Kong is going to be deployed. -Note that you can create a default RBAC superuser when initially setting up an -environment, by setting the `KONG_PASSWORD` environment variable on the initial -migration Job's Pod. This will create a `kong_admin` admin whose token and -basic-auth password match the value of `KONG_PASSWORD` +#### Kong Enterprise Docker registry access + +Next, we need to setup Docker credentials in order to allow Kubernetes +nodes to pull down Kong Enterprise Docker image, which is hosted as a private +repository. -Using RBAC within Kubernetes environments requires providing Kubernetes an RBAC -user for its readiness and liveness checks. We recommend creating a user that -has permission to read `/status` and nothing else. For example, with RBAC still -disabled: +As part of your sign up for Kong Enterprise, you should have received +credentials for these as well. +```bash +$ kubectl create secret docker-registry kong-enterprise-docker \ + --docker-server=kong-docker-kong-enterprise-k8s.bintray.io \ + --docker-username= \ + --docker-password= +secret/kong-enterprise-docker created ``` -$ curl -sX POST http://admin.kong.example/rbac/users --data name=statuschecker --data user_token=REPLACE_WITH_SOME_TOKEN -{"user_token_ident":"45239","user_token":"$2b$09$cL.xbvRQCzE35A0osl8VTej7u0BgJOIgpTVjxpwZ1U8.jNdMwyQRW","id":"fe8824dc-09a7-4b68-b5e6-541e4b9b4ced","name":"statuschecker","enabled":true,"comment":null,"created_at":1558131229} -$ curl -sX POST http://admin.kong.example/rbac/roles --data name=read-status -{"comment":null,"created_at":1558131353,"id":"e32507a5-e636-40b2-88c0-090042db7d79","name":"read-status","is_default":false} +Set the secret name in `values.yaml` in the `image.pullSecrets` section. +Again, Please ensure the above secret is created in the same namespace in which +Kong is going to be deployed. -$ curl -sX POST http://admin.kong.example/rbac/roles/read-status/endpoints --data endpoint="/status" --data actions=read -{"endpoint":"\/status","created_at":1558131423,"workspace":"default","actions":["read"],"negative":false,"role":{"id":"e32507a5-e636-40b2-88c0-090042db7d79"}} +### Service location hints -$ curl -sX POST http://admin.kong.example/rbac/users/statuschecker/roles --data roles=read-status -{"roles":[{"created_at":1558131353,"id":"e32507a5-e636-40b2-88c0-090042db7d79","name":"read-status"}],"user":{"user_token_ident":"45239","user_token":"$2b$09$cL.xbvRQCzE35A0osl8VTej7u0BgJOIgpTVjxpwZ1U8.jNdMwyQRW","id":"fe8824dc-09a7-4b68-b5e6-541e4b9b4ced","name":"statuschecker","comment":null,"enabled":true,"created_at":1558131229}} -``` -Probes will then need to include that user's token, e.g. for the readinessProbe: +Kong Enterprise add two GUIs, Kong Manager and the Kong Developer Portal, that +must know where other Kong services (namely the admin and files APIs) can be +accessed in order to function properly. Kong's default behavior for attempting +to locate these absent configuration is unlikely to work in common Kubernetes +environments. Because of this, you should set each of `admin_gui_url`, +`admin_api_uri`, `proxy_url`, `portal_api_url`, `portal_gui_host`, and +`portal_gui_protocol` under the `.env` key in values.yaml to locations where +each of their respective services can be accessed to ensure that Kong services +can locate one another and properly set CORS headers. See the +[Property Reference documentation](https://docs.konghq.com/enterprise/latest/property-reference/) +for more details on these settings. -``` -readinessProbe: - httpGet: - path: "/status" - port: admin - scheme: HTTP - httpHeaders: - - name: Kong-Admin-Token - value: REPLACE_WITH_SOME_TOKEN - ... -``` +### RBAC + +You can create a default RBAC superuser when initially setting up an +environment, by setting the `KONG_PASSWORD` environment variable on the initial +migration Job's Pod. This will create a `kong_admin` admin whose token and +basic-auth password match the value of `KONG_PASSWORD`. +You can create a secret holding the initial password value and then +mount the secret as an environment variable using the `env` section. Note that RBAC is **NOT** currently enabled on the admin API container for the controller Pod when the ingress controller is enabled. This admin API container @@ -293,10 +426,10 @@ need to be stored in plaintext. RBAC is still enforced on the admin API of the main deployment when using the ingress controller, as that admin API *is* accessible outside the Pod. -#### Sessions +### Sessions -Login sessions for Kong Manager and the Developer Portal make use of [the Kong -Sessions plugin](https://docs.konghq.com/enterprise/0.35-x/kong-manager/authentication/sessions/). +Login sessions for Kong Manager and the Developer Portal make use of +[the Kong Sessions plugin](https://docs.konghq.com/enterprise/latest/kong-manager/authentication/sessions). Their configuration must be stored in Secrets, as it contains an HMAC key. If using either RBAC or the Portal, create a Secret with `admin_gui_session_conf` and `portal_session_conf` keys. @@ -314,12 +447,13 @@ always be changed for both configurations. After creating your secret, set its name in values.yaml, in the `.enterprise.rbac.session_conf_secret` and -`.enterprise.rbac.session_conf_secret` keys. +`.enterprise.portal.session_conf_secret` keys. -#### Email/SMTP +### Email/SMTP -Email is used to send invitations for [Kong Admins](https://docs.konghq.com/enterprise/enterprise/0.35-x/kong-manager/networking/email/) -and [Developers](https://docs.konghq.com/enterprise/enterprise/0.35-x/developer-portal/configuration/smtp/). +Email is used to send invitations for +[Kong Admins](https://docs.konghq.com/enterprise/latest/kong-manager/networking/email) +and [Developers](https://docs.konghq.com/enterprise/latest/developer-portal/configuration/smtp). Email invitations rely on setting a number of SMTP settings at once. For convenience, these are grouped under the `.enterprise.smtp` key in values.yaml. @@ -332,66 +466,281 @@ If your SMTP server requires authentication, you should the `username` and `smtp_password_secret` must be a Secret containing an `smtp_password` key whose value is your SMTP password. -### DB-less Configuration +## Changelog +### 0.36.6 -When deploying Kong in DB-less mode (`env.database: "off"`) and without the Ingress -Controller (`ingressController.enabled: false`), Kong needs a config to run. In -this case, configuration can be provided using an exsiting ConfigMap -(`dblessConfig.configMap`) or pushed directly into the values file under -`dblessConfig.config`. See the example configuration in the default values.yaml -for more details. +This version has no code changes and Kong's chart is now deprecated in this +repository. Please use Kong's official +[chart repository](https://github.com/kong/charts). -### Kong Ingress Controller +### 0.36.5 -Kong Ingress Controller's primary purpose is to satisfy Ingress resources -created in your Kubernetes cluster. -It uses CRDs for more fine grained control over routing and -for Kong specific configuration. -To deploy the ingress controller together with -kong run the following command: +> PR https://github.com/helm/charts/pull/20099 -```bash -# without a database -helm install stable/kong --set ingressController.enabled=true \ - --set postgresql.enabled=false --set env.database=off -# with a database -helm install stable/kong --set ingressController.enabled=true -``` +#### Improvements -If you like to use a static IP: +- Allow `grpc` protocol for KongPlugins -```shell -helm install stable/kong --set ingressController.enabled=true --set proxy.loadBalancerIP=[Your IP goes there] --set proxy.type=LoadBalancer --name kong --namespace kong -``` +### 0.36.4 -**Note**: Kong Ingress controller doesn't support custom SSL certificates -on Admin port. We will be removing this limitation in the future. +> PR https://github.com/helm/charts/pull/20051 -Kong ingress controller relies on several Custom Resource Definition objects to -declare the the Kong configurations and synchronize the configuration with the -Kong admin API. Each of this new objects declared in Kubernetes have a -one-to-one relation with a Kong resource. -The custom resources are: +#### Fixed -- KongConsumer -- KongCredential -- KongPlugin -- KongIngress +- Issue: [`Ingress Controller errors when chart is redeployed with Admission + Webhook enabled`](https://github.com/helm/charts/issues/20050) -You can can learn about kong ingress custom resource definitions [here](https://github.com/Kong/kubernetes-ingress-controller/blob/master/docs/custom-resources.md). +### 0.36.3 +> PR https://github.com/helm/charts/pull/19992 -| Parameter | Description | Default | -| ---------------------------------- | ------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | -| enabled | Deploy the ingress controller, rbac and crd | false | -| replicaCount | Number of desired ingress controllers | 1 | -| image.repository | Docker image with the ingress controller | kong-docker-kubernetes-ingress-controller.bintray.io/kong-ingress-controller | -| image.tag | Version of the ingress controller | 0.2.0 | -| readinessProbe | Kong ingress controllers readiness probe | | -| livenessProbe | Kong ingress controllers liveness probe | | -| ingressClass | The ingress-class value for controller | nginx | -| podDisruptionBudget.enabled | Enable PodDisruptionBudget for ingress controller | `false` | -| podDisruptionBudget.maxUnavailable | Represents the minimum number of Pods that can be unavailable (integer or percentage) | `50%` | -| podDisruptionBudget.minAvailable | Represents the number of Pods that must be available (integer or percentage) | | +#### Fixed + +- Fix spacing in ServiceMonitor when label is specified in config + +### 0.36.2 + +> PR https://github.com/helm/charts/pull/19955 + +#### Fixed + +- Set `sideEffects` and `admissionReviewVersions` for Admission Webhook +- timeouts for liveness and readiness probes has been changed from `1s` to `5s` + +### 0.36.1 + +> PR https://github.com/helm/charts/pull/19946 + +#### Fixed + +- Added missing watch permission to custom resources + +### 0.36.0 + +> PR https://github.com/helm/charts/pull/19916 + +#### Upgrade Instructions + +- When upgrading from <0.35.0, in-place chart upgrades will fail. + It is necessary to delete the helm release with `helm del --purge $RELEASE` and redeploy from scratch. + Note that this will cause downtime for the kong proxy. + +#### Improvements + +- Fixed Deployment's label selector that prevented in-place chart upgrades. + +### 0.35.1 + +> PR https://github.com/helm/charts/pull/19914 + +#### Improvements + +- Update CRDs to Ingress Controller 0.7 +- Optimize readiness and liveness probes for more responsive health checks +- Fixed incorrect space in NOTES.txt + +### 0.35.0 + +> PR [#19856](https://github.com/helm/charts/pull/19856) + +#### Improvements + +- Labels on all resources have been updated to adhere to the Helm Chart + guideline here: + https://v2.helm.sh/docs/developing_charts/#syncing-your-chart-repository + +### 0.34.2 + +> PR [#19854](https://github.com/helm/charts/pull/19854) + +This release contains no user-visible changes + +#### Under the hood + + - Various tests have been consolidated to speed up CI. + +### 0.34.1 + +> PR [#19887](https://github.com/helm/charts/pull/19887) + +#### Fixed + +- Correct indentation for Job securityContexts. + +### 0.34.0 + +> PR [#19885](https://github.com/helm/charts/pull/19885) + +#### New features + +- Update default version of Ingress Controller to 0.7.0 + +### 0.33.1 + +> PR [#19852](https://github.com/helm/charts/pull/19852) + +#### Fixed + +- Correct an issue with white space handling within `final_env` helper. + +### 0.33.0 + +> PR [#19840](https://github.com/helm/charts/pull/19840) + +#### Dependencies + +- Postgres sub-chart has been bumped up to 8.1.2 + +#### Fixed + +- Removed podDisruption budge for Ingress Controller. Ingress Controller and + Kong run in the same pod so this was no longer applicable +- Migration job now receives the same environment variable and configuration + as that of the Kong pod. +- If Kong is configured to run with Postgres, the Kong pods now always wait + for Postgres to start. Previously this was done only when the sub-chart + Postgres was deployed. +- A hard-coded container name is used for kong: `proxy`. Previously this + was auto-generated by Helm. This deterministic naming allows for simpler + scripts and documentation. + +#### Under the hood + +Following changes have no end user visible effects: + +- All Custom Resource Definitions have been consolidated into a single + template file +- All RBAC resources have been consolidated into a single template file +- `wait-for-postgres` container has been refactored and de-duplicated + +### 0.32.1 + +#### Improvements + +- This is a doc only release. No code changes have been done. +- Post installation steps have been simplified and now point to a getting + started page +- Misc updates to README: + - Document missing variables + - Remove outdated variables + - Revamp and rewrite major portions of the README + - Added a table of content to make the content navigable + +### 0.32.0 + +#### Improvements + +- Create and mount emptyDir volumes for `/tmp` and `/kong_prefix` to allow + for read-only root filesystem securityContexts and PodSecurityPolicys. +- Use read-only mounts for custom plugin volumes. +- Update stock PodSecurityPolicy to allow emptyDir access. +- Override the standard `/usr/local/kong` prefix to the mounted emptyDir + at `/kong_prefix` in `.Values.env`. +- Add securityContext injection points to template. By default, + it sets Kong pods to run with UID 1000. + +#### Fixes + +- Correct behavior for the Vitals toggle. + Vitals defaults to on in all current Kong Enterprise releases, and + the existing template only created the Vitals environment variable + if `.Values.enterprise.enabled == true`. Inverted template to create + it (and set it to "off") if that setting is instead disabled. +- Correct an issue where custom plugin configurations would block Kong + from starting. + +### 0.31.0 + +#### Breaking changes + +- Admin Service is disabled by default (`admin.enabled`) +- Default for `proxy.type` has been changed to `LoadBalancer` + +#### New features + +- Update default version of Kong to 1.4 +- Update default version of Ingress Controller to 0.6.2 +- Add support to disable kong-admin service via `admin.enabled` flag. + +### 0.31.2 + +#### Fixes + +- Do not remove white space between documents when rendering + `migrations-pre-upgrade.yaml` + +### 0.30.1 + +#### New Features + +- Add support for specifying Proxy service ClusterIP + +### 0.30.0 + +#### Breaking changes + +- `admin_gui_auth_conf_secret` is now required for Kong Manager + authentication methods other than `basic-auth`. + Users defining values for `admin_gui_auth_conf` should migrate them to + an externally-defined secret with a key of `admin_gui_auth_conf` and + reference the secret name in `admin_gui_auth_conf_secret`. + +### 0.29.0 + +#### New Features + +- Add support for specifying Ingress Controller environment variables. + +### 0.28.0 + +#### New Features + +- Added support for the Validating Admission Webhook with the Ingress Controller. + +### 0.27.2 + +#### Fixes + +- Do not create a ServiceAccount if it is not necessary. +- If a configuration change requires creating a ServiceAccount, + create a temporary ServiceAccount to allow pre-upgrade tasks to + complete before the regular ServiceAccount is created. + +### 0.27.1 + +#### Documentation updates +- Retroactive changelog update for 0.24 breaking changes. + +### 0.27.0 + +#### Breaking changes + +- DB-less mode is enabled by default. +- Kong is installed as an Ingress Controller for the cluster by default. + +### 0.25.0 + +#### New features + +- Add support for PodSecurityPolicy +- Require creation of a ServiceAccount + +### 0.24.0 + +#### Breaking changes + +- The configuration format for ingresses in values.yaml has changed. +Previously, all ingresses accepted an array of hostnames, and would create +ingress rules for each. Ingress configuration for services other than the proxy +now accepts a single hostname, which allows simpler TLS configuration and +automatic population of `admin_api_uri` and similar settings. Configuration for +the proxy ingress is unchanged, but its documentation now accurately reflects +the TLS configuration needed. + +## Seeking help +If you run into an issue, bug or have a question, please reach out to the Kong +community via [Kong Nation](https://discuss.konghq.com). +Please do not open issues in [this](https://github.com/helm/charts) repository +as the maintainers will not be notified and won't respond.