What would you like to be added:
A new metric exposing the podCIDRs field from the Node spec (node.spec.podCIDRs), which contains the list of CIDR ranges assigned to the node for Pod IP allocation.
Why is this needed:
podCIDRs is the authoritative multi-value successor to podCIDR and is required for dual-stack clusters, where a node will have both an IPv4 and IPv6 CIDR assigned. There is currently no way to observe or alert on this field via kube-state-metrics. This would enable the capability to alert on misconfigurations. For example, you might spin up a 6 node cluster and grant it a /108 IPv6 CIDR range and assume 1,048,576 IPs would be enough for your cluster's Pods. But in fact the way kubernetes splits that CIDR up, you'll end up with 2 nodes without IPv6 ranges.
Describe the solution you'd like:
A presence-style metric with one series per CIDR entry:
kube_node_spec_pod_cidr{node="node1", cidr="10.0.1.0/24", ip_family="IPv4"} 1
kube_node_spec_pod_cidr{node="node1", cidr="fd00::/120", ip_family="IPv6"} 1
This follows the existing pattern used by kube_node_spec_taint and similar multi-valued fields. The ip_family label can be derived from the CIDR itself (presence of : indicates IPv6).
This metric wouldn't be disruptive, you should end up with a cardinality of 1-2 timeseries per node depending on if your cluster is single or dual stack.
Additional context:
This metric enables alerting on dual-stack completeness, for example:
promql# Alert on nodes missing dual-stack CIDR assignment
count by (node) (kube_node_spec_pod_cidr) < 2
The existing kube_node_info metric exposes the singular pod_cidr field, but this does not capture the full podCIDRs array and is insufficient for dual-stack environments.
What would you like to be added:
A new metric exposing the podCIDRs field from the Node spec (node.spec.podCIDRs), which contains the list of CIDR ranges assigned to the node for Pod IP allocation.
Why is this needed:
podCIDRs is the authoritative multi-value successor to podCIDR and is required for dual-stack clusters, where a node will have both an IPv4 and IPv6 CIDR assigned. There is currently no way to observe or alert on this field via kube-state-metrics. This would enable the capability to alert on misconfigurations. For example, you might spin up a 6 node cluster and grant it a /108 IPv6 CIDR range and assume 1,048,576 IPs would be enough for your cluster's Pods. But in fact the way kubernetes splits that CIDR up, you'll end up with 2 nodes without IPv6 ranges.
Describe the solution you'd like:
A presence-style metric with one series per CIDR entry:
This follows the existing pattern used by kube_node_spec_taint and similar multi-valued fields. The ip_family label can be derived from the CIDR itself (presence of : indicates IPv6).
This metric wouldn't be disruptive, you should end up with a cardinality of 1-2 timeseries per node depending on if your cluster is single or dual stack.
Additional context:
This metric enables alerting on dual-stack completeness, for example:
The existing kube_node_info metric exposes the singular pod_cidr field, but this does not capture the full podCIDRs array and is insufficient for dual-stack environments.