feat: release v0.9.0 (#66)

* charts(kong): update to kong-2.4.0

generator command: 'kong-2.4.0'

generator command version: 2b9dc2a

* release(v0.9.0) update operator metadata and docs

Release 0.9.0 and change the kongs CRD API group from charts.helm.k8s.io
to charts.konghq.com.

The new group is not in one of the protected groups established by
kubernetes/enhancements#1111. This operator CRD
should not use a protected group as it is not a core part of the
Kubernetes project.

This change makes the CRD compatible with Kubernetes >=1.22. However, it
breaks compatibility with previous versions of the operator. As such,
0.9.0 has no replace version: it requires a fresh operator install and a
fresh set of Kong CRs.

* test: update microk8s to 1.22

* test: update kubectl to 1.22.2

* test: update Ingress API version

* feat: support Ingress v1

* test: remove Ingress waits

Remove the Ingress status waits and add retry configuration to curl when
validating the Ingress configuration.

KIC 2.0+ handles status updates for non-LoadBalancer Services
differently than earlier versions. Previously, KIC would set a status
with a 0-length list of ingresses if the proxy Service was not type
Loadbalancer, e.g.

status:
  loadBalancer:
    ingress:
    - {}

As of KIC 2.0, no status is set if the Service is not type LoadBalancer,
e.g.

status:
  loadBalancer: {}

This change to the operator tests confirms that Ingress configuration
was successfully applied to the proxy using requests through the proxy
only. These now run immediately after the upstream Deployment becomes
available, however, so they may run before the controller has ingested
Ingress configuration or observed Endpoint updates. To account for this,
the curl checks are now wrapped in wait_for to allow a reasonable amount
of time for the controller to update configuration.

* fix: update ingress example in README.md to v1

* feat: update OLM maintainer info

Co-authored-by: Shane Utt <shaneutt@linux.com>
Co-authored-by: Michał Flendrich <michal@flendrich.pro>

.github/workflows/test.yaml

@@ -50,15 +50,15 @@ jobs:
 
     - name: 'Arrange: Set up microk8s'
       run: |
-        sudo snap install microk8s --channel 1.18/stable --classic
+        sudo snap install microk8s --channel 1.22/stable --classic
         for addon in dns rbac registry
         do
           sudo microk8s enable $addon
         done
         mkdir -p ~/.kube
         sudo chown $USER -R ~/.kube
         sudo microk8s.config > ~/.kube/config
-        sudo curl -L https://storage.googleapis.com/kubernetes-release/release/v1.18.4/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl
+        sudo curl -L https://storage.googleapis.com/kubernetes-release/release/v1.22.2/bin/linux/amd64/kubectl -o /usr/local/bin/kubectl
         kubectl wait --for=condition=Available deploy -n container-registry registry --timeout=120s
 
     - uses: actions/download-artifact@v2
@@ -101,21 +101,20 @@ jobs:
         kubectl wait --for=condition=Available deploy kong2-kong --timeout=120s
 
         kubectl wait --for=condition=Available deploy echo --timeout=120s
-        wait_for 'kubectl get ingress demo1 -o jsonpath={.status.loadBalancer.ingress}' ".+" 120
-        wait_for 'kubectl get ingress demo2 -o jsonpath={.status.loadBalancer.ingress}' ".+" 120
 
     - name: 'Assert: Validate Ingress'
       run: |
         set -x
+        . test/integration/helpers.sh
 
         PROXY1_IP=$(kubectl get service kong1-kong-proxy -o jsonpath={.spec.clusterIP})
         PROXY2_IP=$(kubectl get service kong2-kong-proxy -o jsonpath={.spec.clusterIP})
 
-        [ "$(curl -sw '%{http_code}' -o /dev/null http://$PROXY1_IP/via-kong1/)" == 200 ]
-        [ "$(curl -sw '%{http_code}' -o /dev/null http://$PROXY2_IP/via-kong2/)" == 200 ]
+        wait_for "curl -sw '%{http_code}' -o /dev/null http://$PROXY1_IP/via-kong1/" "200" 120
+        wait_for "curl -sw '%{http_code}' -o /dev/null http://$PROXY2_IP/via-kong2/" "200" 120
 
-        [ "$(curl -sw '%{http_code}' -o /dev/null http://$PROXY1_IP/via-kong2/)" == 404 ]
-        [ "$(curl -sw '%{http_code}' -o /dev/null http://$PROXY2_IP/via-kong1/)" == 404 ]
+        wait_for "curl -sw '%{http_code}' -o /dev/null http://$PROXY1_IP/via-kong2/" "404" 30
+        wait_for "curl -sw '%{http_code}' -o /dev/null http://$PROXY2_IP/via-kong1/" "404" 30
 
     - name: 'Print debugging information'
       if: ${{ always() }}

CHANGELOG.md

@@ -1,5 +1,79 @@
 # Changelog
 
+## 0.9.0
+
+### Breaking changes
+
+* 0.9.0 changes the API group used for the Kong CRD to `charts.konghq.com`.
+  This is necessary to comply with new requirements for `*.k8s.io` groups
+  enforced by Kubernetes 1.22 and newer. Because of this change, you **cannot
+  upgrade to 0.9.0 from previous releases of the operator, and must manually
+  copy configuration from your existing kongs.charts.helm.k8s.io CRs into new
+  kongs.charts.konghq.com CRs.** See the "Upgrading from previous versions"
+  section below for detailed instructions.
+* Chart 2.4 updates the default version of KIC to 2.0. If you do not override
+  your KIC version to an older 1.x version and you use a database, you should
+  [temporarily disable KIC before upgrading it to 2.0](https://github.com/Kong/charts/blob/kong-2.4.0/charts/kong/UPGRADE.md#disable-ingress-controller-prior-to-2x-upgrade-when-using-postgresql)
+  to avoid database inconsistency.
+* ServiceAccount configuration has a [new location inside Kong custom
+  resources](https://github.com/Kong/charts/blob/kong-2.4.0/charts/kong/UPGRADE.md#changed-serviceaccount-configuration-location)
+  to support configurations that require a ServiceAccount but do not use the
+  ingress controller.
+* Various resources [now use updated API versions](https://github.com/Kong/charts/blob/kong-2.4.0/charts/kong/UPGRADE.md#changed-serviceaccount-configuration-location)
+  for compatibility with newer Kubernetes releases. These versions require
+  Kubernetes 1.16 or newer. Note that the upgraded Ingress resources now use
+  the `ingressClassName` field: you should remove `ingress.class` annotations
+  and set their value in `ingressClassName` to account for [changes to the
+  Ingress spec](https://docs.konghq.com/kubernetes-ingress-controller/2.0.x/concepts/ingress-versions/).
+* The [Pod disruption budget default has changed](https://github.com/Kong/charts/blob/kong-2.4.0/charts/kong/UPGRADE.md#changes-to-pod-disruption-budget-defaults)
+  to allow support for the `minUnavailable` setting. You may wish to restore
+  the older default if you are upgrading from a previous version.
+
+### Upgrading from previous versions
+
+0.9.0 changes the CRD API group used by this operator. The new
+`kongs.charts.konghq.com` CRD and old `kongs.charts.helm.k8s.io` CRD have
+identical specs, but you must manually copy data into new CRs to migrate your
+configuration. We recommend backing up your cluster prior to migrating.
+
+Because the old CRD is not compatible with Kubernetes 1.22, you must complete
+these steps on Kubernetes 1.21 or older. To migrate your configuration:
+
+1. Install the new CRD:
+   ```
+   kubectl create -f https://raw.githubusercontent.com/Kong/kong-operator/v0.9.0/deploy/crds/charts_v1alpha1_kong_crd.yaml
+   ```
+2. Using [jq](https://stedolan.github.io/jq/), create new CRs from your
+   existing CRs:
+   ```
+   kubectl get kongs.charts.helm.k8s.io --all-namespaces -o json | jq ".items[] | del(.metadata.uid, .metadata.creationTimestamp, .metadata.generation, .metadata.resourceVersion) | .apiVersion=\"charts.konghq.com/v1alpha1\"" | kubectl create -f -
+   ```
+3. Plan an outage window where you will upgrade to Kubernetes 1.22 and install
+   the new operator. Because you will uninstall previous versions of the
+   operator, there will be a period when your Kong instances will not be
+   available.
+4. Begin your outage window. Delete existing Kong instances and remove the
+   operator CRD:
+   ```
+   kubectl delete kongs --all-namespaces --all
+   ```
+   This will _stop all running Kong instances_.
+5. [Uninstall the Kong operator](https://olm.operatorframework.io/docs/tasks/uninstall-operator/)
+   and run `kubectl delete crds kongs.charts.helm.k8s.io` to remove the old
+   CRD.
+5. Install Kong operator 0.9.0 by creating a [new subscription](https://olm.operatorframework.io/docs/getting-started/#installing-an-operator-using-olm)
+   with `startingCSV: kong.v0.9.0`.
+6. Check the status of your Kong instances with `kubectl get deploy` in
+   namespaces you've installed Kong. 0.9.0 should detect the new CRs and start
+   Kong instances automatically.
+
+### Improvements
+
+* Upgraded to chart 2.4. See the [chart changelog](https://github.com/Kong/charts/blob/kong-2.4.0/charts/kong/CHANGELOG.md)
+  for full details.
+* Upgraded the Kong CRD API version to `apiextensions.k8s.io/v1` for
+  compatibility with Kubernetes 1.22 and newer.
+
 ## 0.8.0
 
 ### Breaking changes

README.md

@@ -25,7 +25,7 @@ With Kong Operator running in your cluster, you can spin up multiple instances o
 1. Deploy a Kong Ingress Controller with `example-ingress-class` Ingress class (see [_Configuration_ section][section-configuration] for available options):
     ```
     kubectl create -f - <<EOF
-    apiVersion: charts.helm.k8s.io/v1alpha1
+    apiVersion: charts.konghq.com/v1alpha1
     kind: Kong
     metadata:
       name: example-kong

build/Dockerfile

@@ -5,7 +5,7 @@ ADD LICENSE /licenses/LICENSE
 LABEL name="kong-operator" \
       maintainer="harry@konghq.com" \
       vendor="Kong Inc" \
-      version="v0.8.0" \
+      version="v0.9.0" \
       summary="kong-operator installs and manages Kong in your k8s environemnt" \
       description="kong-operator installs and manages Kong in your k8s environemnt"