Supercharge Your Debugging Sessions with Telepresence: A Virtual Gateway into Kubernetes

In the world of software development, debugging is an essential and often time-consuming task. Developers strive to identify and fix issues swiftly to ensure smooth operation and optimal performance. However, traditional debugging methods often come with limitations, particularly when working with complex systems like Kubernetes clusters. Enter telepresence, a technology that offers a virtual gateway into the heart of Kubernetes, enabling developers to work as if they were inside the cluster itself.

By seamlessly bridging the gap between their local development environment and the Kubernetes cluster, telepresence empowers developers to gain real-time access and interact directly with the cluster’s components. This article explores the potential of telepresence, highlighting how it supports local debugging sessions and enables developers to work with efficiency, as if they were physically present within the Kubernetes cluster. They can interact with the cluster’s resources, observe real-time behaviors, and make changes on the fly, all while working within their familiar local environment. This unique capability not only enhances productivity but also significantly reduces the time and effort required to diagnose and resolve issues.

Get telepresence up and running

There are multiple ways to set up telepresence on your machine. We need telepresence itself and a traffic manager inside the cluster we want to debug.

The traffic manager installed by telepresence is a dynamic proxy that redirects network traffic between the local development environment and the Kubernetes cluster. During debugging, developers can effortlessly interact with cluster resources, ensuring correct service routing for requests. This enables real-time observation, code testing, and efficient troubleshooting within the Kubernetes ecosystem.

1. Manual

First, we need to install telepresence on our local machine.

# Install on mac using brew

# for intel processors remove the -arm64

brew install datawire/blackbird/telepresence-arm64



# Install on linux

# 1. Download the latest binary (~50 MB):

sudo curl -fL https://app.getambassador.io/download/tel2/linux/amd64/latest/telepresence -o /usr/local/bin/telepresence



# 2. Make the binary executable:

sudo chmod +x /usr/local/bin/telepresence

Now we’ve got telepresence and we then need to install a traffic manager inside our cluster. This traffic manager keeps track of the routing inside the cluster and can reroute traffic to our local machine.

telepresence helm install

Now that everything is there, we can connect to the cluster and beam ourselves into the cluster

telepresence connect --namespace <name-of-your-namespace>

2. With Jetbrains products

1. Open the services window

2. Right click on your connected kubernetes cluster

3. Select connect to telepresence

If Telepresence is not present on your computer or there is no traffic manager inside the cluster, a notification will pop up, allowing you to choose to install it.

Intercept traffic from the cluster

In the past, when working with Kubernetes and microservices, developers faced two main options. They could either run through a complete build automation cycle, which often involved time-consuming processes for even minor code changes (such as pushing code, waiting for builds, and deployments). Alternatively, they could run all relevant services locally on their laptop.

Now we can replace those options with telepresence and put our local machine as a kind of man in the middle between the services running inside the cluster.

So now we could start intercepting traffic from the cluster manually with

telepresence intercept <name-of-the-service> --port <local-port>

or via Jetbrains through the services window, where we can create a new interception.

Once the interception is created, the traffic manager redirects the traffic from the cluster to our local machine. If we now start the service we want to debug locally, we can use the tool of our choice to start debug and gaining more insights.

The traffic manager also allows to communicate with all other services from the cluster through the cluster dns entries.

Debugging example

For demonstrating how it would work, let’s assume we have already a working cluster. Now first off, we would start the interception of a deployment/service or pod.

telepresence intercept <name-of-service> --port <local-port>

If we would run a local dotnet webapi this would then be port 5000 (default). Here you need to pick the port of your locally running service. This port get’s then used to forward the traffic from the cluster towards your locally running instance.

After creating the interception we would then spin up our application locally and then start debugging.

A sample setup could look like this:

How does telepresence work?

Telepresence connects the local and remote networks by creating a virtual network bridge between them. Activating telepresence intercepts network traffic from the local environment and redirects it to the Kubernetes cluster. It achieves this by combining network address translation (NAT) and proxying techniques.

Telepresence sets up a local proxy on the developer’s machine, which acts as a gateway for network traffic. When the local environment makes a request to a service in the Kubernetes cluster, the proxy intercepts the request and forwards it to the appropriate destination within the cluster. The proxy also ensures that the cluster’s response is directed back to the local environment.

To establish this connection, telepresence modifies the routing tables on the developer’s machine, redirecting traffic destined for the cluster’s IP addresses to the local proxy. The proxy then encapsulates and forwards the traffic to the cluster. This allows the developer to interact with the cluster’s resources as if they were directly connected to the cluster’s network.

Furthermore, telepresence utilizes techniques such as port forwarding and network address translation to ensure the correct routing of network traffic between the local and remote environments. These techniques enable seamless communication between the local development environment and the services running in the Kubernetes cluster.

Conclusion

In summary, telepresence presents an interesting solution for local debugging in Kubernetes, offering a seamless and immersive experience. By bridging the gap between developers’ local environments and the Kubernetes cluster, telepresence enables direct interaction with cluster resources, real-time observation of behaviors, and swift changes in a controlled environment. This not only boosts productivity but also reduces the time and effort required for issue resolution. With telepresence, developers can work with unmatched efficiency, as if they were physically within the Kubernetes cluster. Embracing telepresence revolutionizes the local debugging process, leading to accelerated development cycles and enhanced software quality. Upgrade your debugging experience in Kubernetes by embracing the power of telepresence.