Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mlspawner uses Subnets from the internet #23

Open
sluetze opened this issue Jan 25, 2021 · 1 comment
Open

mlspawner uses Subnets from the internet #23

sluetze opened this issue Jan 25, 2021 · 1 comment

Comments

@sluetze
Copy link

sluetze commented Jan 25, 2021

To avoid conflicts with local docker networks, the code uses the subnets 172.33. upwards.
This IP-Ranges are public ip ranges. The networks only exist locally on each host, but there may be a issue, when a spawned container wants to contact a service/ip/Packetresource which resides in the same created subnet. even though this case may not have a high probability, it theoretically can occur.

# we create networks in the range of 172.33-255.0.0/24
# Docker by default uses the range 172.17-32.0.0, so we should be save using that range
INITIAL_CIDR_FIRST_OCTET = 172
INITIAL_CIDR_SECOND_OCTET = 33
INITIAL_CIDR = "{}.33.0.0/24".format(INITIAL_CIDR_FIRST_OCTET)

I would recommend to use another private subnet range, as specified by https://tools.ietf.org/html/rfc1918 Chapter 3. Since the 192.168.x ranges are often used in private networks, and only have a small subnet-possibility I would use a 10.x.x.x Net-Range

@LukasMasuch LukasMasuch added this to Inbox in issue-progress Jan 25, 2021
@ClementGautier
Copy link
Contributor

The problem is that 10.x.x.x is often used for Kubernetes as default CIDR for services (kubeadm --service-cidr defaults to 10.96.0.0/12, Rancher RKE also uses similar ranges for cluster cidr). Ideally, not using fixed ip and relying on kubernetes as a scheduler would solve that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
issue-progress
  
Inbox
Development

No branches or pull requests

2 participants