Repository navigation
Cluster templates work out-of-the-box with managed networks (without provided network_id) #37
Description
User Story
As a CAPSTK User I want:
cluster templates to work out-of-the-box with managed networks without having to provide STACKIT_NETWORK_ID
So that: I can spin up a fully working Kubernetes cluster with automatic network provisioning and a functional Cloud Controller Manager (CCM).
Context & Problem Statement
Currently, StackitCluster supports creating managed networks dynamically at runtime (#34). However, our cluster templates (templates/cluster-template*.yaml) deploy the STACKIT Cloud Controller Manager via a ClusterResourceSet, which embeds a static cloud.yaml (stackit-cloud-config).
Since stackit-cloud-controller-manager strictly requires loadBalancer.networkId to start, users cannot omit STACKIT_NETWORK_ID when using clusterctl generate cluster today.
Acceptance Criteria
- Users can deploy clusters using cluster templates without specifying
STACKIT_NETWORK_ID. - The deployed
stackit-cloud-controller-managerreceives the dynamically resolved network ID (from.status.network.idor.spec.network.id) and starts successfully. - Services of
type: LoadBalancercan successfully provision STACKIT load balancers in both BYO and managed network modes.
Potential Approaches / Ideas for Discussion
-
Controller-managed Secret for CRS (Management Cluster): CAPSK reconciles/updates the
ClusterResourceSetSecret (containingstackit-cloud-config) on the management cluster once the network ID is known, letting CAPI's CRS handle the workload cluster sync.
Example: CAPV -
Workload-Cluster ConfigMap reconciliation: CAPSK directly reconciles/patches the
stackit-cloud-configConfigMap inkube-systemof the workload cluster once the control plane is reachable.
Example: CAPO -
(Optional / External) CCM Auto-Discovery: Support omitting
loadBalancer.networkIdand auto-discovering it from node network interfaces/metadata directly withinstackitcloud/cloud-provider-stackit.
(Note: Requires change and a new release in the external CCM repository).
Example: GCP, AWS, ...
Activity
fabian-schmitt commentedon Nov 3, 2026
Follow-Up for a completed user-experience:
#37
tuunit commentedon Nov 4, 2026
I think what we could do is split the CCM resources in the static and dynamic parts. Keep all things DaemonSet, RBAC, SA, etc. in the template and only split out the dynamic configuration containing the networkId out.
This way everything can already be deployed without a hard dependency on something like "STACKIT_NETWORK_ID".
Then we can extend our cluster controller to reconcile a secret named
<cluster-name>-cloud-configusing the networkID be it provided through the spec or a dynamic one created and stored in the status field. By giving it the typeaddons.cluster.x-k8s.io/resource-setit should automatically ensure it is distributed to the cluster through capi-system.We need to ensure the cleanup works as well therefore I guess we need to set the OwenrReference or similar.
tuunit commentedon Nov 4, 2026
Additionally we could consider rasining a issue in the cloud-provider-stackit repo to allow for auto-discovery in the future