Autoscaler nodes assigned to wrong subnet in shared networks

[sergeyv5577-hero]

Description

When a shared Hetzner network has multiple subnets, the Hetzner Cloud API assigns new servers to the last created subnet by default. The module passes only HCLOUD_NETWORK (network ID) to the autoscaler helm chart without specifying a subnet, so autoscaler nodes land in whatever subnet was created last — not the cluster's dedicated hcloud_network_subnet.autoscaler subnet.

With private-only cluster access, the autoscaler node can't communicate with the rest of the cluster.

The upstream cluster-autoscaler already supports subnetIPRange in nodeConfigs since helm chart 9.52.0 (kubernetes/autoscaler#8570), but the module doesn't pass it — autoscaler.tf only sets cloudInit, labels, and taints in nodeConfigs.

PR #226 addresses this but has been stale since Nov 2025. Its upstream dependency merged Oct 2025.

Expected Behavior

Autoscaler nodes should be assigned to the cluster's dedicated autoscaler subnet (hcloud_network_subnet.autoscaler).

Actual Behavior

Autoscaler nodes are assigned to whichever subnet was created last in the shared network. E.g. if a 10.111.0.0/24 subnet exists and was created after the cluster subnet, autoscaler nodes land there instead of the cluster's 10.3.64.0/19 range.

Minimal Module Configuration

module "kubernetes" {
  source  = "hcloud-k8s/kubernetes/hcloud"
  version = "3.21.3"

  hcloud_network_id          = data.terraform_remote_state.shared.outputs.network_id  # shared network with multiple subnets
  network_node_ipv4_cidr     = "10.3.64.0/19"

  cluster_autoscaler_nodepools = [
    {
      name     = "autoscaler"
      type     = "cpx41"
      location = "fsn1"
      max      = 5
    }
  ]
}

Relevant Output

$ talosctl get members
NODE                                    ADDRESSES
cluster-autoscaler-abc123   ["10.111.0.2","x.x.x.x"]   # wrong: landed in 10.111.0.0/24 (last created subnet)
cluster-control-1           ["10.3.64.1","x.x.x.x"]   # correct: cluster subnet
cluster-worker-1            ["10.3.65.1","x.x.x.x"]   # correct: cluster subnet

Confirmation

• I checked existing issues, discussions, and the web for similar problems

Related

• kubernetes/autoscaler#8570 — adds subnetIPRange support (merged Oct 2025)
• #226 — stale PR addressing this issue
• Hetzner autoscaler README — documents subnetIPRange / defaultSubnetIPRange
• Module default helm chart: 9.50.1 (predates feature); latest available: 9.55.0

[M4t7e]

Hey @sergeyv5577-hero, thanks for reporting this! This is a known limitation of CA, but we haven't had an issue open for it, so let's keep this for tracking.

@tloesch (the author of kubernetes/autoscaler#8570) created a discussion about this topic here: #194

The PR is included in CA 1.35, which officially requires Kubernetes 1.35 for compatibility. This will likely land in this module around Q3. @mlinares1998 suggested we can already implement the subnet allocation feature, since the setting is probably ignored in earlier versions. If someone urgently needs this, they can manually set the CA version to 1.35 and hope everything works. Cross-version combinations are often compatible, but I've seen cases in the past where they weren't.

In general, I'd like to solve #163 first. I'm currently considering adjusting the subnet planning to reserve some space for a future implementation of bare metal servers (see #277). This would probably impact the current CA subnet, which might need to be changed. To move forward with that issue, we first need hetznercloud/terraform-provider-hcloud#1278 to be merged and released. As soon as this is done, we can solve all other issues.

PR #226 addresses this but has been stale since Nov 2025. Its upstream dependency merged Oct 2025.

This PR might become obsolete after implementing the fix for #163. There will be a default subnet for all CA nodepools, and possibly an option to pass a subnet per node pool instead of generating subnets like we do for other node types.

[mlinares1998]

Hey @sergeyv5577-hero, thanks for reporting this! This is a known limitation of CA, but we haven't had an issue open for it, so let's keep this for tracking.

@tloesch (the author of kubernetes/autoscaler#8570) created a discussion about this topic here: #194

The PR is included in CA 1.35, which officially requires Kubernetes 1.35 for compatibility. This will likely land in this module around Q3. @mlinares1998 suggested we can already implement the subnet allocation feature, since the setting is probably ignored in earlier versions. If someone urgently needs this, they can manually set the CA version to 1.35 and hope everything works. Cross-version combinations are often compatible, but I've seen cases in the past where they weren't.

In general, I'd like to solve #163 first. I'm currently considering adjusting the subnet planning to reserve some space for a future implementation of bare metal servers (see #277). This would probably impact the current CA subnet, which might need to be changed. To move forward with that issue, we first need hetznercloud/terraform-provider-hcloud#1278 to be merged and released. As soon as this is done, we can solve all other issues.

PR #226 addresses this but has been stale since Nov 2025. Its upstream dependency merged Oct 2025.

This PR might become obsolete after implementing the fix for #163. There will be a default subnet for all CA nodepools, and possibly an option to pass a subnet per node pool instead of generating subnets like we do for other node types.

Should I close #226 for now? We can revisit it once hetznercloud/terraform-provider-hcloud#1278 is eventually merged, as that’s the real prerequisite to properly fixing #163.

BTW, I’ve pinged the Hetzner maintainer again since that PR has been stale since November 😞.
Do you have any ideas on how to make more "noise" effectively?

Regards!

[M4t7e]

Hey @mlinares1998 🙂

Should I close #226 for now? We can revisit it once hetznercloud/terraform-provider-hcloud#1278 is eventually merged, as that’s the real prerequisite to properly fixing #163.

Yes, I think we can close it for now.

BTW, I’ve pinged the Hetzner maintainer again since that PR has been stale since November 😞.
Do you have any ideas on how to make more "noise" effectively?

I think it's best to give the maintainer some time to review the PR again after your latest ping. Sometimes other priorities can come up that require more focus, so hopefully he'll return to this issue soon. If not, we can consider upgrading to the next major release and wait for v5 to resolve all the issues.

[sergeyv5577-hero]

Hey, thanks for replying.

Are there blockers to fix this?

I could make a PR if we agree on the solution path. How about this: we bump up the helm chart version for the autoscaler and pass subnetIPRange param to it under the hood without touching anything else. #163 fix will then land on top. Will this work?

[M4t7e]

@sergeyv5577-hero Thank you, but there is nothing we can do for now. As mentioned, we have dependencies here that should ideally be resolved first. But I’m thinking about an intermediate solution as well. See my comment: #163 (comment)