Proxy Outbound Traffic to My Cluster

While preview URLs are a powerful feature, there are other options to use Telepresence for proxying traffic between your laptop and the cluster.

Proxying Outbound Traffic

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.

1. Run telepresence connect, you will be prompted for your password to run the daemon.

2. Run telepresence status to confirm that you are connected to your cluster and are proxying traffic to it.

3. Now try to access your service by name with curl verylargejavaservice.default:8080. Telepresence will route the request to the cluster, as if your laptop is actually running in the cluster.

4. Terminate the client with telepresence quit and try to access the service again, it will fail because traffic is no longer being proxied from your laptop.

Controlling Outbound Connectivity

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.

Using local-only intercepts

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.

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.

The unqualified name access is now removed provided that no other intercept is active and using the same namespace.

External dependencies (formerly --also-proxy)

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.