Hi,
As shared in our roadmap , we have been preparing all the necessary updates to migrate your cluster to the 1.23 version.
We wanted to give you more visibility on the plan we had in mind to migrate all the clusters, including ours 
Planning
-
Week 23/01/2023:
– migrate the Qovery production clusters. No downtime is expected by this operation.
– make the 1.23 the default version for any new cluster -
Week 30/01/2023:
– Migrate any cluster flagged as non-production in the qovery console (making sure to exclude any clusters havingdev,staging,testin their names).
But if you have production clusters, make sure those are properly 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?”). You can run your tests on your non-production cluster or create a new one (it will be automatically on the 1.23 version).
-
Week 13/02/2023:
– Migrate all the other clusters. We suppose that you are ok with this upgrade. If there is any specific reason we should delay the upgrade of your cluster, please fill this form
We will keep updating this post and our status page with all the information about the upgrades.
For any questions, please comment directly within this thread!
Benjamin
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 in the 1.23, migrating the pods on the new node and shutting down the 1.22 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 advanced settings ) so that the newly created instances of your service will receive traffic only when ready
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 make sure that they are compatible with Kubernetes 1.23. You can test them by either creating a new cluster in the 1.23 version (when it will be the default one) or testing it on your non-production cluster when it will be upgraded.
