Allow choosing docker network subnet

[dweebo]

Problem
I have a network conflict issue. In our case, our EKS clusters use a service CIDR of 172.20.0.0/16.

We are using the --docker option when running telepresence connect. Our engineers use mac osx laptops.

The problem seems to be that occasionally the docker network that telepresence creates picks a 172.20.x address and we get an error like this:

telepresence connect: error: Unable to create network <network name>: Error response from daemon: failed to add interface tp-uc4yvqwkin6q to sandbox: error setting interface "tp-uc4yvqwkin6q" IP to 172.20.0.2/16: cannot program address 172.20.0.2/16 in sandbox interface because it conflicts with existing route {Ifindex: 12 Dst: 172.20.0.0/16 Src: 172.20.0.0 Gw: <nil> Flags: [] Table: 254 Realm: 0}

I was able to fix it for one user by configuring dockers default-address-pools in the engine settings and restarting docker, but I am looking to avoid having to have our engineers do that manual step.

I could be wrong of course but that seems to be the root of the issue, please correct me if I've misunderstood the error.

Solution I'd like
I would like the ability to pass in a --docker-subnet field (or some flag) to telepresence connect and have it use that in the created network.

Alternatives I've considered
Having users configure dockers default-address-pools in the engine settings and restarting docker.

Pre-creating the docker network with a non-conflicting subnet and having telepresence reuse it (I wasn't able to get that working, but if you have suggestions that would be greatly appreciated).

Versions

$ telepresence version
OSS Client : v2.23.6
Root Daemon: not running
User Daemon: not running

$ kubectl version
Client Version: v1.30.14
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.32.9-eks-3cfe0ce

[thallgren]

Can you please try the 2.25.1 client instead? There's been a lot of changes to the docker integration since 2.23. Even if your problem should persist after an upgrade, that's the version where we'll make adjustments.

Thanks.

[dweebo]

I upgraded to 2.25.1 but telepresence was unresponsive when running replace
Is the performance for larger clusters much worse with this version?

It worked fine on our smaller test cluster.
We have 72 namespaces at the moment that are enabled for telepresence

[thallgren]

That's worrying. The performance should not be worse. I'd be interested in looking deeper into that. Can you provide logs from the traffic-manager/traffic-agent? If not here, then perhaps we can continue that discussion in using DMs in Slack?

That said, on your smaller test cluster, did you manage to verify the docker network issue?

[bensaufley]

FWIW I'm trying to set up a Telepresence configuration using docker compose and running into the error mentioned in the original post, on 2.25.1. Proxying a number of services in a number of namespaces and running telepresence compose -f docker-compose.dev.yml create; it consistently sets up two proxies and then fails on the third, at 172.20.0.0/16.

[thallgren]

A sample reproducer would be valuable here and probably speed up the resolution. Ticket #4053 provides a good example.