GitLab Cloud Native Chart 7.0
Along with the 16.0 release of GitLab, we have bumped the chart version to 7.0.
Summary of major changes
- The recommended PostgreSQL database is upgraded to 14.8.
- The bundled certmanager chart is upgraded from 1.5.4 to 1.11.1.
Upgrade path from 6.x
In order to upgrade to the 7.0 version of the chart, you first need to upgrade to the latest 6.11.x
release of the chart. Check the version mapping details for the latest patch.
GitLab now defaults to using two database connections. Prior to upgrading, you can check that PostgreSQL max_connections is
high enough (using more than 50% of the available max connections).
You can verify this by running the following Rake task using the Toolbox container:
gitlab-rake gitlab:db:decomposition:connection_status
If the task indicates that max_connections is high enough, then you can
proceed with the upgrade. If not, or you wish to remain on single
connection, you can set the ci.enabled key to false prior to the upgrade.
Upgrade from 6.11.x
Please follow the upgrade steps for 7.0 release.
Major Changes
PostgreSQL
As part of the 7.0.0 release of this chart, we upgraded the default PostgreSQL version from 12.7 to 14.8. This
is done by upgrading PostgreSQL chart version from
8.9.4 to 12.5.2.
This is not a drop in replacement. Manual steps need to be performed to upgrade the database. The steps have been documented in the upgrade steps.
Bundled certmanager
The bundled certmanager chart is upgraded from 1.5.4 to 1.11.1. Depending on your cluster and tooling this may require manual interaction before upgrading.
Make sure your cluster version is supported by certmanager 1.11. The release supports Kubernetes 1.21 to 1.26 and OpenShift 4.8 to 4.13. See certmanager supported releases for more information.
The default certmanager configuration now uses the acme.cert-manager.io/http01-edit-in-place annotation.
As a result, certmanager will use the existing Ingresses to complete ACME challenges instead of creating
new ones. This change ensures compatibility with Ingress controllers that need the ingressClassName to be set.
OpenShift users may have to modify the Security Context Constraints to deploy certmanager 1.10+. See certmanager 1.10 release notes for more information.
In case you deploy any certmanager custom resources not managed by the GitLab chart, or use additional scripts or tooling related to cert-manager, please read through the potentially breaking changes of certmanager 1.6 to 1.11 before upgrading.
Disable in-place Ingress modification
Sometimes the logic of reusing existing Ingresses for validation is not suitable. For example, if you have IP allowlists or other restrictions on your Ingresses that makes them inaccessible to the public Internet.
To perform the ACME challenge validation with an Ingress created dynamically each time, from 7.7.0 you can
set the global.issuer.useNewIngressForCerts value to true (defaults to false).
Setting useNewIngressForCerts to true requires the ingressClassName field to be supported by the
Ingress controller. This field has been available from Kubernetes 1.18, but is not supported on all controllers,
for example it is not yet available when using
GKE Ingress.
In case you need to enable this field during an upgrade on an existing cluster running GitLab charts 7.0-7.6,
please follow the upgrade instructions
Redis
The included bitnami/Redis
sub-chart has been updated to version 16.13.2 from the previously installed
11.3.4. This also upgrades Redis from 6.0.9 to 6.2.7.
Manual steps are required prior to upgrading if using the bundled Redis. See Upgrade the bundled Redis sub-chart