IP Address Range from different to be supported in single IPPool

[sachinphogat]

As per current CRD Spec, InClusterIPPool or GlobalInClusterIPPool supports addresses from 1 subnet only.
For eg,
Single InClusterIPPool and GlobalInClusterIPPool cannot support below two subnets,

1. 100.98.254.1- 100.98.254.100 (Prefix 23)
2. 100.96.32.1 - 100.96.32.100 (Prefix 22)

Request you to support both subnets under single IPPool. We were able to use this feature using capm3 ippool.
apiVersion: ipam.metal3.io/v1alpha1
kind: IPPool
metadata:
name: vlan
spec:
pools:

• end: 100.96.32.100
  prefix: 22
  start: 100.96.32.1
• end: 100.98.254.100
  prefix: 23
  start: 100.98.254.1

[schrej]

The spec does support multiple ranges. The examples in the usage examples just show variants, you can provide multiple ranges or subnets.

With the current resources, you'd need to set the prefix to 14, but I guess that's not what you want.

apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool-sample
spec:
  addresses:
    - 100.96.32.1-100.96.32.100
    - 100.98.254.1-100.98.254.100
  prefix: 14
  gateway: 100.98.254.254

I think the issue here is that we do not support different prefix lengths (and therefore also gateways) for different subnets or ranges. With the current CRD it would also be difficult to implement in a nice way. Maybe we could consider adding a list of networks as an alternative to addresses.

apiVersion: ipam.cluster.x-k8s.io/v1alpha2
kind: InClusterIPPool
metadata:
  name: inclusterippool-sample
spec:
  networks:
  - addresses:
    - 100.96.32.1-100.96.32.100
    prefix: 22
    gateway: 100.96.32.254
  - addresses:
    - 100.98.254.1-100.98.254.100
    prefix: 23
    gateway: 100.98.254.254

I'm not sure about adding this complexity here. For complicated setups like this, it might be better using an external IPAM system like Netbox or Infoblox. There is no provider for Netbox yet.

My condolences on that network setup, I thought our telco environment was bad, but this seems worse.

[sachinphogat]

Can we plan to add networks spec?

[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

[k8s-triage-robot]

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, 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 rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[k8s-triage-robot]

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

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

This bot triages 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:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

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

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.