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

Telepresence should send all traffic to the cluster (container method) #391

Closed
ark3 opened this Issue Dec 28, 2017 · 3 comments

Comments

1 participant
@ark3
Copy link
Contributor

ark3 commented Dec 28, 2017

It seems #320 is also an issue in container mode. We should consider having all container traffic go to the cluster, much like inject-tcp mode works.

@ark3

This comment has been minimized.

Copy link
Contributor

ark3 commented Mar 21, 2018

FWIW, @plombardi89 worked around this issue (and #320) in Kubernaut by putting an IP address in the generated Kubernetes configuration for Kubernaut clusters. This avoids the DNS lookup entirely. Regardless, we should still consider sending all container traffic to the cluster. Among other things, that would avoid some cluster analysis on startup, thereby speeding things up.

@ark3 ark3 changed the title kubectl under Telepresence container mode & Kubernaut doesn't work Telepresence should send all traffic to the cluster (container method) Apr 16, 2018

@ark3

This comment has been minimized.

Copy link
Contributor

ark3 commented Apr 16, 2018

Note that docker run has a few options to configure DNS in the container.

@ark3

This comment has been minimized.

Copy link
Contributor

ark3 commented Jun 11, 2018

Plan:

  • Use kubectl exec to grab the hostname and resolv.conf of the proxy pod. See telepresence.remote_env._get_remote_env(...) for an example. Perhaps even do this in the same place; these are components of the remote environment in some sense.
  • Use the captured info to modify the appropriate docker run command with --hostname and --dns* flags as described in the options link above. You will need to figure out whether these flags need to be used for the network container or the user container (or both).
  • Replace the sshuttle invocation in the network container with one that proxies 0/0 instead of a subset of the IP space. You still need --dns even if the above DNS configuration step worked correctly for the user container to convince sshuttle to capture UDP on port 53.
  • Actively disallow (by erroring out) Telepresence options that are intended for the vpn-tcp method.

@ark3 ark3 added this to To do in Tel Tracker via automation Jun 11, 2018

@ark3 ark3 moved this from To do to In progress in Tel Tracker Dec 6, 2018

@ark3 ark3 closed this in 0b89784 Dec 7, 2018

Roadmap automation moved this from Kubernaut Integration to Completed Dec 7, 2018

Tel Tracker automation moved this from In progress to Done Dec 7, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment