Setting Up Service Profiles

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

    The destination service for a request is computed by selecting the value of the first header to exist of, l5d-dst-override, :authority, and Host. The port component, if included and including the colon, is stripped. That value is mapped to the fully qualified DNS name. When the destination service matches the name of a service profile in the namespace of the sender or the receiver, Linkerd will use that to provide , retries and .

    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.

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

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

    For a complete demo walkthrough, check out the 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 annotation. To manually verify if the requests are being associated correctly, run tap on your own deployment:

    1. linkerd viz tap -o wide <target> | grep req

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

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

      1. 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 and will be installed into the service’s namespace.

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

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

      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.

      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:

      1. linkerd viz 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.

      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.