Why Telepresence

In this lesson we explain why Telepresence is useful for Kubernetes development, what problems it solves, and how it speeds up the typical edit-build-push-apply cycle. Motivating example Imagine a Kubernetes cluster running version 1 of a service. You modify the code locally and want to test version 2 without shipping a new container image every time. Example change (Node/Express):

app.get("/", (req, res) => {
  res.json({
    message: "This is v2"
  });
});

Typical Kubernetes development workflow The usual approach to test a code change in-cluster involves rebuilding and redeploying an image, which adds latency to each iteration:

Step	Command / Action	Notes
Build new Docker image	`docker build -t kodekloud/auth:v2 .`	Packaging your change into an image
Push to registry	`docker push kodekloud/auth:v2`	Requires network, auth, and time
Update Deployment	Change `image:` in manifest and run `kubectl apply -f deployment.yaml`	Causes a rollout in the cluster

Example snippet from a Deployment manifest:

spec:
  selector:
    matchLabels:
      service: auth
  template:
    metadata:
      labels:
        service: auth
    spec:
      containers:
      - name: auth
        image: kodekloud/auth:v1

(You would change image: kodekloud/auth:v1 to kodekloud/auth:v2 and run kubectl apply -f deployment.yaml.) Summary: even a small code edit can require several seconds to minutes of build/push/deploy work, which slows down iterative development.

If you could run the modified service locally while the rest of the cluster runs unchanged, you could iterate instantly: edit, restart locally, and test — no image build and cluster deploy required.

Kubernetes networking constraints Kubernetes relies on cluster networking and internal DNS. Your laptop exists outside those networks, so it cannot automatically resolve cluster service names or reach pod/service IPs. Key cluster networking elements:

Component	Purpose	Typical range / example
Pod CIDR	IPs assigned to pods	`172.16.0.0/16` (example)
Service CIDR	Cluster IPs for Services	`10.0.0.0/16` (example)
Cluster DNS	kube-dns or CoreDNS for service name resolution	`kube-dns` / `CoreDNS`

From your laptop you cannot directly resolve or reach in-cluster DNS names and IP ranges:

nslookup service-a     # fails from laptop without cluster DNS resolution
curl http://172.16.0.1 # cannot reach pod IP from laptop

A slide titled "Why Telepresence?" showing a Kubernetes network diagram with pods (172.16.0.x) and services (10.0.0.x), Kube-DNS, and a laptop connected into the cluster. It illustrates the pod- and service-CIDR ranges and service endpoints.

Troubleshooting limitations inside containers When you need to debug DNS, network, or runtime issues from inside a pod, many production images are minimal and lack troubleshooting tools such as nslookup, dig, curl, or a shell. Common workarounds include:

Copying utilities into a running pod with kubectl cp:

kubectl cp /usr/bin/nslookup backend-pod:/tmp/nslookup

Deploying a separate debug pod that includes diagnostic tools.

Both approaches are inconvenient: copying binaries is brittle and a separate debug pod may not match the real pod’s environment (env vars, volumes, namespaces).

A presentation slide titled "Why Telepresence?" showing a Kubernetes diagram with a troubleshooting pod, backend, database and Kube-DNS inside a cluster. Developer tool icons (VS Code, debugging, browser) are shown outside the cluster, with a speech bubble saying "I don't have nslookup."

What Telepresence provides Telepresence creates a two-way proxy tunnel between your laptop and a Kubernetes cluster so your laptop behaves like a pod on the cluster network. With Telepresence:

Your laptop gains access to pod CIDR and service CIDR ranges.
Cluster DNS (kube-dns/CoreDNS) can resolve for your laptop just like for pods.
From a networking perspective, your laptop appears to the cluster as an in-cluster endpoint.

Once Telepresence is connected, common commands become meaningful from your laptop:

nslookup service-a
curl http://service-a:3000
curl http://172.16.0.1
# cluster network ranges (examples):
# 172.16.0.0/16
# 10.0.0.0/16

Intercepts: redirecting traffic to your local process A core Telepresence feature is the “intercept.” An intercept redirects traffic destined for a Kubernetes Service or set of pods to a local process you run on your laptop:

Telepresence captures the pod runtime context it needs (network namespace, environment variables, and volumes where possible).
It configures the cluster to forward traffic for the intercepted service to your local process.
Consumers in the cluster call the same Service/DNS name and do not notice anything changed.

This lets you run your service locally with your IDE, debugger, and local tools, while the rest of the system remains live in the cluster.

Access to cloud resources Because Telepresence makes your laptop appear as if it were running inside the cluster network, any external resources reachable from the cluster (for example an RDS database or other cloud services) become reachable from your laptop using the same cluster networking path. This can eliminate the need for separate VPNs, bastion hosts, or special firewall rules for many troubleshooting scenarios.

An architecture diagram titled "Telepresence" showing frontend and backend components (with a laptop) inside a dashed Kubernetes environment, linked to an Amazon RDS service in an AWS boundary.

Benefits summary Telepresence accelerates Kubernetes development and debugging by:

Creating a two-way proxy tunnel so your laptop can access cluster networks and DNS.
Letting you run selected services locally while the cluster continues to run (intercepts).
Reproducing a pod’s runtime context (network namespace, env vars, and volumes where possible) so your local process acts like the in-cluster pod.
Providing access to cloud resources reachable from the cluster without additional VPN setup.

Problem	How Telepresence helps
Slow edit-build-push-deploy cycle	Run service locally, intercept traffic — no image build required for every change
No cluster DNS from laptop	Telepresence forwards CoreDNS resolution to your laptop
Minimal container images lacking tools	Debug locally with full toolset while interacting with real cluster services
Need to access cloud resources via cluster network	Your laptop can use the cluster’s routes and credentials to reach those resources

Telepresence reduces the edit-build-push-apply loop by making your laptop behave like a pod on the cluster network. This enables fast, iterative local development against live Kubernetes environments while preserving production-like connectivity.

Course Introduction

Telepresence For Kubernetes

Watch Video