Hi !
We are working on migrating Qovery managed Kubernetes clusters from version 1.29 to 1.30.
We have polished our integration to comply to 1.30 making sure everything works properly and migration/upgrade will be smooth.
We will automatically upgrade your clusters based on the planning below (see “Planning” section). If the planning doesn’t fit your needs, you will be able to manually trigger the upgrade (see “User triggered upgrade” section).
Production vs non-production clusters
We will upgrade first every non-production cluster to give you the chance to verify that everything works fine for your environments before upgrading your production cluster. Make sure those are appropriately tagged as such.
This will allow you to verify that everything works as expected on your services with the new Kubernetes version (see the section below “Does the upgrade have any impact on my services?”).
User triggered upgrade
If you want to trigger by yourself the upgrade, use the option “Upgrade to K8s 1.30” available in your cluster menu section (when the new kubernetes version is available).
if you don’t do it, we will do it automatically, see planning below.
Communication
We will keep updating this post and our status page with all the information about the upgrades.
Planning
- 11/04/2024: newly created clusters are running 1.30 by default
- 11/06/2024: users can trigger cluster upgrade
- 11/12/2024: migrate all NON-PRODUCTION clusters to 1.30
- 11/25/2024: migrate all PRODUCTION clusters to 1.30
If you have any issue with this timeline, please contact us.
FAQ
Why do we need to upgrade your cluster
Each cloud provider has a limited number of supported Kubernetes versions and Qovery manages for you the upgrades!
More info on the supported Kubernetes versions by cloud provider:
Does the upgrade have any impact on my services?
- Services deployed via Qovery
Kubernetes manages the upgrades by automatically creating new nodes with the new version, migrating the pods to the new node and shutting down the old nodes. The upgrade might cause a very small downtime for your applications, if you want to avoid the downtime you should:
- set at least 2 instances for your applications (within the application settings ) so that at least 1 instance will be available to receive traffic.
- set the correct liveness/readiness probes (using the health checks section) so that the newly created instances of your service will receive traffic only when ready
- Please redeploy your services if it has not been redeployed since the
registry.image_retention_timecluster advanced setting . Otherwise your services won’t be able to start once the migration is done, as the image won’t be available.
Please note that, even outside this migration period, we strongly advise you to apply the points above to ensure no service disruption during the deployment of your applications.
- Services deployed by yourself (via a helm chart)
For any service you have installed by yourself, please ensure they are compatible with Kubernetes new versions. You can test them by either creating a new cluster in the new version (when it will be the default one) or testing it on your non-production cluster when it is upgraded.
What about next kubernetes version (1.31)?
Update 18th of December: the migration to the 1.31 is postponed to the beginning of Q1. It will be probably rolled out mid January, we will communicate as soon as we have more visibility
I have a self-managed cluster, what should I do
The latest qovery charts are already compatible with the kubernetes version 1.30.
Make sure to:
- Deploy the latest version of the charts via the qovery cluster install command
- Upgrade your cluster to version 1.30
For any questions, please comment directly within this thread!
Alessandro