Conduit-Linker2 inject proxy with routing rules



I’m starting with service mesh using conduit (now linkerd2).
When I inject a new microservice is it possible configure routing rules to the sidecar proxy? This is in order to make a routing to call another microservice depending output value of current service.

Thanks in advance!


Hey @simonts, glad to hear you’re getting up and running with linkerd2.

Can you elaborate a bit more on your routing use case? We don’t configure routing on a per-sidecar basis. Each of the sidecars establishes a connection back to the linkerd2 control plane, which provides each proxy with the set of addresses that are available for routing. The address set is dictated by the Kubernetes endpoints and service APIs.

What you’re describing sounds like application-specific logic. Maybe it would be better to configure your application to inspect the response and make follow-up requests?


Hello @klingerf, thanks for your answer!

I try to make a simple example with services mesh.
I have three microservices to access an application.

The login service receives the username and password and returns a json:

“jti”: “id123456”/null,
“type”: “user”/“admin”/null

The smalltoken service receives the username and returns a json:

“token”: “WKASEDSX…”/null,
“exp”: 1407019629/null

The longtoken service receives the username and returns a json:

“token”: “abWdKsAdSFeEeDtStXt…”/null,
“exp”: 1409999999/null

The scenario is the following:
An application makes a request to the service login in the service grid.
In the proxy of the service, the address of the login service is called
If the user type returned by the login service is “user”, the smalltoken service is called
If the user type returned by the login service is “admin”, the longtoken service is called

Is it possible to set this business rules in the proxy (routing rules)? Can this be done in the .yml file when the service is injected?

Sorry for my extensive question.

Thanks in advance!


Hey @simonts – I don’t think that proxy sidecar is the best place to put this logic. It sounds pretty application-specific, so I’d recommend putting it in the calling application itself. Or you could create an intermediary application that does this for you. Something like:

application => login handler => login service
                             <= token
                  user token => small token service
                 admin token => large token service

You’d still need to write login handler and run it as a separate service. That said, you could use linkerd to connect all of your applications to the login handler and to connect the login handler to the login service, small token service, and large token service.

Hopefully that’s helpful, and apologies if I’m not quite understanding your use case.


Hello @klingerf, thanks for the explanation.

Sorry, I thought that in the control plane the communication between the microservices for scenarios could be orchestrated with conditional rules.

That intermediate application that you suggest, can it be a microservice (orchestrator) that internally calls the other microservices for the condition described in the scenario?

This “microservice orchestrator” can be registered in the service mesh by injecting it into its own yml file?

Once registered in the service network, will this ensure that the communication between the “microservice orchestrator” and the microservices is in the internal network of the service mesh network to minimize the response time?

Thanks in advance :sunny: !


Hey @simonts, that all sounds correct to me. The basic idea is that in a microservices architecture that uses linkerd, it should be trivial to add new services. So in your case it sounds like you need a relatively small but specialized application for routing login traffic, and I’d recommend setting that up as a separate service in your architecture.


It is very helpfull. Thanks a lot!