While preview URLs are a powerful feature, there are other options to use Telepresence for proxying traffic between your laptop and the cluster.
Connecting to the cluster instead of running an intercept will allow you to access cluster workloads as if your laptop was another pod in the cluster. You will be able to access other Kubernetes services using
<service name>.<namespace>, for example by curling a service from your terminal. A service running on your laptop will also be able to interact with other services on the cluster by name.
Connecting to the cluster starts the background daemon on your machine and installs the Traffic Manager pod into the cluster of your current
kubectl context. The Traffic Manager handles the service proxying.
telepresence connect, you will be prompted for your password to run the daemon.Terminal$ telepresence connectLaunching Telepresence Daemon v2.3.7 (api v3)Need root privileges to run "/usr/local/bin/telepresence daemon-foreground /home/<user>/.cache/telepresence/logs '' ''"[sudo] password:Connecting to traffic manager...Connected to context default (https://<cluster public IP>)
telepresence statusto confirm that you are connected to your cluster and are proxying traffic to it.Terminal$ telepresence statusRoot Daemon: RunningVersion : v2.3.7 (api 3)Primary DNS : ""Fallback DNS: ""User Daemon: RunningVersion : v2.3.7 (api 3)Ambassador Cloud : Logged outStatus : ConnectedKubernetes server : https://<cluster public IP>Kubernetes context: defaultTelepresence proxy: ON (networking to the cluster is enabled)Intercepts : 0 total
Now try to access your service by name with
curl web-app.emojivoto:80. Telepresence will route the request to the cluster, as if your laptop is actually running in the cluster.Terminal$ curl web-app.emojivoto:80<!DOCTYPE html><html><head><meta charset="UTF-8"><title>Emoji Vote</title>...
Terminate the client with
telepresence quitand try to access the service again, it will fail because traffic is no longer being proxied from your laptop.Terminal$ telepresence quitTelepresence Daemon quitting...done
By default, Telepresence will provide access to all Services found in all namespaces in the connected cluster. This might lead to problems if the user does not have access permissions to all namespaces via RBAC. The
--mapped-namespaces <comma separated list of namespaces> flag was added to give the user control over exactly which namespaces will be accessible.
When using this option, it is important to include all namespaces containing services to be accessed and also all namespaces that contain services that those intercepted services might use.
An intercept with the flag
--local-only can be used to control outbound connectivity to specific namespaces.
When developing services that have not yet been deployed to the cluster, it can be necessary to provide outbound connectivity to the namespace where the service is intended to be deployed so that it can access other services in that namespace without using qualified names. Worth noting though, is that a local-only intercept will not cause outbound connections to originate from the intercepted namespace. Only a real intercept can do that. The reason for this is that in order to establish correct origin, the connection must be routed to a
traffic-agentof an intercepted pod. For local-only intercepts, the outbound connections will originate from the
$ telepresence intercept <deployment name> --namespace <namespace> --local-only
The resources in the given namespace can now be accessed using unqualified names as long as the intercept is active. The intercept is deactivated just like any other intercept.
$ telepresence leave <deployment name>
The unqualified name access is now removed provided that no other intercept is active and using the same namespace.
If you have a resource outside of the cluster that you need access to, you can leverage Headless Services to provide access. This will give you a kubernetes service formatted like all other services (
my-service.prod.svc.cluster.local), that resolves to your resource.
If the outside service has a DNS name, you can use the ExternalName service type, which will create a service that can be used from within your cluster and from your local machine when connected with telepresence.
If the outside service is an ip, create a service without selectors and then create an endpoint of the same name.
In both scenarios, Kubernetes will create a service that can be used from within your cluster and from your local machine when connected with telepresence.