Setting Up Service Profiles

Service profiles provide Linkerd additional information about a service. They work off the :authority or Host headers and can be used for internal services (web.default.svc.cluster.local) as well as external services (github.com). When an outgoing request matches a service profile’s Host, Linkerd will use that to provide per-route metrics, retries and timeouts. Incoming requests will match as well and are currently used for per-route metrics.

There are times when you may need to define a service profile for a service which resides in a namespace that you do not control. To accomplish this, simply create a service profile as before, but edit the namespace of the service profile to the namespace of the pod which is calling the service. When Linkerd proxies a request to a service, a service profile in the source namespace will take priority over a service profile in the destination namespace.

For a complete demo walkthrough, check out the books demo.

There are a couple different ways to use linkerd profile to create service profiles.

Requests which have been associated with a route will have a rt_route annotation. To manually verify if the requests are being associated correctly, run tap on your own deployment:

linkerd tap -o wide <target> | grep req

The output will stream the requests that deploy/webapp is receiving in real time. A sample is:

req id=0:1 proxy=in  src=10.1.3.76:57152 dst=10.1.3.74:7000 tls=disabled :method=POST :authority=webapp.default:7000 :path=/books/2878/edit src_res=deploy/traffic src_ns=foobar dst_res=deploy/webapp dst_ns=default rt_route=POST /books/{id}/edit

Conversely, if rt_route is not present, a request has not been associated with any route. Try running:

linkerd tap -o wide <target> | grep req | grep -v rt_route

Swagger

If you have an OpenAPI (Swagger) spec for your service, you can use the --open-api flag to generate a service profile from the OpenAPI spec file.

linkerd profile --open-api webapp.swagger webapp

This generates a service profile from the webapp.swagger OpenAPI spec file for the webapp service. The resulting service profile can be piped directly to kubectl apply and will be installed into the service’s namespace.

linkerd profile --open-api webapp.swagger webapp | kubectl apply -f -

Protobuf

If you have a protobuf format for your service, you can use the --proto flag to generate a service profile.

linkerd profile --proto web.proto web-svc

This generates a service profile from the web.proto format file for the web-svc service. The resulting service profile can be piped directly to kubectl apply and will be installed into the service’s namespace.

Auto-Creation

It is common to not have an OpenAPI spec or a protobuf format. You can also generate service profiles from watching live traffic. This is based off tap data and is a great way to understand what service profiles can do for you. To start this generation process, you can use the --tap flag:

linkerd profile -n emojivoto web-svc --tap deploy/web --tap-duration 10s

This generates a service profile from the traffic observed to deploy/web over the 10 seconds that this command is running. The resulting service profile can be piped directly to kubectl apply and will be installed into the service’s namespace.

Template

Alongside all the methods for automatically creating service profiles, you can get a template that allows you to add routes manually. To generate the template, run:

linkerd profile -n emjoivoto web-svc --template

This generates a service profile template with examples that can be manually updated. Once you’ve updated the service profile, use kubectl apply to get it installed into the service’s namespace on your cluster.