Skip to main content
Telepresence is a powerful tool designed to streamline Kubernetes development by connecting your local environment directly to a remote cluster. In this lesson, we’ll explore the motivations behind Telepresence, the problems it solves, and how it works under the hood.

​
The challenge of testing code in Kubernetes

When you update application code in Kubernetes, every new iteration typically requires a full build-and-deploy cycle: 
// Version 1
app.get("/", (req, res) => {
  res.json({ message: "This is v1" });
});

// Version 2
app.get("/", (req, res) => {
  res.json({ message: "This is v2" });
});
To test v2 in-cluster, you must:
  1. Build a Docker image 
    docker build -t kodekloud/auth:v2 .
  2. Push it to a registry 
    docker push kodekloud/auth:v2
  3. Update your Deployment manifest 
    spec:
  template:
    spec:
      containers:
      - name: auth
        image: kodekloud/auth:v2
  4. Apply the changes 
    kubectl apply -f deployment.yaml
Each code change triggers this manual sequence—packaging, pushing, manifest editing, and redeployment—turning a quick test into a multi-minute ordeal.

​
Manual vs. Telepresence development workflow

StepManual Kubernetes CycleTelepresence Flow
Code changeEdit, build, push, deployEdit locally
Build timeMinutesZero
Cluster DNS resolutionInaccessible from laptopFully supported
Live debuggingDifficult, remote logsDebug with IDE locally

​
Local development vs. Kubernetes networking

A common scenario is running Service A locally while the rest of the cluster (e.g., Service B) remains in Kubernetes. However, built-in networking makes this challenging:
  • Pod CIDR: 172.16.0.0/16
  • Service CIDR: 10.0.0.0/16
  • In-cluster DNS (kube-dns)
From your laptop: 
nslookup service-a       # fails
curl http://service-a:3000  # fails
curl http://172.16.0.1      # unreachable
Without a tunnel, your laptop can’t resolve or reach in-cluster Pod/Service IPs or DNS names.
You need a way for your local machine to appear inside the cluster network.

​
Two-way proxy tunnel

Telepresence solves this by establishing a transparent two-way proxy between your laptop and the Kubernetes cluster:
The image illustrates a network setup involving Telepresence, showing a laptop connected to a Kubernetes cluster with pods and services, along with their respective CIDR notations.
With the Telepresence tunnel, you can:
  • Access pod and service CIDR ranges as if local
  • Perform in-cluster DNS lookups: 
    nslookup service-a
curl http://service-a:3000
  • Use Kubernetes APIs and services transparently
Your workstation now behaves like a pod inside the cluster.

​
Intercepts for live debugging

Telepresence’s intercept feature lets you run an exact copy of a service locally, retaining its environment:
  1. Telepresence captures the pod’s network namespace, environment variables, and volumes.
  2. Cluster traffic destined for that service is redirected to your local process.
The image illustrates a "Telepresence Intercept" setup, showing a user interacting with a frontend, which is connected to a Kubernetes cluster and a local development environment with network namespace and environment variables.
Now you can:
  • Step through code with your IDE
  • Hot-reload changes instantly
  • Preserve in-cluster configuration and secrets

​
Simplified cloud resource access

Since Telepresence makes your laptop look like a cluster pod, you automatically inherit existing network permissions:
  • No extra VPNs or bastion hosts required
  • Direct connectivity to cloud services (e.g., AWS RDS)
  • Secure access using in-cluster service accounts

​
Summary of benefits

The image is a summary list highlighting six benefits of a process related to development and debugging, proxy tunneling, Kubernetes operation, traffic interception, access to namespaces, and cloud communication.
Telepresence accelerates Kubernetes development by:
  • Establishing a two-way proxy tunnel between laptop and cluster
  • Enabling your machine to operate as if inside Kubernetes
  • Intercepting traffic for live debugging of local services
  • Preserving pod networking, environment variables, and volumes
  • Providing seamless access to in-cluster and cloud resources

Watch Video