Tags: hetznercloud/hcloud-cloud-controller-manager
Tags
chore(main): release v1.29.0 (#1111) ### Watch-Based Route Reconciliation Previously, 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 contributed an event-driven approach, similar to the mechanisms used by other controllers such as the Load Balancer controller. With this new approach, route reconciliation is triggered by node additions, node deletions, or changes to a node’s `PodCIDRs` or `Addresses`. Additionally, to ensure consistency, reconciliation still occurs periodically at a randomized interval between 12 and 24 hours. #### Enabled by default This feature is now **enabled by default**. If you encounter any problems you can disable the feature by setting the following Helm value: `args.feature-gates=CloudControllerManagerWatchBasedRoutesReconciliation=false` ### Global Load Balancer Defaults Configure cluster-wide defaults for Load Balancers via the extended `HCLOUD_LOAD_BALANCERS_*` env vars. These values automatically apply during Load Balancer creation and reconciliation whenever annotations are omitted. Learn more about it in the [reference documentation](docs/reference/load_balancer_envs.md) ### Features - extend environment variables for default load balancer configuration (#1052) - enable watch based route reconciliation by default (#1112)
chore(main): release v1.28.0 (#1061) ### Updated ClusterRole for HCCM We have introduced a custom `ClusterRole` for the HCCM component, based on the [upstream recommendation from sig-cloud-provider](https://kubernetes.io/docs/concepts/architecture/cloud-controller/#authorization-miscellaneous). To ensure a smooth transition, we renamed the `ClusterRoleBinding` by adding the `:restricted` suffix. This change was necessary because the `roleRef` field in a `ClusterRoleBinding` is immutable, which would otherwise cause errors during a Helm upgrade. As a result, users who deploy HCCM using the provided Kubernetes manifests must manually delete the old `ClusterRoleBinding` after applying the updated manifests. Users deploying via the Helm chart do **not** need to take any action. ```bash kubectl delete clusterrolebindings.rbac.authorization.k8s.io system:hcloud-cloud-controller-manager ``` ### Features - **helm**: use custom ClusterRole - configurable metrics address (#1055) ### Bug Fixes - add client-side timeouts to hcloud and robot clients (#1058)
chore(main): release v1.28.0-rc.1 (#1059) ### Updated ClusterRole for HCCM We have introduced a custom `ClusterRole` for the HCCM component, based on the [upstream recommendation from sig-cloud-provider](https://kubernetes.io/docs/concepts/architecture/cloud-controller/#authorization-miscellaneous). Due to this change, users who deploy HCCM using the provided Kubernetes manifests must manually remove the old ClusterRoleBinding after applying the updated manifests. Users deploying via the Helm chart do not need to perform any migration steps. ```bash kubectl delete clusterrolebindings.rbac.authorization.k8s.io system:hcloud-cloud-controller-manager ```
chore(main): release v1.28.0-rc.0 (#1051) ### Updated ClusterRole for HCCM We have introduced a custom `ClusterRole` for the HCCM component, based on the [upstream recommendation from sig-cloud-provider](https://kubernetes.io/docs/concepts/architecture/cloud-controller/#authorization-miscellaneous). Because of this change, a simple `helm upgrade` may fail due to immutable fields in the existing `ClusterRoleBinding`. To ensure a successful upgrade, you must delete the existing `ClusterRoleBinding` before upgrading. **This will make HCCM temporarily unavailable until the new version is deployed. Please avoid making any changes to the clusters, especially node- or service-related modifications, during this time.** ```bash kubectl delete clusterrolebindings.rbac.authorization.k8s.io system:hcloud-cloud-controller-manager ``` ### Features - **helm**: use custom ClusterRole - configurable metrics address (#1055) ### Bug Fixes - add client-side timeouts to hcloud and robot clients (#1058)
chore(main): release v1.27.0 (#983) ### 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](./docs/guides/load-balancer/private-networks.md). ### 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)](kubernetes/enhancements#5289). 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`
chore(main): release v1.27.0-alpha.1 (#982) 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)
chore(main): release v1.27.0-alpha.0 (#972) 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)](kubernetes/enhancements#5289). Furthermore, a [work-in-progress pull request](kubernetes/kubernetes#131220) 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)
PreviousNext