Setting Up Service Profiles

Service profiles provide Linkerd additionalinformation about a service and how to handle requests for a service.

When an HTTP (not HTTPS) request is received by a Linkerd proxy,the destination service of that request is identified. If aservice profile for that destination service exists, then thatservice profile is used toto provide per-route metrics,retries andtimeouts.

The destination service for a request is computed by selectingthe value of the first header to exist of, l5d-dst-override,:authority, and Host. The port component, if included andincluding the colon, is stripped. That value is mapped to the fullyqualified DNS name. When the destination service matches thename of a service profile in the namespace of the sender or thereceiver, Linkerd will use that to provide per-routemetrics,retries andtimeouts.

There are times when you may need to define a service profile fora service which resides in a namespace that you do not control. Toaccomplish this, simply create a service profile as before, butedit the namespace of the service profile to the namespace of thepod which is calling the service. When Linkerd proxies a requestto a service, a service profile in the source namespace will takepriority over a service profile in the destination namespace.

Your destination service may be a ExternalNameservice.In that case, use the spec.metadata.name and the`spec.metadata.namespace’ values to name your ServiceProfile. Forexample,

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: prod
spec:
  type: ExternalName
  externalName: my.database.example.com

use the name my-service.prod.svc.cluster.local for the ServiceProfile.

Note that at present, you cannot view statistics gathered for routesin this ServiceProfile in the web dashboard. You can get thestatistics using the CLI.

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
• Template

Requests 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:

linkerd tap -o wide <target> | grep req

The output will stream the requests that deploy/webapp is receiving in realtime. 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 rtroute is not present, a request has _not been associatedwith 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 serviceprofile from the OpenAPI spec file.

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.

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.

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:

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:

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.