Merge pull request #300 from Kong/next

[kong] release 1.15.0

charts/kong/CHANGELOG.md

@@ -1,5 +1,49 @@
 # Changelog
 
+## 1.15.0
+
+1.15.0 is an interim release before the planned release of 2.0.0. There were
+several feature changes we wanted to release prior to the removal of deprecated
+functionality for 2.0. The original planned deprecations covered in the [1.14.0
+changelog](#1140) are still planned for 2.0.0.
+
+### Improvements
+
+* The default Kong version is now 2.3 and the default Kong Enterprise version
+  is now 2.3.2.0.
+* Added configurable `terminationGracePeriodSeconds` for the pre-stop lifecycle
+  hook.
+  ([#271](https://github.com/Kong/charts/pull/271)).
+* Initial migration database wait init containers no longer have a default
+  image configuration in values.yaml. When no image is specified, the chart
+  will use the Kong image. The standard Kong images include bash, and can run
+  the database wait script without downloading a separate image. Configuring a
+  wait image is now only necessary if you use a custom Kong image that lacks
+  bash.
+  ([#285](https://github.com/Kong/charts/pull/285)).
+* Init containers for database availability and migration completeness can now
+  be disabled. They cause compatibility issues with many service meshes.
+  ([#285](https://github.com/Kong/charts/pull/285)).
+* Removed the default migration Job annotation that disabled Kuma's mesh proxy.
+  The latest version of Kuma no longer prevents Jobs from completing.
+  ([#285](https://github.com/Kong/charts/pull/285)).
+* Services now support user-configurable labels, and the Prometheus
+  ServiceMonitor label is included on the proxy Service by default. Users that
+  disable the proxy Service and add this label to another Service to collect
+  metrics.
+  ([#290](https://github.com/Kong/charts/pull/290)).
+* Migration Jobs now allow resource quota configuration. Init containers
+  inherit their resource quotas from their associated Kong container.
+  ([#294](https://github.com/Kong/charts/pull/294)).
+
+### Fixed
+
+* The database readiness wait script ConfigMap and associated mounts are no
+  longer created if that feature is not in use.
+  ([#285](https://github.com/Kong/charts/pull/285)).
+* Removed a duplicated field from CRDs.
+  ([#281](https://github.com/Kong/charts/pull/281)).
+
 ## 1.14.5
 
 ### Fixed

charts/kong/Chart.yaml

@@ -10,5 +10,5 @@ maintainers:
   email: [email protected]
 name: kong
 sources:
-version: 1.14.5
-appVersion: 2.2
+version: 1.15.0
+appVersion: 2.3

charts/kong/FAQs.md

@@ -85,3 +85,25 @@ This occurs if a `RELEASE-NAME-kong-init-migrations` Job is left over from a
 previous `helm install` or `helm upgrade`. Deleting it with
 `kubectl delete job RELEASE-NAME-kong-init-migrations` will allow the upgrade
 to proceed. Chart versions greater than 1.5.0 delete the job automatically.
+
+#### DB-backed instances do not start when deployed within a service mesh
+
+Service meshes, such as Istio and Kuma, if deployed in a mode that injects
+a sidecar to Kong, don't make the mesh available to `InitContainer`s,
+because the sidecar starts _after_ all `InitContainer`s finish.
+
+By default, this chart uses init containers to ensure that the database is
+online and has migrations applied before starting Kong. This provides for a
+smoother startup, but isn't compatible with service mesh sidecar requirements
+if Kong is to access the database through the mesh.
+
+Setting `waitImage.enabled=false` in values.yaml disables these init containers
+and resolves this issue. However, during the initial install, your Kong
+Deployment will enter the CrashLoopBackOff state while waiting for migrations
+to complete. It will eventually exit this state and enter Running as long as
+there are no issues finishing migrations, usually within 2 minutes.
+
+If your Deployment is stuck in CrashLoopBackoff for longer, check the init
+migrations Job logs to see if it is unable to connect to the database or unable
+to complete migrations for some other reason. Resolve any issues you find,
+delete the release, and attempt to install again.

charts/kong/README.md

@@ -37,6 +37,7 @@ $ helm install kong/kong --generate-name --set ingressController.installCRDs=fal
   - [Standalone controller nodes](#standalone-controller-nodes)
   - [Hybrid mode](#hybrid-mode)
   - [CRDs only](#crds-only)
+  - [Sidecar containers](#sidecar-containers)
   - [Example configurations](#example-configurations)
 - [Configuration](#configuration)
   - [Kong Parameters](#kong-parameters)
@@ -52,6 +53,7 @@ $ helm install kong/kong --generate-name --set ingressController.installCRDs=fal
   - [RBAC](#rbac)
   - [Sessions](#sessions)
   - [Email/SMTP](#emailsmtp)
+- [Prometheus Operator integration](#prometheus-operator-integration)
 - [Changelog](https://github.com/Kong/charts/blob/main/charts/kong/CHANGELOG.md)
 - [Upgrading](https://github.com/Kong/charts/blob/main/charts/kong/UPGRADE.md)
 - [Seeking help](#seeking-help)
@@ -154,26 +156,13 @@ Following sections detail on various high-level architecture options available:
 
 ### Database
 
-Kong can run with or without a database (DB-less).
-By default, this chart installs Kong without a database.
+Kong can run with or without a database (DB-less). By default, this chart
+installs Kong without a database.
 
-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.
+You can set the database the `env.database` parameter. For more details, please
+read the [env](#the-env-section) section.
 
-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
+#### DB-less deployment
 
 When deploying Kong in DB-less mode(`env.database: "off"`)
 and without the Ingress Controller(`ingressController.enabled: false`),
@@ -184,6 +173,18 @@ The configuration can be provided using an existing ConfigMap
 parameter. See the example configuration in the default values.yaml
 for more details.
 
+#### Using the Postgres sub-chart
+
+The chart can optionally spawn a Postgres instance using [Bitnami's Postgres
+chart](https://github.com/bitnami/charts/blob/master/bitnami/postgresql/README.md)
+as a sub-chart. Set `postgresql.enabled=true` to enable the sub-chart. Enabling
+this will auto-populate Postgres connection settings in Kong's environment.
+
+The Postgres sub-chart is best used to quickly provision temporary environments
+without installing and configuring your database separately. For longer-lived
+environments, we recommend you manage your database outside the Kong Helm
+release.
+
 ### Runtime package
 
 There are three different packages of Kong that are available:
@@ -468,10 +469,11 @@ directory.
 | env                                | Additional [Kong configurations](https://getkong.org/docs/latest/configuration/)      |                     |
 | migrations.preUpgrade              | Run "kong migrations up" jobs                                                         | `true`              |
 | migrations.postUpgrade             | Run "kong migrations finish" jobs                                                     | `true`              |
-| migrations.annotations             | Annotations for migration job pods                                                    | `{"sidecar.istio.io/inject": "false", "kuma.io/sidecar-injection": "disabled"}` |
+| migrations.annotations             | Annotations for migration job pods                                                    | `{"sidecar.istio.io/inject": "false" |
 | migrations.jobAnnotations          | Additional annotations for migration jobs                                             | `{}`                |
-| waitImage.repository               | Image used to wait for database to become ready                                       | `bash`              |
-| waitImage.tag                      | Tag for image used to wait for database to become ready                               | `5`                 |
+| waitImage.enabled                  | Spawn init containers that wait for the database before starting Kong                 | `true`              |
+| waitImage.repository               | Image used to wait for database to become ready. Uses the Kong image if none set      |                     |
+| waitImage.tag                      | Tag for image used to wait for database to become ready                               |                     |
 | 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`.| `` |
@@ -535,6 +537,7 @@ nodes.
 | SVC.ingress.path                   | Ingress path.                                                                         | `/`                 |
 | SVC.ingress.annotations            | Ingress annotations. See documentation for your ingress controller for details        | `{}`                |
 | SVC.annotations                    | Service annotations                                                                   | `{}`                |
+| SVC.labels                         | Service labels                                                                        | `{}`                |
 
 #### Stream listens
 
@@ -591,6 +594,7 @@ For a complete list of all configuration values you can set in the
 | readinessProbe                     | Kong readiness probe                                                                  |                     |
 | livenessProbe                      | Kong liveness probe                                                                   |                     |
 | lifecycle                          | Proxy container lifecycle hooks                                                       | see `values.yaml`   |
+| terminationGracePeriodSeconds      | Related to lifecycle hook                                                             | 30                  |
 | affinity                           | Node/pod affinities                                                                   |                     |
 | nodeSelector                       | Node labels for pod assignment                                                        | `{}`                |
 | deploymentAnnotations              | Annotations to add to deployment                                                      |  see `values.yaml`  |
@@ -686,11 +690,10 @@ Kong is going to be deployed.
 
 #### Kong Enterprise Docker registry access
 
-Next, we need to setup Docker credentials in order to allow Kubernetes
-nodes to pull down Kong Enterprise Docker images, which are hosted in a private
-registry.
+Kong Enterprise versions 2.2 and earlier use a private Docker registry and
+require a pull secret. **If you use 2.3 or newer, you can skip this step.**
 
-You should received credentials to log into https://bintray.com/kong after
+You should have received credentials to log into https://bintray.com/kong after
 purchasing Kong Enterprise. After logging in, you can retrieve your API key
 from \<your username\> \> Edit Profile \> API Key. Use this to create registry
 secrets:
@@ -803,6 +806,30 @@ If your SMTP server requires authentication, you must provide the `username` and
 
 By default, SMTP uses `AUTH` `PLAIN` when you provide credentials. If your provider requires `AUTH LOGIN`, set `smtp_auth_type: login`.
 
+## Prometheus Operator integration
+
+The chart can configure a ServiceMonitor resource to instruct the [Prometheus
+Operator](https://github.com/prometheus-operator/prometheus-operator) to
+collect metrics from Kong Pods. To enable this, set
+`serviceMonitor.enabled=true` in `values.yaml`.
+
+Kong exposes memory usage and connection counts by default. You can enable
+traffic metrics for routes and services by configuring the [Prometheus
+plugin](https://docs.konghq.com/hub/kong-inc/prometheus/).
+
+The ServiceMonitor requires an `enable-metrics: "true"` label on one of the
+chart's Services to collect data. By default, this label is set on the proxy
+Service. It should only be set on a single chart Service to avoid duplicate
+data. If you disable the proxy Service (e.g. on a hybrid control plane instance
+or Portal-only instance) and still wish to collect memory usage metrics, add
+this label to another Service, e.g. on the admin API Service:
+
+```
+admin:
+  labels:
+    enable-metrics: "true"
+```
+
 ## Seeking help
 
 If you run into an issue, bug or have a question, please reach out to the Kong

charts/kong/ci/single-image-default.yaml

@@ -2,7 +2,7 @@
 # use single image strings instead of repository/tag
 
 image:
-  single: kong:2.0
+  unifiedRepoTag: kong:2.3
 proxy:
   type: NodePort
 
@@ -12,5 +12,5 @@ ingressController:
   env:
     anonymous_reports: "false"
   image:
-    single: kong-docker-kubernetes-ingress-controller.bintray.io/kong-ingress-controller:0.8.1
+    unifiedRepoTag: kong-docker-kubernetes-ingress-controller.bintray.io/kong-ingress-controller:1.1.1
   installCRDs: false

charts/kong/ci/test2-values.yaml

@@ -1,5 +1,6 @@
 # This tests the following unrelated aspects of Ingress Controller
 # - ingressController deploys with a database
+# - stream listens work
 ingressController:
   enabled: true
   installCRDs: false

charts/kong/ci/test5-values.yaml

@@ -0,0 +1,46 @@
+# This tests the following unrelated aspects of Ingress Controller
+# - ingressController deploys with a database
+# - TODO remove this test when https://github.com/Kong/charts/issues/295 is solved
+#   and its associated wait-for-db workaround is removed.
+#   This test is similar to test2-values.yaml, but lacks a stream listen.
+#   wait-for-db will _not_ create a socket file. This test ensures the workaround
+#   does not interfere with startup when there is no file to remove.
+
+ingressController:
+  enabled: true
+  installCRDs: false
+  env:
+    anonymous_reports: "false"
+postgresql:
+  enabled: true
+  postgresqlUsername: kong
+  postgresqlDatabase: kong
+  service:
+    port: 5432
+env:
+  anonymous_reports: "off"
+  database: "postgres"
+# - ingress resources are created without hosts
+admin:
+  type: NodePort
+  ingress:
+    enabled: true
+    hosts: []
+    path: /
+proxy:
+  type: NodePort
+  ingress:
+    enabled: true
+    hostname: proxy.kong.example
+    annotations: {}
+    path: /
+
+# - PDB is enabled
+podDisruptionBudget:
+  enabled: true
+# update strategy
+updateStrategy:
+  type: "RollingUpdate"
+  rollingUpdate:
+    maxSurge: 1
+    maxUnavailable: 0

charts/kong/crds/custom-resource-definitions.yaml

@@ -375,8 +375,6 @@ spec:
     type: date
     description: Age
     JSONPath: .metadata.creationTimestamp
-  subresources:
-    status: {}
   validation:
     openAPIV3Schema:
       properties:

charts/kong/example-values/full-k4k8s-with-kong-enterprise.yaml

@@ -11,11 +11,8 @@
 #   the Portal and Portal API.
 
 image:
-  repository: kong-docker-kong-enterprise-edition-docker.bintray.io/kong-enterprise-edition
-  tag: 2.2.1.0-alpine
-  pullSecrets:
-    # CHANGEME: https://github.com/Kong/charts/blob/main/charts/kong/README.md#kong-enterprise-docker-registry-access
-    - kong-enterprise-edition-docker
+  repository: kong-docker-kong-gateway-docker.bintray.io/kong-enterprise-edition
+  tag: "2.3.2.0-alpine"
 
 env:
   prefix: /kong_prefix/

charts/kong/example-values/minimal-k4k8s-with-kong-enterprise.yaml

@@ -8,11 +8,8 @@
 # kubectl port-forward deploy/your-deployment-kong 8001:8001 8002:8002
 
 image:
-  repository: kong-docker-kong-enterprise-edition-docker.bintray.io/kong-enterprise-edition
-  tag: 2.2.1.0-alpine
-  pullSecrets:
-    # CHANGEME: https://github.com/Kong/charts/blob/main/charts/kong/README.md#kong-enterprise-docker-registry-access
-    - kong-enterprise-edition-docker
+  repository: kong-docker-kong-gateway-docker.bintray.io/kong-enterprise-edition
+  tag: "2.3.2.0-alpine"
 
 admin:
   enabled: true
@@ -34,6 +31,12 @@ enterprise:
   smtp:
     enabled: false
 
+portal:
+  enabled: false
+
+portalapi:
+  enabled: false
+
 env:
   prefix: /kong_prefix/
   database: postgres

charts/kong/example-values/minimal-kong-controller.yaml

@@ -2,7 +2,7 @@
 
 image:
   repository: kong
-  tag: "2.2"
+  tag: "2.3"
 
 env:
   prefix: /kong_prefix/

charts/kong/example-values/minimal-kong-enterprise-dbless.yaml

@@ -1,15 +1,10 @@
-# WARNING: this deployment example is currently in beta. It is not suited for production.
 # Basic values.yaml for Kong for Kubernetes with Kong Enterprise (DB-less)
 # Several settings (search for the string "CHANGEME") require user-provided
 # Secrets. These Secrets must be created before installation.
 
 image:
-  repository: kong-docker-kong-enterprise-edition-docker.bintray.io/kong-enterprise-edition
-  tag: 2.2.1.0-alpine
-
-  pullSecrets:
-    # CHANGEME: https://github.com/Kong/charts/blob/master/charts/kong/README.md#kong-enterprise-docker-registry-access
-    - kong-enterprise-edition-docker
+  repository: kong-docker-kong-gateway-docker.bintray.io/kong-enterprise-edition
+  tag: "2.3.2.0-alpine"
 
 enterprise:
   enabled: true
@@ -22,6 +17,14 @@ enterprise:
   rbac:
     enabled: false
 
+manager:
+  enabled: false
+
+portal:
+  enabled: false
+
+portalapi:
+  enabled: false
 
 env:
   database: "off"

charts/kong/example-values/minimal-kong-hybrid-control.yaml

@@ -6,7 +6,7 @@
 
 image:
   repository: kong
-  tag: "2.2"
+  tag: "2.3"
 
 env:
   prefix: /kong_prefix/