TELEPRESENCE 2

What’s New in Telepresence 2?

Faster, more powerful Kubernetes development teams powered by Telepresence 2

In May 2018, the Ambassador Labs team donated Telepresence to the Cloud Native Computing Foundation (CNCF) to give the fast-moving Kubernetes community more efficient development workflows so they could code faster. The early versions of Telepresence emphasized fast, local development for single Kubernetes developers working on services.

Over the years since Telepresence’s initial release, however, we’ve learned that cloud-native developers rarely work in silos. Development teams need to be able to iterate on services rapidly without disrupting their teammates or other teams. We learned that many Telepresence power users were building their own custom solutions to make Telepresence work for multiple users. These homegrown solutions often worked well until the team’s application scaled. They quickly became hard to maintain as applications grew more complex and team’s got bigger.

It’s our belief that tools should scale with your team, not create so much maintenance work that they slow you down. Over the last few months we’ve been iterating rapidly on a next-generation Telepresence 2 client. Rewritten in Go, Telepresence 2 is:

• Architected for multiple users
• Faster to startup
• Is more reliable, with support for features such as re-connects
• Supports VPNs

In this article, we’ll walk through what’s new in Telepresence 2, talk about the architecture decisions we made when building Telepresence 2 and how it compares to the original Telepresence, and help you get started using it to intercept your own services.

Super Efficient Kubernetes Development Teams with Telepresence 2

Telepresence was originally built around the concept of “swapping deployments”, where we would sneakily substitute a Telepresence proxy pod in place of your actual deployment. This was a simple abstraction that our users quickly understood and found very useful.

With Telepresence 2, we’re introducing intercepts, which provide for far greater flexibility in using Telepresence. Intercepts are routing rules. To replicate the swap deployment behavior, create an intercept that routes all traffic intended for a pod to a laptop instead. But because intercepts are routing rules, you’re not limited to a “route all” semantic. You can create an intercept that routes some of the traffic to your laptop based on, for example, a JWT token passed in the HTTP header.

Intercepts unlock a new set of possibilities for Telepresence:

• Reduce development compute costs. Share a single common cluster with your team while enabling each developer to have their own sandbox built on selective intercepts.
• Live debugging in production. Route test traffic based on a selective intercept to your laptop, while real production traffic is not impacted.

Learn more about intercepts in the documentation:

• How To: Intercept a Service
• Technical Reference: Intercepts

Preview URLs for fast collaboration

Have you ever spent more time reproducing a teammates’ bug than actually fixing their issue? Telepresence 2 integrates seamlessly with Ambassador Cloud to automatically generate preview URLs for intercepted services. Developers can then Slack the preview URL to a teammate so they can easily access the version of the service running on their teammates machine. They can then recreate the bug they’re experiencing on their teammates’ local machine. The developer can set a breakpoint, watch their teammate hit the bug, fix the bug, and their teammate can see the results of the fix immediately. Sound too good to be true? Read the documentation or see it in action:

A New Architecture for a Faster, More Reliable Telepresence

As Telepresence gained adoption, we incrementally added features in response to different use cases. Over time, we realized that the core architecture of Telepresence limited our ability to address certain scenarios. There were two major feature requests we kept on hearing:

1. Telepresence is great, but how do you use it for multi-user environments?
2. Telepresence is great, but how can we improve its reliability and performance?

We experimented with incremental changes to Telepresence, and then decided (after a long prototyping phase) that a new architecture was the best path forward. With Telepresence 2, we address these two core use cases, and then some. Now, with Telepresence 2:

• We split the monolithic proxy in Telepresence 1 into two components, the traffic agent and traffic manager.
• The traffic manager is a persistent proxy that always runs in your cluster. This improves performance (you don’t need to redeploy it every time) and reliability (there’s a persistent process to connect to).
• The traffic agent is a sidecar injected onto the service, which lets us do more intelligent routing, supporting multi-user cases.
• Is written purely in Go, taking advantage of the broader ecosystem of Kubernetes/Go libraries, versus Python.

You can read more about the new architecture in the documentation.

Telepresence 2 Availability

Telepresence 2 is open source and available now. To get up and running faster, try the Telepresence 2 quickstart and intercept a demo service from our sample application in the following languages:

• Go
• NodeJS
• Python (Flask)
• Python (FastAPI)
• Java
• …and of course it works with your other favorite language too!

If you’re ready to get started intercepting one of your own services in your own cluster, create your first intercept now!

Upgrading to Telepresence 2

If you’re an existing Telepresence user, we recommend upgrading to the latest version for increased speed and reliability, especially if you’re using Telepresence in a team setting. The following features from Telepresence 1 are not yet currently supported by Telepresence 2:

• Running Telepresence in container mode (although you may not need container mode; you can run multiple intercepts to the same service)
• mTLS support (i.e., intercepting services that only communicate over TLS) is planned but not yet available

We will reach feature parity between Telepresence 1 and Telepresence 2 in time for KubeCon EU. At that time, Telepresence 2 will become the default version of Telepresence, so we recommend upgrading as soon as possible to share your feedback! Join our community on Slack to ask questions, meet other users, and share your thoughts on Telepresence 2 with our team.

We’ve created a special upgrade guide for users that are upgrading from Telepresence 1 to Telepresence 2 with additional resources on the new Telepresence architecture. Give it a try and be sure to tell us how it goes!