@EanWo can you please share the logs of the component?

can you check that you have disabled the default ipam controller in the kube-controlller-manager and/or the cloud-controller-manager?

@EanWo can you please share the logs of the component?

can you check that you have disabled the default ipam controller in the kube-controlller-manager and/or the cloud-controller-manager?

Yes, I am certain. I have set the 'allocate-node-cidrs' parameter to 'false' for all master 'kube-controller-manager' configurations

@aojea I created a new ClusterCIDR object called 'clustercidr-name-ean' at step ①, which has a NodeSelector with the specified label 'name=ean', and the logs have recorded this. Then at step ②, I added a node with the label 'name=ean', but the result showed that the assigned PodCIDR belonged to the default ClusterCIDR. At this point, at step ③, I first removed the previously created node using the 'kubectl delete node' command, then re-added it to the cluster by restarting the node with the 'systemctl restart kubelet' command, and then restarted the controller. After that, at step ④, I saw that the node was assigned to the correct 'clustercidr-name-ean' ClusterCIDR.

@EanWo the original issue was for the old repo. Could you please confirm that you are using the latestv0.2.0 node-ipam-controller?

@EanWo the original issue was for the old repo. Could you please confirm that you are using the latestv0.2.0 node-ipam-controller?

@mneverov I am using the latest code from the main branch. Additionally, I have also tried the code from tag v0.2.0, and the results were the same.

@mneverov @aojea I tried modifying the code to print some logs and discovered some issues. At step ①, I added a ClusterCIDR object named 'name-ean'. At step ②, I printed the contents of the cidrMap, which showed only the default ClusterCIDR and did not include the newly added 'name-ean' ClusterCIDR. Then at step ③, I restarted the controller, and at this point, the cidrMap showed the newly added 'name-ean' ClusterCIDR.

@EanWo thank you for the info!
Do you use any CNI by chance? Can you add the new node yaml before you restart the manager?
What k8s distribution you use (k3s, kind, minikube, k3d ..)?

@mneverov I am using a cluster provided by a cloud vendor. I tested three versions of the Kubernetes cluster, with cluster versions and corresponding CNI plugins being v1.21 with Flannel, v1.23 with Calico, and v1.25 with Flannel. The test results were the same for all versions. I can add and remove nodes to and from the cluster at will.

I have resolved the issue. The cause of the problem was that the YAML file for the ClusterCIDR I created specified a finalizer for the controller.

/reopen

@sarveshr7 made a good analysis of this problem and I still think we should handle better this scenario, quoting from chat conversation for reference

We should modify the code here: https://github.com/kubernetes-sigs/node-ipam-controller/blob/d843244e4ae2ea7e4a877[…]f6751f461daf0/pkg/controller/ipam/multi_cidr_range_allocator.go , make the createClusterCIDR function idempotent and create the in-memory map irrespective of whether the finalizer is present or not
GitHubGitHub
node-ipam-controller/pkg/controller/ipam/multi_cidr_range_allocator.go at d843244e4ae2ea7e4a877f828d2f6751f461daf0 · kubernetes-sigs/node-ipam-controller

/assign @sarveshr7

@aojea: Reopened this issue.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

/assign