Change:
fs.DurationVar(&o.NodeMonitorPeriod.Duration, "node-monitor-period", o.NodeMonitorPeriod.Duration, fmt.Sprintf("The period for syncing NodeStatus in %s.", names.CloudNodeLifecycleController)) fs.StringVar(&o.ClusterName, "cluster-name", o.ClusterName, "The instance prefix for the cluster.") <del> fs.StringVar(&o.ClusterCIDR, "cluster-cidr", o.ClusterCIDR, "CIDR Range for Pods in cluster. Requires --allocate-node-cidrs to be true") fs.BoolVar(&o.AllocateNodeCIDRs, "allocate-node-cidrs", false, "Should CIDRs for Pods be allocated and set on the cloud provider.") </del> <ins> fs.StringVar(&o.ClusterCIDR, "cluster-cidr", o.ClusterCIDR, "CIDR Range for Pods in cluster. Only used when --allocate-node-cidrs=true; if false, this option will be ignored.") fs.BoolVar(&o.AllocateNodeCIDRs, "allocate-node-cidrs", false, "Should CIDRs for Pods be allocated and set on the cloud provider. Requires --cluster-cidr.") </ins> fs.StringVar(&o.CIDRAllocatorType, "cidr-allocator-type", "RangeAllocator", "Type of CIDR allocator to use") fs.BoolVar(&o.ConfigureCloudRoutes, "configure-cloud-routes", true, "Should CIDRs allocated by allocate-node-cidrs be configured on the cloud provider.")

Discussion:
In on --cluster-cidr flag is written that it requires --allocate-node-cidrs to be true. Bu actual, we can set non empty --cluster-cidr and disable node cidr allocation (set --allocate-node-cidrs to false). I expect to see in documentation of --allocate-node-cidrs flag note that for this node pod cidr allocation functionality is required to set the --cluster-cidr flag. Also in documentation on --cluster-cidr flag I expect removing mention about that it requires --allocate-node-cidrs flag to be true. Run controller manager with 2 flags: --allocate-node-cidrs=false --cluster-cidr=172.20.0.0/16 We are using this functionality to change the expand cluster CIDR subnet. As I see, we can temporary disable nodeIPAM controller work by setting --allocate-node-cidrs=false. I found a with the code that ignores cluster cidr parsing if allocate-node-cidrs flag is false. kubernetes version 1.23.17 bare metal No response No response No response No response
This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the label and provide further guidance. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/sig docs
if you disable the value of is not used anyhwere, is it? I do not understand exactly what do you mean here, can you elaborate in your use case?
/assign
We have a cluster which was initialized with and . Our cluster grew to 65 nodes. In kube-controlle-manager logs we observed errors like: This error appears because the nodeIPAM controller is enabled and it tries to allocate a podCIDR subnet with /24 mask for each node. have 64 subnets - so for 65'th node there is now free subnet. We want to expand cluster CIDR subnet. For this action, while maintenance, we want to disable kube-controller-manager's nodeIPAM controller. Actually we can do this by changing only one flag in kube-controller-manager . The flag can remain unchanged.

Yes it is. The main idea of the issue is to change the affirmation in . Would be more transparent if flag will require flag to be set. Bot not vice versa. From the docs It is not clear that you can disable allocation of node CIDR and leave the flag cluster-cidr. I try to thing back side: If the flags and are 100% connected and there are used only by nodeIPAM, why do we need this separate flags. As I understand: configures the CIDR parameter for nodeIPAM controller. enables the controller. So if I am right in previous affirmations, the flag actually does not require to be true. NodeIPAM controller requires and with a subnet set.
/cc as we talked about this today
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
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, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at .

/lifecycle stale [1]:
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues. This bot triages un-triaged issues according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue as fresh with Close this issue with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle rotten [1]:
/remove-lifecycle rotten
/assign