Setting Up Service Profiles

Service profiles provide Linkerd additionalinformation about a service. They work off the :authority orHost 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 usethat to provide per-route metrics,retries andtimeouts. Incoming requests will match as welland are currently used for per-route metrics.

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

For a complete demo walkthrough, check out thebooks demo.

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

  • Swagger
  • Protobuf
  • Auto-Creation
  • TemplateRequests which have been associated with a route will have a rt_routeannotation. To manually verify if the requests are being associated correctly,run tap on your own deployment:
  1. linkerd tap -o wide <target> | grep req

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

  1. 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 rtroute is not present, a request has _not been associatedwith any route. Try running:

  1. 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 serviceprofile from the OpenAPI spec file.

  1. linkerd profile --open-api webapp.swagger webapp

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

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

Protobuf

If you have a protobuf formatfor your service, you can use the —proto flag to generate a service profile.

  1. linkerd profile --proto web.proto web-svc

This generates a service profile from the web.proto format file for theweb-svc service. The resulting service profile can be piped directly tokubectl 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 alsogenerate service profiles from watching live traffic. This is based off tap dataand is a great way to understand what service profiles can do for you. To startthis generation process, you can use the —tap flag:

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

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

Template

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

  1. linkerd profile -n emjoivoto web-svc --template

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