Develop directly on a Kubernetes cluster using a CDE (Gitpod) and Telepresence
Pauline Narvas
Feb 6, 2024
Kubernetes is a tool for production. Building your developer experience around Kubernetes with the appropriate feedback loops can be challenging. There is a disparity created between our local configuration tools like Docker and Docker Compose with our upstream configurations of Kubernetes Manifest files, Helm, Kustomize and all the complexities of cloud environments.
Running an entire Kubernetes cluster locally is challenging because of resource constraints and reproducibility issues. But, pushing to the cloud can lead to painfully long build and push loops waiting for continuous integration suites to build. But, luckily, we don’t have to compromise.
Enter Telepresence!
What is Telepresence?
Telepresence directly addresses Kubernetes developer experience challenges by creating a two-way proxy between your local (or cloud) development environment and a remote Kubernetes cluster. Using telepresence redefines the Kubernetes development experience by allowing developers to work as if they are developing inside a Kubernetes cluster without needing to go through a painful, docker build, test push cycle.
Why Gitpod and Telepresence?
Telepresence helps Kubernetes development by connecting to an external cluster. But questions remain such as: how do developers authenticate with your cluster? How, and when does that cluster (or namespace) get created? Gitpod is a Cloud Development Environment, and can automate everything a developer needs to be “ready-to-code”, including Telepresence configurations.
Gitpod works well with Telepresence, as Gitpod can automate the installation and configuration of Telepresence. Want a configuration that spins up your front-end and connects to your remote backend? You can do that with Gitpod. Want to spin up a single microservice and network it into a remote cluster of microservices? You can automate that with Gitpod.
Gitpod is providing the development environment automation that allows you to use powerful Kubernetes tools like Telepresence, by automating away all of the implementation details, like installation and authentication, so that developers can get up and running immediately. If a developer breaks their environment, they toss it away and create a new one. Simple.
Gitpod + Telepresence: A Guide
In this guide, we’ll walk you through the steps of installing Telepresence into a Gitpod workspace, allowing for real-time changes to applications within a Kubernetes cluster. Specifically, we’ll cover how to:
- Install Telepresence into a Gitpod workspace
- Configure a Gitpod workspace to establish a connection with a remote Kubernetes cluster
- Codify these steps so that every time you initiate a Gitpod workspace, you can drive straight into development
For this demo, I have a fresh EKS cluster with a very simple “hello” app deployed (a service, deployment and pod.)
Utilizing a cloud development environment (CDE) like Gitpod offers the flexibility to work with Docker, Docker Compose, or engage in a “remocal” development flow, enabling a seamless integration with services like Telepresence. This allows for the abstraction of underlying configurations and complexities, so developers can leverage Telepresence without needing in-depth knowledge of its operation, configuration, or authentication processes.
Prerequisites
- A Kubernetes cluster
- A Gitpod account (you can get started on Gitpod Cloud for free)
Getting started
Creating Gitpod configuration files
In your project Git repository, create a .gitpod.yml file with the following content to specify the Docker image for your workspace:
ymlimage:
file: .gitpod.DockerfileNext, create a .gitpod.Dockerfile to install kubectl and telepresence into your workspace:
ymlFROM gitpod/workspace-base:latest
## Install Kubectl
RUN curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && \
chmod +x ./kubectl && \
sudo mv ./kubectl /usr/local/bin/kubectl && \
mkdir /.kube
## Install Telepresence
RUN sudo curl -fL https://app.getambassador.io/download/tel2oss/releases/download/v2.17.0/telepresence-linux-amd64 -o /usr/local/bin/telepresence
RUN sudo chmod a+x /usr/local/bin/telepresence
## Install Telepresence Traffic Manager
RUN telepresence helm install
## Set-up interception
RUN telepresence connect -n default # change this to a specific namespace that you want to intercept
Commit and push and start a new Gitpod workspace.
Managing your existing Kubernetes clusters on Gitpod
Note: For this example, we use environment variables to configure the kubeconfig in this demo. However, we suggest you implement Workspace OIDC with a secrets manager as a best practice.
Head to Gitpod environment variables, and add a new variable named KUBECONFIG, paste your *kubeconfig* base64 format there. Here’s an example contributed by our community.
Let’s check that we are connected to our Kubernetes cluster and that we have all the resources running as expected.
bashkubectl get namespace, service, pod, deployment
NAME STATUS AGE
namespace/ambassador Active 108m
namespace/default Active 127m
namespace/kube-node-lease Active 127m
namespace/kube-public Active 127m
namespace/kube-system Active 127m
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/hello ClusterIP 10.100.104.128 <none> 80/TCP 8s
service/kubernetes ClusterIP 10.100.0.1 <none> 443/TCP 127m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/hello 1/1 1 1 13s
NAME READY STATUS RESTARTS AGE
pod/hello-5fc4649fb-5psqz 1/1 Running 0 13sSet-up Telepresence in your cluster
Installing the Traffic Manager
Let’s now check that the correct version of Telepresence has been installed. With the correct version of Telepresence confirmed, we’ll proceed to install the Traffic Manager into your cluster. Traffic Manager manages the connections and traffic routing for Telepresence, and resides in the ambassador namespace.
bashtelepresence version
OSS Client : v2.17.0
Root Daemon: not running
User Daemon: not runningWhen you intercept a resource, such as a pod, if you run kubectl describe pod <name> you should be able to see that the traffic-agent is installed there as well.
bashtraffic-config:
Type: ConfigMap (a volume populated by a ConfigMap)
Name: telepresence-agents
Optional: falseStart an interception
An interception should be ready to start when your Gitpod workspace spins up because of how we configured our .gitpod.Dockerfile. You can specify the namespace with -n flag in the Dockerfile if you have your resources in a specific namespace, otherwise Telepresence will look for resources in the default namespace.
bashLaunching Telepresence User Daemon
Launching Telepresence Root Daemon
Connected to context pawlean-dev@telepresence-demo.eu-west-1.eksctl.io, namespace default (https://F4417278B82BA14610BCFC45A2999BD8.yl4.eu-west-1.eks.amazonaws.com)
This connection will now allow outbound traffic to be routed to the cluster.You can now run the intercept action, in the example below, we are intercepting the pod named “hello” on port 9000. What this means is that we are redirecting traffic to the pod to our laptop/Gitpod workspace (inbound traffic.)
bashtelepresence intercept hello --port 9000 -- python3 -m http.server 9000
Using Deployment hello
Intercept name : hello
State : ACTIVE
Workload kind : Deployment
Destination : 127.0.0.1:9000
Volume Mount Error: sshfs is not installed on your local machine
Intercepting : all TCP connections
Serving HTTP on 0.0.0.0 port 9000 (http://0.0.0.0:9000/) ...
192.168.255.203 - - [29/Jan/2024 14:25:28] "GET /?vscodeBrowserReqId=1706538328288 HTTP/1.1" 200 -Note: The telepresence intercept configuration can also be automated in the Gitpod configuration if you already know which resource you want to intercept. Here’s how you could modify your Dockerfile to include this script:
yml## Start an interception
RUN telepresence intercept hello --port 9000 -- python3 -m http.server 9000Make changes to your application
With the connection set, navigate to your application code and make any desired changes. You should see these changes in real time, in your Gitpod workspace.
At any time, you can also run telepresence status for an overview of the connection.
bashtelepresence status
OSS User Daemon: Running
Version : v2.17.0
Executable : /usr/local/bin/telepresence
Install ID : 2d35ff41-9aac-45cb-bb1f-764278c4ea7c
Status : Connected
Kubernetes server : https://F4417278B82BA14610BCFC45A2999BD8.yl4.eu-west-1.eks.amazonaws.com
Kubernetes context: pawlean-dev@telepresence-demo.eu-west-1.eksctl.io
Connection name : pawlean-dev_telepresence-demo.eu-west-1.eksctl.io-default
Namespace : default
Manager namespace : ambassador
Intercepts : 0 total
OSS Root Daemon: Running
Version : v2.17.0
Version : v2.17.0
DNS :
Local IP : 1.1.1.1
Remote IP : 192.168.81.158
Exclude suffixes: [.com .io .net .org .ru]
Include suffixes: []
Timeout : 8s
Also Proxy : (0 subnets)
Never Proxy: (2 subnets)
- 34.243.119.246/32
- 34.242.117.145/32Kubernetes development doesn’t have to be difficult
With Telepresence, developers benefit from faster development loops without needing a super complex Kubernetes set-up. By adding Gitpod to the mix, you get a ready-to-use, automated, cloud development environment that further improves your developer experience (DevX).
Together, Telepresence and Gitpod make Kubernetes development smoother, faster, and more productive. They’re a powerful duo that simplifies your workflow and helps you get your software production-ready, faster.
Learn more about how to adopt Kubernetes in your organization without ruining your developer experience.
