From a45ed86e79e830ad161d3972465d42406cf08147 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 11:56:07 -0600 Subject: [PATCH 01/11] docs: add upgrade Kubernetes version how-to page --- docs/docs/how-tos/upgrade-kubernetes.mdx | 112 +++++++++++++++++++++++ 1 file changed, 112 insertions(+) create mode 100644 docs/docs/how-tos/upgrade-kubernetes.mdx diff --git a/docs/docs/how-tos/upgrade-kubernetes.mdx b/docs/docs/how-tos/upgrade-kubernetes.mdx new file mode 100644 index 00000000..6e990474 --- /dev/null +++ b/docs/docs/how-tos/upgrade-kubernetes.mdx @@ -0,0 +1,112 @@ +--- +title: Upgrade Kubernetes version +slug: /how-tos/upgrade-kubernetes +description: How to upgrade the Kubernetes version of an NKP cluster one minor version at a time, for both AWS EKS and Hetzner k3s. +--- + +:::note +This page covers NKP clusters managed by `nic`. Classic clusters are not covered here. +::: + +NKP supports in-place Kubernetes version upgrades via `nic deploy`. Edit the `kubernetes_version` field in your config and re-run deploy — `nic` handles the rest. + +## Before you upgrade + +### Version compatibility + +**AWS (EKS):** EKS requires incremental upgrades — you can move only one minor version at a time. To go from 1.32 to 1.34, you must upgrade twice: + +``` +1.32 → 1.33 → 1.34 +``` + +Skipping a version (for example, 1.32 → 1.34 directly) will fail validation. Downgrades are not supported. + +**Hetzner (k3s):** k3s upgrades also go one minor version at a time. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. + +### Operator and pack compatibility + +The Nebari Operator and Software Packs run inside the cluster and follow its Kubernetes version. There is no separate compatibility matrix to check before upgrading. + +## Upgrade steps + +These steps are the same for all providers. + +1. Edit `kubernetes_version` in your config — bump by one minor version: + + ```yaml + # AWS + cluster: + aws: + kubernetes_version: "1.34" # was "1.33" + + # Hetzner + cluster: + hetzner: + kubernetes_version: "1.33" # was "1.32" + ``` + +2. Validate the config: + + ```bash + nic validate -f + ``` + +3. Preview what will change: + + ```bash + nic deploy -f --dry-run + ``` + +4. Apply the upgrade: + + ```bash + nic deploy -f + ``` + +## What happens during the upgrade + +### AWS (EKS) + +EKS upgrades in two phases: + +1. **Control plane** upgrades first. The Kubernetes API server and control-plane components are updated to the new version. This takes around 10 minutes and is handled by AWS. +2. **Node groups** roll one at a time. For each managed node group, EKS cordons, drains, and replaces nodes with the new AMI — one node at a time. Node groups upgrade sequentially after the control plane finishes. + +Plan for a total time of 20–40 minutes depending on the number of node groups and their sizes. + +### Hetzner (k3s) + +`hetzner-k3s` handles the rolling upgrade. It upgrades the control plane node first, then each worker node in turn. + +## Operator and pack considerations + +During node rolling, pods on the node being replaced are evicted and rescheduled elsewhere: + +- The **Nebari Operator** may be briefly unavailable while the node it runs on is replaced. +- **Software Packs**, ArgoCD, Keycloak, and other foundational apps may be briefly unavailable during the rollout of the node they run on. +- **ArgoCD continues reconciling** throughout — any app that falls out of sync during the rollout is restored automatically once the replacement node is ready. + +Multi-replica workloads tolerate rolling node replacement without downtime, provided their replicas are spread across nodes. Single-replica packs will have a brief interruption while their pod is rescheduled. + +## Verify the upgrade + +After deploy completes, check that all nodes are running the new version: + +```bash +kubectl get nodes -o wide +``` + +All nodes should show the target version in the `VERSION` column. Then verify ArgoCD apps are healthy: + +```bash +kubectl get applications -n argocd +``` + +All applications should reach `Healthy`. Any that are briefly `Progressing` after the upgrade will self-correct within a few minutes. + +## See also + +- [NKP architecture](/docs/explanations/nkp-architecture) — conceptual overview of how the platform layers fit together +- [Deploy lifecycle](/docs/how-tos/deploy) — full deploy, update, and destroy reference +- [Update a cluster](/docs/how-tos/update-cluster) — other config changes you can make to a running cluster From b2009e36ae06e4b75703f67e0d148db6d6ce1b15 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 12:02:09 -0600 Subject: [PATCH 02/11] docs: add upgrade-kubernetes to sidebar --- docs/sidebars.js | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/sidebars.js b/docs/sidebars.js index 6be21d5b..74c403a8 100644 --- a/docs/sidebars.js +++ b/docs/sidebars.js @@ -47,6 +47,7 @@ module.exports = { "how-tos/deploy-cluster", "how-tos/cloudflare-dns", "how-tos/update-cluster", + "how-tos/upgrade-kubernetes", "how-tos/destroy-cluster", "how-tos/keycloak-auth", { From ca7f4f59f4cf24c1a46adb8ed0afd2880105900a Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 12:09:20 -0600 Subject: [PATCH 03/11] docs: link AWS provider page to upgrade-kubernetes how-to --- docs/docs/how-tos/providers/aws.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/docs/how-tos/providers/aws.mdx b/docs/docs/how-tos/providers/aws.mdx index 65430d68..8d07d5f5 100644 --- a/docs/docs/how-tos/providers/aws.mdx +++ b/docs/docs/how-tos/providers/aws.mdx @@ -181,6 +181,10 @@ To change something about a running cluster (scale a node group, add a `gpu` gro Changing `region`, `project_name`, or `vpc_cidr_block` triggers destructive resource recreation. Treat these as one-way decisions. ::: +:::note[Upgrading the Kubernetes version] +To upgrade the EKS Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). EKS requires one-minor-version increments — you cannot skip versions. +::: + ## Destroy Run the destroy commands as described in [Destroy a cluster](/docs/how-tos/destroy-cluster). From c9996bbc18ea8e6d4136102150dcc181c8cb8c8f Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 12:13:51 -0600 Subject: [PATCH 04/11] docs: link Hetzner provider page to upgrade-kubernetes how-to --- docs/docs/how-tos/providers/hetzner.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index c256b225..7b6468b9 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -148,6 +148,10 @@ To change something about a running cluster (scale a node group, add a `gpu` gro Changing `location` or `project_name` triggers destructive resource recreation. Treat these as one-way decisions. ::: +:::note[Upgrading the Kubernetes version] +To upgrade the k3s Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). Bump `kubernetes_version` by one minor version at a time. +::: + ## Destroy Run the destroy commands as described in [Destroy](/docs/how-tos/deploy#destroy) in the deploy lifecycle guide. From 31256d6400d4748ac94a5ba870255884d9442930 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 14:56:16 -0600 Subject: [PATCH 05/11] docs: fix reviewer findings on upgrade-kubernetes how-to MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - C1: Fix ArgoCD contradiction — replace "continues reconciling throughout" with "Once ArgoCD's replacement pod is ready, any apps that fell out of sync are restored" - C2: Replace "will fail validation" with "will be rejected by EKS during deploy" - I1: Add kubernetes version upgrade note to update-cluster.mdx Apply a change section - I2: Strengthen Hetzner note from guidance language to hard constraint with "cannot skip versions" - I3: Correct EKS node group upgrade sequence from cordon-drain-replace to surge-then-drain - M1: Add AWS-scoped note about verifying EKS managed add-ons after upgrade - M2: Add upgrade-kubernetes cross-reference to deploy.mdx Update an existing deployment section --- docs/docs/how-tos/deploy.mdx | 2 ++ docs/docs/how-tos/providers/hetzner.mdx | 2 +- docs/docs/how-tos/update-cluster.mdx | 4 ++++ docs/docs/how-tos/upgrade-kubernetes.mdx | 8 ++++---- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/docs/docs/how-tos/deploy.mdx b/docs/docs/how-tos/deploy.mdx index c9db8502..39dd5477 100644 --- a/docs/docs/how-tos/deploy.mdx +++ b/docs/docs/how-tos/deploy.mdx @@ -41,6 +41,8 @@ After deploy completes, your cluster needs DNS records to be reachable: see [Clo To change a running cluster, edit your config and re-run `nic deploy`: see [Update a cluster](/docs/how-tos/update-cluster). +To upgrade the cluster's Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) — version bumps have additional constraints beyond a normal config change. + ## Destroy When you're done with the cluster, tear it down with `nic destroy`: see [Destroy a cluster](/docs/how-tos/destroy-cluster). diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index 7b6468b9..03782639 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -149,7 +149,7 @@ Changing `location` or `project_name` triggers destructive resource recreation. ::: :::note[Upgrading the Kubernetes version] -To upgrade the k3s Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). Bump `kubernetes_version` by one minor version at a time. +To upgrade the k3s Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). Hetzner k3s requires one-minor-version increments — you cannot skip versions. ::: ## Destroy diff --git a/docs/docs/how-tos/update-cluster.mdx b/docs/docs/how-tos/update-cluster.mdx index f185fe02..4bdf7d6b 100644 --- a/docs/docs/how-tos/update-cluster.mdx +++ b/docs/docs/how-tos/update-cluster.mdx @@ -15,6 +15,10 @@ nic deploy -f --dry-run # show what would change; nothing is mo nic deploy -f # apply it ``` +:::note[Upgrading the Kubernetes version] +Bumping `kubernetes_version` has additional requirements. See [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) — EKS and k3s both require one-minor-version increments. +::: + ## Immutable fields Some fields (cluster identity, network foundation) can't be changed on a running cluster. Changing one requires destroying and recreating it. The exact fields are provider-specific: see your [provider's page](/docs/how-tos/providers). diff --git a/docs/docs/how-tos/upgrade-kubernetes.mdx b/docs/docs/how-tos/upgrade-kubernetes.mdx index 6e990474..5aac77ed 100644 --- a/docs/docs/how-tos/upgrade-kubernetes.mdx +++ b/docs/docs/how-tos/upgrade-kubernetes.mdx @@ -20,13 +20,13 @@ NKP supports in-place Kubernetes version upgrades via `nic deploy`. Edit the `ku 1.32 → 1.33 → 1.34 ``` -Skipping a version (for example, 1.32 → 1.34 directly) will fail validation. Downgrades are not supported. +Skipping a version (for example, 1.32 → 1.34 directly) will be rejected by EKS during deploy. Downgrades are not supported. **Hetzner (k3s):** k3s upgrades also go one minor version at a time. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. ### Operator and pack compatibility -The Nebari Operator and Software Packs run inside the cluster and follow its Kubernetes version. There is no separate compatibility matrix to check before upgrading. +The Nebari Operator and Software Packs run inside the cluster and follow its Kubernetes version. There is no separate compatibility matrix to check before upgrading. **AWS:** After upgrading, verify your EKS managed add-ons (kube-proxy, CoreDNS, VPC CNI) are on versions compatible with the new cluster version — check the **Add-ons** tab in the AWS EKS console and update any that are flagged. ## Upgrade steps @@ -71,7 +71,7 @@ These steps are the same for all providers. EKS upgrades in two phases: 1. **Control plane** upgrades first. The Kubernetes API server and control-plane components are updated to the new version. This takes around 10 minutes and is handled by AWS. -2. **Node groups** roll one at a time. For each managed node group, EKS cordons, drains, and replaces nodes with the new AMI — one node at a time. Node groups upgrade sequentially after the control plane finishes. +2. **Node groups** roll one at a time. For each managed node group, EKS launches a replacement node, waits for it to become Ready, then drains and terminates the old one — one node at a time per node group. Node groups upgrade sequentially after the control plane finishes. Plan for a total time of 20–40 minutes depending on the number of node groups and their sizes. @@ -85,7 +85,7 @@ During node rolling, pods on the node being replaced are evicted and rescheduled - The **Nebari Operator** may be briefly unavailable while the node it runs on is replaced. - **Software Packs**, ArgoCD, Keycloak, and other foundational apps may be briefly unavailable during the rollout of the node they run on. -- **ArgoCD continues reconciling** throughout — any app that falls out of sync during the rollout is restored automatically once the replacement node is ready. +- Once **ArgoCD's replacement pod is ready**, any apps that fell out of sync during the rollout are restored automatically. Multi-replica workloads tolerate rolling node replacement without downtime, provided their replicas are spread across nodes. Single-replica packs will have a brief interruption while their pod is rescheduled. From 0fe63c324e8fe90b94b0aa8de0c1b7db53889b82 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 16:03:51 -0600 Subject: [PATCH 06/11] docs: strip provider-specific content from upgrade-kubernetes how-to --- docs/docs/how-tos/upgrade-kubernetes.mdx | 49 +++--------------------- 1 file changed, 6 insertions(+), 43 deletions(-) diff --git a/docs/docs/how-tos/upgrade-kubernetes.mdx b/docs/docs/how-tos/upgrade-kubernetes.mdx index 5aac77ed..0ee572ab 100644 --- a/docs/docs/how-tos/upgrade-kubernetes.mdx +++ b/docs/docs/how-tos/upgrade-kubernetes.mdx @@ -1,7 +1,7 @@ --- title: Upgrade Kubernetes version slug: /how-tos/upgrade-kubernetes -description: How to upgrade the Kubernetes version of an NKP cluster one minor version at a time, for both AWS EKS and Hetzner k3s. +description: How to upgrade the Kubernetes version of an NKP cluster — common steps that work across all providers. --- :::note @@ -12,39 +12,15 @@ NKP supports in-place Kubernetes version upgrades via `nic deploy`. Edit the `ku ## Before you upgrade -### Version compatibility +Version constraints and accepted formats vary by provider — see your [provider's page](/docs/how-tos/providers) before upgrading. -**AWS (EKS):** EKS requires incremental upgrades — you can move only one minor version at a time. To go from 1.32 to 1.34, you must upgrade twice: - -``` -1.32 → 1.33 → 1.34 -``` - -Skipping a version (for example, 1.32 → 1.34 directly) will be rejected by EKS during deploy. Downgrades are not supported. - -**Hetzner (k3s):** k3s upgrades also go one minor version at a time. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. - -### Operator and pack compatibility - -The Nebari Operator and Software Packs run inside the cluster and follow its Kubernetes version. There is no separate compatibility matrix to check before upgrading. **AWS:** After upgrading, verify your EKS managed add-ons (kube-proxy, CoreDNS, VPC CNI) are on versions compatible with the new cluster version — check the **Add-ons** tab in the AWS EKS console and update any that are flagged. +The Nebari Operator and Software Packs run inside the cluster and follow its Kubernetes version. There is no separate compatibility matrix to check before upgrading. ## Upgrade steps These steps are the same for all providers. -1. Edit `kubernetes_version` in your config — bump by one minor version: - - ```yaml - # AWS - cluster: - aws: - kubernetes_version: "1.34" # was "1.33" - - # Hetzner - cluster: - hetzner: - kubernetes_version: "1.33" # was "1.32" - ``` +1. Edit `kubernetes_version` in your config — bump by one minor version. See your [provider's page](/docs/how-tos/providers) for the exact field path and accepted version formats. 2. Validate the config: @@ -64,21 +40,6 @@ These steps are the same for all providers. nic deploy -f ``` -## What happens during the upgrade - -### AWS (EKS) - -EKS upgrades in two phases: - -1. **Control plane** upgrades first. The Kubernetes API server and control-plane components are updated to the new version. This takes around 10 minutes and is handled by AWS. -2. **Node groups** roll one at a time. For each managed node group, EKS launches a replacement node, waits for it to become Ready, then drains and terminates the old one — one node at a time per node group. Node groups upgrade sequentially after the control plane finishes. - -Plan for a total time of 20–40 minutes depending on the number of node groups and their sizes. - -### Hetzner (k3s) - -`hetzner-k3s` handles the rolling upgrade. It upgrades the control plane node first, then each worker node in turn. - ## Operator and pack considerations During node rolling, pods on the node being replaced are evicted and rescheduled elsewhere: @@ -110,3 +71,5 @@ All applications should reach `Healthy`. Any that are briefly `Progressing` afte - [NKP architecture](/docs/explanations/nkp-architecture) — conceptual overview of how the platform layers fit together - [Deploy lifecycle](/docs/how-tos/deploy) — full deploy, update, and destroy reference - [Update a cluster](/docs/how-tos/update-cluster) — other config changes you can make to a running cluster +- [AWS provider](/docs/how-tos/providers/aws) — EKS-specific upgrade constraints and mechanics +- [Hetzner provider](/docs/how-tos/providers/hetzner) — k3s-specific upgrade constraints and mechanics From 585b99460e2d56f398a3e58d5a3d1f6894db121e Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 16:05:58 -0600 Subject: [PATCH 07/11] docs: expand AWS upgrade section with full EKS mechanics --- docs/docs/how-tos/providers/aws.mdx | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/docs/how-tos/providers/aws.mdx b/docs/docs/how-tos/providers/aws.mdx index 8d07d5f5..e43f1683 100644 --- a/docs/docs/how-tos/providers/aws.mdx +++ b/docs/docs/how-tos/providers/aws.mdx @@ -181,9 +181,24 @@ To change something about a running cluster (scale a node group, add a `gpu` gro Changing `region`, `project_name`, or `vpc_cidr_block` triggers destructive resource recreation. Treat these as one-way decisions. ::: -:::note[Upgrading the Kubernetes version] -To upgrade the EKS Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). EKS requires one-minor-version increments — you cannot skip versions. -::: +## Upgrade Kubernetes version + +EKS requires one-minor-version increments — you cannot skip versions or downgrade. To go from 1.32 to 1.34 you must upgrade twice: + +``` +1.32 → 1.33 → 1.34 +``` + +Skipping a version (for example, 1.32 → 1.34 directly) is rejected by EKS during deploy. + +EKS upgrades in two phases: + +1. **Control plane** upgrades first. The Kubernetes API server and control-plane components are updated to the new version. This takes around 10 minutes and is handled by AWS. +2. **Node groups** roll one at a time. EKS launches a replacement node, waits for it to become Ready, then drains and terminates the old one — one node at a time per node group. Node groups upgrade sequentially after the control plane finishes. Plan for 20–40 minutes total depending on the number of node groups. + +After upgrading, verify your EKS managed add-ons (kube-proxy, CoreDNS, VPC CNI) are on versions compatible with the new cluster version — check the **Add-ons** tab in the AWS EKS console and update any that are flagged. + +See [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) for the upgrade commands and post-upgrade verification steps. ## Destroy From df4567b96274c3a1b07cd0657d4773e33f3fd363 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 16:14:08 -0600 Subject: [PATCH 08/11] docs: expand Hetzner upgrade section with full k3s mechanics --- docs/docs/how-tos/providers/hetzner.mdx | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index 03782639..aab72467 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -148,9 +148,13 @@ To change something about a running cluster (scale a node group, add a `gpu` gro Changing `location` or `project_name` triggers destructive resource recreation. Treat these as one-way decisions. ::: -:::note[Upgrading the Kubernetes version] -To upgrade the k3s Kubernetes version, see [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes). Hetzner k3s requires one-minor-version increments — you cannot skip versions. -::: +## Upgrade Kubernetes version + +Hetzner k3s requires one-minor-version increments — you cannot skip versions. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. + +`hetzner-k3s` handles the rolling upgrade: it upgrades the control plane node first, then each worker node in turn. + +See [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) for the upgrade commands and post-upgrade verification steps. ## Destroy From 0cb5de2e826e820273894e00ec7affa912ab2119 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Tue, 23 Jun 2026 16:21:20 -0600 Subject: [PATCH 09/11] =?UTF-8?q?docs:=20fix=20review=20findings=20?= =?UTF-8?q?=E2=80=94=20add=20field=20path,=20downgrade=20note,=20trailing?= =?UTF-8?q?=20newline?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - AWS: add kubernetes_version field path and example under cluster.aws - Hetzner: clarify that downgrades are also not supported - AWS: add trailing newline to file --- docs/docs/how-tos/providers/aws.mdx | 12 +++++++++++- docs/docs/how-tos/providers/hetzner.mdx | 2 +- 2 files changed, 12 insertions(+), 2 deletions(-) diff --git a/docs/docs/how-tos/providers/aws.mdx b/docs/docs/how-tos/providers/aws.mdx index e43f1683..009e6c0a 100644 --- a/docs/docs/how-tos/providers/aws.mdx +++ b/docs/docs/how-tos/providers/aws.mdx @@ -191,6 +191,16 @@ EKS requires one-minor-version increments — you cannot skip versions or downgr Skipping a version (for example, 1.32 → 1.34 directly) is rejected by EKS during deploy. +Set `kubernetes_version` under `cluster.aws` in your config: + +```yaml +cluster: + aws: + kubernetes_version: "1.33" # was "1.32" +``` + +EKS accepts bare minor versions (`"1.33"`) — patch versions are not required. + EKS upgrades in two phases: 1. **Control plane** upgrades first. The Kubernetes API server and control-plane components are updated to the new version. This takes around 10 minutes and is handled by AWS. @@ -206,4 +216,4 @@ Run the destroy commands as described in [Destroy a cluster](/docs/how-tos/destr `nic destroy` removes EKS, node groups, EFS, VPC components, and the state bucket. If a resource fails to delete (commonly, a leftover load balancer from the cluster's ingress), remove it manually in the AWS console before retrying with `--force`. -Always confirm in the AWS console that no orphan resources remain. NAT gateways, load balancers, and EBS volumes can keep billing if they're not cleaned up. \ No newline at end of file +Always confirm in the AWS console that no orphan resources remain. NAT gateways, load balancers, and EBS volumes can keep billing if they're not cleaned up. diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index aab72467..5a9fb7a2 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -150,7 +150,7 @@ Changing `location` or `project_name` triggers destructive resource recreation. ## Upgrade Kubernetes version -Hetzner k3s requires one-minor-version increments — you cannot skip versions. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. +Hetzner k3s requires one-minor-version increments — you cannot skip versions or downgrade. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. `hetzner-k3s` handles the rolling upgrade: it upgrades the control plane node first, then each worker node in turn. From e1fd688a3ada240825b9682775517d5a92a531a8 Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Wed, 24 Jun 2026 10:22:58 -0600 Subject: [PATCH 10/11] improve language --- docs/docs/how-tos/providers/hetzner.mdx | 2 +- docs/docs/how-tos/update-cluster.mdx | 2 +- docs/docs/how-tos/upgrade-kubernetes.mdx | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index 5a9fb7a2..983fcb67 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -150,7 +150,7 @@ Changing `location` or `project_name` triggers destructive resource recreation. ## Upgrade Kubernetes version -Hetzner k3s requires one-minor-version increments — you cannot skip versions or downgrade. The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. +The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. Downgrades are not supported. `hetzner-k3s` handles the rolling upgrade: it upgrades the control plane node first, then each worker node in turn. diff --git a/docs/docs/how-tos/update-cluster.mdx b/docs/docs/how-tos/update-cluster.mdx index 4bdf7d6b..610c8a05 100644 --- a/docs/docs/how-tos/update-cluster.mdx +++ b/docs/docs/how-tos/update-cluster.mdx @@ -16,7 +16,7 @@ nic deploy -f # apply it ``` :::note[Upgrading the Kubernetes version] -Bumping `kubernetes_version` has additional requirements. See [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) — EKS and k3s both require one-minor-version increments. +Bumping `kubernetes_version` has additional requirements. See [Upgrade Kubernetes version](/docs/how-tos/upgrade-kubernetes) ::: ## Immutable fields diff --git a/docs/docs/how-tos/upgrade-kubernetes.mdx b/docs/docs/how-tos/upgrade-kubernetes.mdx index 0ee572ab..2fb8669c 100644 --- a/docs/docs/how-tos/upgrade-kubernetes.mdx +++ b/docs/docs/how-tos/upgrade-kubernetes.mdx @@ -20,7 +20,7 @@ The Nebari Operator and Software Packs run inside the cluster and follow its Kub These steps are the same for all providers. -1. Edit `kubernetes_version` in your config — bump by one minor version. See your [provider's page](/docs/how-tos/providers) for the exact field path and accepted version formats. +1. Edit `kubernetes_version` in your config. See your [provider's page](/docs/how-tos/providers) for provider specific requirements. 2. Validate the config: From 9baf7f4e9561ef4d01de7f7f76d7c34b3e796aae Mon Sep 17 00:00:00 2001 From: andrewfulton9 Date: Wed, 24 Jun 2026 10:35:57 -0600 Subject: [PATCH 11/11] remove fake news --- docs/docs/how-tos/providers/hetzner.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/docs/how-tos/providers/hetzner.mdx b/docs/docs/how-tos/providers/hetzner.mdx index 983fcb67..6f7a3dbb 100644 --- a/docs/docs/how-tos/providers/hetzner.mdx +++ b/docs/docs/how-tos/providers/hetzner.mdx @@ -150,7 +150,7 @@ Changing `location` or `project_name` triggers destructive resource recreation. ## Upgrade Kubernetes version -The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. Downgrades are not supported. +The `kubernetes_version` field accepts `"1.32"`, `"1.32.0"`, or a full release tag like `"v1.32.12+k3s1"`. Specifying `"1.32"` resolves to the latest stable k3s patch release for that minor version. `hetzner-k3s` handles the rolling upgrade: it upgrades the control plane node first, then each worker node in turn.