Releases: hetznercloud/hcloud-cloud-controller-manager
v1.27.0
Attach Load Balancer to a Subnet
If your CCM is configured for a Private Network, Load Balancers can now join one of its subnets. To place a Load Balancer in a specific subnet, use the new load-balancer.hetzner.cloud/private-subnet-ip-range annotation. Learn more about this feature here.
Watch-Based Route Reconciliation (Experimental)
Currently, route reconciliation is performed at a fixed interval of 30s. This leads to unnecessary API requests, as a GET /v1/networks/{id} call is triggered every 30s, even when no changes have occurred.
Upstream we have proposed an event-driven approach, similar to the mechanism used by other controllers such as the Load Balancer Controller. With this new approach, route reconciliation is triggered on node additions, node deletions, or when the PodCIDRs or Addresses of nodes change. Additionally, to ensure consistency, reconciliation will still occur periodically at a randomized interval between 12 and 24 hours.
We are close to merging a Kubernetes Enhancement Proposal (KEP). Furthermore, a pull request containing the implementation is already open in the Kubernetes repository.
Forked Upstream Libraries
In this release, we replaced the upstream controller-manager and cloud-provider libraries with our own forks. These forks are based on the upstream v0.34.1 release (aligned with Kubernetes v1.34.1) and include our patches on top.
Enabling the Feature
This feature is disabled by default and will not affect existing deployments unless explicitly enabled. We recommend testing it in a non-production environment before considering use in production.
As the KEP has not yet been reviewed for production readiness, the feature gate name may change in an upcoming release. Since this feature is marked as experimental, such changes will not be considered breaking.
To enable the feature, set the following Helm value:
args.feature-gates=CloudControllerManagerWatchBasedRoutesReconciliation=true
Features
- watch-based route reconciliation (#970)
- set dns config via helm chart values (#1027)
- support Kubernetes v1.34 and drop v1.30 (#1037)
- load-balancer: attach load balancer to specific subnetwork (#1031)
Bug Fixes
- feature gate cannot be enabled (#980)
v1.27.0-alpha.1
This release introduces an experimental feature to address #395.
Watch-Based Route Reconciliation (Experimental)
Currently, route reconciliation is performed at a fixed interval of 30s. This leads to unnecessary API requests, as a GET /v1/networks/{id} call is triggered every 30s, even when no changes have occurred.
Upstream we have proposed an event-driven approach, similar to the mechanism used by other controllers such as the Load Balancer Controller. With this new approach, route reconciliation is triggered on node additions, node deletions, or when the PodCIDRs or Addresses of nodes change. Additionally, to ensure consistency, reconciliation will still occur periodically at a randomized interval between 12 and 24 hours.
We are close to merging a Kubernetes Enhancement Proposal (KEP). Furthermore, a work-in-progress pull request containing the implementation is already open in the Kubernetes repository.
Forked Upstream Libraries
In this release, we replaced the upstream controller-manager and cloud-provider libraries with our own forks. These forks are based on the upstream v0.33.2 release (aligned with Kubernetes v1.33.2) and include our patches on top.
Enabling the Feature
This feature is disabled by default and will not impact existing deployments unless explicitly enabled. We do not recommend running this feature in production environments at this stage. However, we welcome early testers who can try it in non-critical setups. Running with this feature active is enough for us to analyze its impact. No additional feedback is required.
To enable the feature, set the following Helm value:
args.feature-gates=CloudControllerManagerWatchBasedRoutesReconciliation=true
Bug Fixes
- feature gate cannot be enabled (#980)
v1.27.0-alpha.0
🛑 Broken release
🛑 This release is broken due to an issue in the release config. Please use v1.27.0-alpha.1.
This release introduces an experimental feature to address #395.
Watch-Based Route Reconciliation (Experimental)
Currently, route reconciliation is performed at a fixed interval of 30 seconds. This leads to unnecessary API requests, as a GET /v1/networks/{id} call is triggered every 30 seconds, even when no changes have occurred.
Upstream we have proposed an event-driven approach, similar to the mechanism used by other controllers such as the Load Balancer Controller. With this new approach, route reconciliation is triggered on node additions, node deletions, or when the PodCIDRs or Addresses of nodes change. Additionally, to ensure consistency, reconciliation will still occur periodically at a randomized interval between 12 and 24 hours.
We are close to merging a Kubernetes Enhancement Proposal (KEP). Furthermore, a work-in-progress pull request containing the implementation is already open in the Kubernetes repository.
Forked Upstream Libraries
In this release, we replaced the upstream controller-manager and cloud-provider libraries with our own forks. These forks are based on the upstream v0.33.2 release (aligned with Kubernetes v1.33.2) and include our patches on top.
Enabling the Feature
This feature is disabled by default and will not impact existing deployments unless explicitly enabled. We do not recommend running this feature in production environments at this stage. However, we welcome early testers who can try it in non-critical setups. Running with this feature active is enough for us to analyze its impact. No additional feedback is required.
To enable the feature, set the following Helm value:
args.feature-gates=CloudControllerManagerWatchBasedRoutesReconciliation=true
Features
- watch-based route reconciliation (#970)
v1.26.0
v1.25.1-rc.0
Bug Fixes
- binaries are missing in the release (#930)
v1.25.1
v1.25.0
v1.24.0
Improved Robot Support in hcloud-cloud-controller-manager
The hcloud-cloud-controller-manager now forwards InternalIPs by default on Robot nodes when the --node-ip flag is used. If the provided IP is not already registered as an ExternalIP and matches the expected address family, it will be forwarded automatically during initialization.
This allows the use of vSwitch IPs in private networks and Load Balancers.
🔗 Learn more in our updated Robot documentation
📘 Follow our how-to-guide to set up Load Balancers with vSwitch IPs.
Features
- robot: forward InternalIPs by default on Robot nodes (#865)
- load-balancer: enable use-private-ip annotation for Robot servers (#898)
Bug Fixes
- load-balancer: don't print entire node object when adding robot target (#904)
v1.23.0
v1.22.0
This release includes an extension of our current metrics to also include the internals of k8s.io/cloud-provider with respect to the work queue depth and requests to the Kubernetes API.
Besides having all data available, this will also help us with debugging #661.