instructions for self-managed private network not working

[xoxys]

I want to use the hcloud-ccm without network support and want to manage the private network used by nodes (K3s --node-ip=<private-network-ip>) on my own. As described in the README and #147 (comment) I have added the missing HCLOUD_NETWORK env variable to the ccm.yaml manifest and created the secret with the token and network name. But the deployment still fails:

k3s kubectl logs hcloud-cloud-controller-manager-7f4cddf697-xm2mt -n kube-system
Flag --allow-untagged-cloud has been deprecated, This flag is deprecated and will be removed in a future release. A cluster-id will be required on cloud instances.
I1118 10:32:40.653868       1 serving.go:348] Generated self-signed cert in-memory
W1118 10:32:40.932295       1 client_config.go:617] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I1118 10:32:40.933393       1 metrics.go:41] Starting metrics server at :8233
I1118 10:32:41.288243       1 cloud.go:143] Hetzner Cloud k8s cloud controller v1.9.1 started
W1118 10:32:41.288334       1 main.go:77] detected a cluster without a ClusterID.  A ClusterID will be required in the future.  Please tag your cluster to avoid any future issues
I1118 10:32:41.288684       1 controllermanager.go:143] Version: v0.0.0-master+$Format:%H$
I1118 10:32:41.296301       1 requestheader_controller.go:169] Starting RequestHeaderAuthRequestController
I1118 10:32:41.296456       1 shared_informer.go:255] Waiting for caches to sync for RequestHeaderAuthRequestController
I1118 10:32:41.296758       1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::client-ca-file"
I1118 10:32:41.296846       1 shared_informer.go:255] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
I1118 10:32:41.297158       1 configmap_cafile_content.go:202] "Starting controller" name="client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file"
I1118 10:32:41.297201       1 shared_informer.go:255] Waiting for caches to sync for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1118 10:32:41.297904       1 secure_serving.go:210] Serving securely on [::]:10258
I1118 10:32:41.298911       1 tlsconfig.go:240] "Starting DynamicServingCertificateController"
I1118 10:32:41.360798       1 node_lifecycle_controller.go:77] Sending events to api server
I1118 10:32:41.361080       1 controllermanager.go:291] Started "cloud-node-lifecycle"
I1118 10:32:41.361843       1 controllermanager.go:291] Started "service"
I1118 10:32:41.362136       1 controller.go:233] Starting service controller
I1118 10:32:41.362170       1 shared_informer.go:255] Waiting for caches to sync for service
I1118 10:32:41.397183       1 shared_informer.go:262] Caches are synced for RequestHeaderAuthRequestController
I1118 10:32:41.397463       1 shared_informer.go:262] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::requestheader-client-ca-file
I1118 10:32:41.397192       1 shared_informer.go:262] Caches are synced for client-ca::kube-system::extension-apiserver-authentication::client-ca-file
E1118 10:32:41.770347       1 controllermanager.go:275] Error starting "route"
F1118 10:32:41.770378       1 controllermanager.go:180] error running controllers: failed to parse cidr value:"" with error:invalid CIDR address:

As a workaround (not even sure if that really works) I have added the --cluster-cidr=<pod-cidr-managed-by-calico> flag to the ccm.yaml manifest and recreated the deployment. Not the pod starts without errors, but also create routes that look wrong and shouldn't be required at all).

[xoxys]

Stumbled over #304 is that the intended way to disable routes in that case?

[lordgreg]

hi @xoxys - thank you for your contribution. This issue started appearing with the version 1.13.0. The 1.12.1 functions without any issues.

We've also updated the deployment file and added the variable:

        - name: HCLOUD_NETWORK_ROUTES_ENABLED
          value: "false"

Now, the deployment passes with "skipping routers" and without any issues.

[github-actions]

This issue has been marked as stale because it has not had recent activity. The bot will close the issue if no further action occurs.