Integrating Istio Virtual Services with Telepresence

1

I work on a large project using Kubernetes. We will likely be moving towards using Istio in the future, but some other people are running that process.

Although I find Istio’s features for production use very intriguing, one thing that I’m particularly interested in pertains to how it could be used on a development cluster, with close collaboration with developers.

One thing that constantly frustrates me is that I see many developers on our project have to add extensive logging statements to their services, because it’s effectively impossible to step through the code in their services when their service is in the cluster, participating in complex flows. It is completely impossible to run the entire system on a laptop, to run the entire end-to-end test.

I’ve heard of a tool called “Telepresence”, that allows configuring a cluster so that when requests are sent to particular services, they are instead redirected “out of the cluster”, to a process running on a desktop. With this, a developer could set a breakpoint in their service code and step through the code, without having to guess at what log information they need.

This isn’t practical by itself, because lots of people share the development cluster. If I made the cluster redirect requests to our service to a single process running on my desktop, I would be flooded with calls.

What I really want is for a developer to be able to set a particular known cookie in the browser to a value “registered to that user”, so that when they execute an operation in the browser page pointing to the development cluster, all the requests to a particular service, that also have that cookie value, will be redirected to the process on my desktop.

From what little I’ve read about Istio, I think this “Virtual Service” thing might facilitate this idea of mine. The Virtual Service appears to have the ability to specify different conditions for when to redirect to different routes, and it seems like some of those conditions are values in the environment. I think it’s possible that a developer could somehow “register” their cookie value into a shared resource, so that everyone else testing the app in the browser will send all requests to the services in the cluster, but the one developer with this “registered” cookie value, when a request in the pipeline goes to a particular service, it will instead go to the desktop process.

Does this seem possible? Has anyone considered doing something like this? Has it already been done?

1 Like
2

Hi David,

I have done a very basic sample of the same idea, check this out if you’re interested

It’s far from perfect, and I’m not even using it myself right now.
But I’m hoping to develop a complete set of methods for my team soon, this shall be a good start

3

Glad to see someone is experimenting with this.

At this point, I’m only aware of the possibility of these two working in concert, but I haven’t examined the details. What I can’t quite figure out are the DNS implications of how this works. Is it the case that I have to run “kubectl apply” (for the yaml that references the “local” host) on the same host that I start telepresence on?

If my k8s server is a particular server host, and I want it to call my “ratings-local” service running on my laptop when it tries to call the “ratings” service, does this process you describe just work? The host reference to “ratings-local” in the yaml has to use binding set up by telepresence when it configures the k8s cluster. Is that what is happening here/

4

Swapping deployment worked out of the box for us. Note that our traffic policies are super open (but with strict mTLS).

e.g.:

telepresence --swap-deployment our-deployment --expose 8000:80
5

A little bit late to the party but we’ve been working on an open-source tool that provides a similar developer experience as telepresence but also leverages Istio features such as routing traffic to the clone of the service which is under development (but only for specific users, so the regular route stays untouched).

One of the strategies we have is based on telepresence.

You can check it out on GitHub

6

We build a project that with minimum changes can meet many companies needs
Changes mostly in what should be used for routing rule(x-user-email header in our case), exposed and tunelled ports add grpc/jdbc/… proxy support

It is quite trivial thing from high level

  1. deploy dcloud-bastion container in kuberenetes
  2. reverse ssh dcloud-bastion port to my localhost port
  3. port-forward my local to dcloud-bastion(it will route to any istio service)
  4. register microservice running locally(all about VirtualService)
    There exists full documentation how to validate this on localhost(ensure build locally docker images are accessible from kubernetes(use docker-desktop kubernetes cluster for demo)
    You can check it out on GitHub
    DCloud