Kubernetes is great for operations but ideally speaking, it’s not something developers should concern themselves about. In reality, apps developed for Kubernetes are different, because they interact with other services and could be stateful, both of which are tough to replicate in a local setup. Developers are used to the luxury of hot reloading and debugging to quickly test and improve the app. When it comes to developing apps for Kubernetes, the developer needs to build and push the container image to the registry and then update Kubernetes pod. After all the time consuming tasks, developers still can’t hot-reload and debug their apps directly.
Over time, there have been tools that help fasten the process of building the container image, automate the process of pushing to the registry, and update Kubernetes with the change. While these tools can be a great addition, they’re quite inadequate from a developer’s perspective. That is why I want to introduce you to Telepresence and how it can be used to improve the developer experience for Kubernetes apps being developed and debugged locally.
Telepresence is a lightweight development tool that can help you to debug and develop apps deployed to Kubernetes seamlessly. Basically, you could have a process running on your local system (without necessarily having to build containers) and telepresence will proxy all the requests back and forth from the cluster to that process. How does it do it?
It replaces your existing deployments with it’s own pod which runs a reverse-proxy that connects with our local system to forward and receive requests. This makes it possible for an app running locally to talk to other services which are running inside the Kubernetes cluster. You can find instructions on how to install Telepresence here.
Initially, there’s an existing deployment in the cluster which is running an API which returns “Hello World”. In this demo, I am going to replace the “Hello World” API deployed to Kubernetes with a process running locally that interacts with Kubernetes API to list the pods across namespaces with just one Telepresence command. Although I have interacted with Kubernetes API in this example, you could essentially interact with just about any other service.
As you can see, following the –run can be the command to run just about any binary on your local system which would run in context of Kubernetes, at least networking wise. In the demo, I had run the Uvicorn server.
Hopefully, this demonstrates how simple it can be to develop apps that need to interact with existing services deployed in Kubernetes. There might be times where you might want to forward requests to a container running locally, you can do that too with –docker-run instead of –run . Debugging and hot reloading apps in local containers can be done by VS Code’s Remote Development extension. You can also find language specific extensions, here’s one for Go.
You can find the code used in the above demo here.
There are couple of limitations as of now :
The following tools provide a way for in-cluster development which syncs with your local files. By going where the app resides, this solves both networking and storage issues for development.
Okteto: This is an absolutely amazing project but only the enterprise version lets you connect with your Kubernetes cluster. Otherwise, you’re limited to a small instance on their cloud.
Devspace: Devspace allows you to connect with your own Kubernetes cluster. In most cases, both of these projects may require a bit of configuration to be written but that’s a one time effort which might be worth it.
Telepresence is a network proxy that connects with your local system to help develop and debug apps in Kubernetes. A lot of projects are emerging in the space of development tools for Kubernetes. Telepresence is definitely on top of my list since it requires no configuration and simple to use.
Hope you enjoyed the blog post and found it helpful for getting started with developing and debugging your kubernetes applications locally using Telepresence. We’re curious to know which tools you have used and what you liked/disliked about them, let’s start a conversation on Twitter or Linkedin.