Hi !
We are working on migrating Qovery managed Kubernetes clusters from version 1.28 to 1.29.
We have polished our integration to comply to 1.29 making sure everything works properly and migration / upgrade will be smooth.
Production vs non-production clusters
Migration process won’t change much from what has been done in the past, but since we have mainly two new kids on the block (aka GKE and EKS with Karpenter support) we will eventually split a bit more the rollout in order to be able to properly monitor everything.
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 give you the opportunity 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
For this upgrade, we’ve worked on a feature allowing you to trigger the cluster upgrade when you want. If a kubernetes version is available for a cluster, you will be able to trigger it.
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
- 10/11/2024: newly created clusters are running 1.29 by default
- 10/14/2024: users can trigger cluster upgrade
- 10/16/2024: migrate all NON-PRODUCTION clusters to 1.29
- 10/28/2024: migrate all PRODUCTION clusters to 1.29
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 manage the upgrades by automatically creating new nodes with the new version, migrating the pods on 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 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 will be upgraded.
What about next kubernetes versions (1.30 & 1.31)?
We will send communication once 1.29 migration will be done. We plan to proceed with those upgrades right after, planning can still move, but we target the following ETA:
- 1.30 to be fully rolled out on 11/28/2024
- 1.31 to be fully rolled out on 12/17/2024
I have a self managed cluster, what should I do
The latest qovery charts are already compatible with the kubernetes version 1.29.
Make sure to:
- Deploy the latest version of the charts via the qovery cluster install command
- Upgrade your cluster to the version 1.29
For any questions, please comment directly within this thread!
Alessandro