Skip to content

docs: note default Kubernetes version for new clusters #362

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mintlify wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs: note default Kubernetes version for new clusters #362

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions cloud-accounts/cluster-upgrades.mdx
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -32,6 +32,16 @@ More documentation around zero-downtime deployments may be found [here](/applica

3. Maintaining a constant stream of communication around upgrade timelines and statuses.

## Default Kubernetes version

New clusters provisioned through Porter are created with **Kubernetes v1.35** by default. This applies to all supported cloud providers (AWS EKS, Google Cloud GKE, and Azure AKS).

You can select a different Kubernetes version when creating a cluster from the Porter dashboard. Supported versions range from v1.27 to v1.35.

<Info>
We recommend keeping the default version unless you have a specific compatibility requirement. Existing clusters are upgraded to newer versions on the schedule described below — you do not need to recreate a cluster to move forward.
</Info>

## Upgrade Calendar

Kubernetes follows a release cycle where there are - approximately - three minor version releases a year. Every release is followed by a period where public clouds integrate the new version into their managed Kubernetes offerings and run tests to ensure compatibility with the underlying cloud. Our upgrade calendar is thus dependent on both release cycles. To account for that, we carry out cluster upgrades twice a year, where we "leapfrog" over versions to ensure customer clusters are running the _latest stable_ version of Kubernetes. These are typically carried out once towards the end of Q1/beginning of Q2 and then later towards the end of Q3.
Expand Down