hcloud-k8s/terraform-hcloud-kubernetes 5.0.0 on GitHub

⚠️ Upgrade Notes

This release requires manual action for #443, which fixes #163.

Special thanks to @mlinares1998 for making the necessary changes in the Hetzner Cloud Terraform provider! See: hetznercloud/terraform-provider-hcloud#1278

Seamless migration

Before upgrading, explicitly set the existing subnet CIDRs using the new subnet option for all worker_nodepools entries.

Example command to retrieve the required configuration from the terraform.tfstate file:

jq -r '
  .resources[]
  | select(.module == "module.kubernetes" and .type == "hcloud_network_subnet" and .name == "worker")
  | .instances[]
  | "\(.index_key): subnet = \"\(.attributes.ip_range)\""
' terraform.tfstate

After the correct subnet option has been set for all worker_nodepools entries, the upgrade to v5 can be performed.

Optional migration to the new dynamic IP address assignment

Finish the seamless migration.
Remove the subnet option from worker_nodepools.
Manually detach the worker nodes from their respective subnets in the Hetzner Console.
Apply the Terraform/OpenTofu changes.

⚠️ Info: Steps 2–4 can also be performed per worker node pool. This procedure is not seamless, and some deployment restarts may be required. Less disruptive migration approaches are possible as well, such as creating new worker node pools without the subnet option and removing the old ones afterwards. This would create fresh nodes using the newly updated pricing.

Important information when using IPsec encryption

When cilium_encryption_type = "ipsec" is used, the Cilium Pods will lose network connectivity after the upgrade to Cilium 1.19 and stop functioning. To restore connectivity, manually reboot every cluster node.

If you plan to switch to the default wireguard encryption instead, be aware that Cilium does not support this migration scenario. A manual reboot of every node is also required for the migration to succeed. See: cilium/cilium#44691

During the upgrade, errors like the following can occur and stop the upgrade procedure:

│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.kubernetes.talos_machine_configuration_apply.control_plane["<NODE>"] to include new values learned so far during apply, provider "<PROVIDER>" produced an invalid new value for .machine_configuration_hash: was
│ cty.StringVal("<OLD_HASH>"), but now cty.StringVal("<NEW_HASH>").
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.
╵
╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for module.kubernetes.talos_machine_configuration_apply.control_plane["<NODE>"] to include new values learned so far during apply, provider "<PROVIDER>" produced an invalid new value for .machine_configuration: inconsistent values for sensitive attribute.
│ 
│ This is a bug in the provider, which should be reported in the provider's own issue tracker.

This is caused by a bug in the Talos Terraform provider and should be resolved by running apply a second time. This may occur more frequently until the provider’s bug fix (siderolabs/terraform-provider-talos#359) is released, especially during Talos upgrades.

See: siderolabs/terraform-provider-talos#352

What's Changed

chore(deps): update terraform hcloud to v1.65.0 by @renovate[bot] in #416
feat(network): add shared subnets for worker and autoscaler by @M4t7e in #443
chore(deps): update dependency siderolabs/talos to v1.13.4 by @renovate[bot] in #410
chore(deps): update helm release cluster-autoscaler to v9.53.0 by @renovate[bot] in #434
chore(deps): update dependency kubernetes/autoscaler to v1.34.3 by @renovate[bot] in #435
chore(deps): update dependency kubernetes/kubernetes to v1.34.9 by @renovate[bot] in #436
chore(deps): update helm release cilium to v1.19.5 by @renovate[bot] in #444
feat(talos): harden Secret redaction during Kubernetes upgrade by @M4t7e in #448

Full Changelog: 4.8.0...5.0.0