The perNodeHostBits should be per family

[uablrek]

To have just one for both ipv4/ipv6 enforces a limit on the number of PODs on a node only based on the shortcomings of ipv4. It should be possible to define for instance "perNodeHostBits4: 7" and "perNodeHostBits6: 32"

For instance a large cluster may want 1000's of PODs/node, but only gateways/ingress-controllers with IPv4 addresses. They shouldn't be forced to allocate >10 perNodeHostBits for IPv4.

Please see kubernetes/enhancements#2593 (comment)

[aojea]

@uablrek I don't understand your example,the number of pods should be the same per host in both families, if you have some pods dual stack and others single stack some applications may fail to work.

Relying on previous knowledge of what kind of application you are going to run is not something we can generalize and force users to have a right control of the IP planning, that is precisely what we want to abstract

[uablrek]

CNI plugins can assign IPv4 addresses to just some PODs, e.g. in a namespace. Calico, and my own kube-node IPAM supports it, and probably other CNI-plugins as well.

But to extend the API (CRD) with this proposed feature in a backward compatible way when/if the need arises in the future is not hard.

[aojea]

but why someone will want to do this? that is my question, one thing is that we can do it, but what problem does it solve?

If you run applications that may have dual or single family without a tight control they may work or not

[uablrek]

They may want to raise maxPods per node from the default of 110, to let's say 1000, without having to waste 11-bit (1024 + 1024 for migration) for unused IPv4 addresses (blog). All problems this feature is solving is there only because of IPv4. I suggest to at least allow a possibility to rid yourself of them. If IPv6 was used you would assign a segment large enough for the lifetime of K8s, and never think about it again.

[aojea]

but my point is that mixed pods on same node or same cluster does not make sense, or either are all single-stack IPv4 or IPv6 or all dual-stack.
My line of thinking is that is that pods are randomly scheduled, and there are multiple users of the cluster that don't have any idea of how their application will behave regarding the network, so imagine you have a deployment with 3 replicas, and 2 of them are dual stack and other single stack, and for whatever reason need to use IP adddress information.

That is an edge case, but my experience with mixed environments on production is that are always going to fail intermittently with random behaviors, and add a lot of problems to the supports teams, I do not think we should offer an API that allows users to create this complexity

[aojea]

This is a fact for decades of ipv6 history, mixed ip families workloads does not work well https://en.wikipedia.org/wiki/IPv6_brokenness_and_DNS_whitelisting , if we add mixed families plus single stack, I can not see this can improve, rather most likely will regress

[k8s-triage-robot]

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