External profiles seem to be broken

[007]

Bug Report

What is the issue?

External profile support seems to be broken (or just finicky), per debugging comments from @adleong

How can it be reproduced?

Create a service profile like:

---
apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: myapp.NAMESPACE.svc.cluster.local
  namespace: NAMESPACE
spec:
  routes:
  - condition:
      method: GET
      pathRegex: /api/foo/.*
    name: GET /foo
  - condition:
      method: GET
      pathRegex: /api/bar/.*
    name: GET /bar

Add annotation on myapp deployment:

config.linkerd.io/enable-external-profiles: "true"

Access the service via an external URL, i.e. blah.example.com/api/foo

Logs, error output, etc

The authority of the requests is blah.example.com, and those requests don't have any route assigned. Internal requests (from within the cluster) to myapp work and show in routes as expected.

linkerd check output

All green checks

Environment

• Kubernetes Version: 1.13
• Cluster Environment: EKS
• Host OS: EKS
• Linkerd version: 2.5

Possible solution

Tried setting service profile name to blah.example.com as requested, but that doesn't seem to make a difference for metrics, and doesn't show up in /namespaces/NAMESPACE/deployments/myapp on the dashboard.

Additional context

https://linkerd.slack.com/archives/C89RTCWJF/p1567199653273600 has a bunch of debugging steps and context

[grampelberg]

I thought we fixed this when you set the l5d-dst-override header...

[olix0r]

Thanks @007 🕵️‍♂️! Are you able to use linkerd tap to inspect requests in this pod? If so, what :authority value is emitted for these requests? Alternatively, can you share the proxy's metrics from this pod via linkerd metrics -n NAMESPACE po/POD?

[olix0r]

@grampelberg

I thought we fixed this when you set the l5d-dst-override header...

i'm missing context... where is this header supposed to be used?

[grampelberg]

I'm pattern matching (someone please correct me if I'm wrong), but this sounds like external user -> ingress controller -> internal service where the external is referencing blah.example.com. For this example, having the ingress controller add the l5d-dst-override header should make the provided service profile work. I think the per-route metrics doc actually talks about this ...

[olix0r]

@007 I believe that we worked through this issue on slack by disabling external profiles and configuring the override header. Are there any remaining questions or should we close out this issue?

[007]

Error is fixed. I'm not sure if this should be changed to "make this discoverable in docs", or if that should be a separate GH issue.

[grampelberg]

I'll move it over to the website repo, thanks!

[vojtechvelkjop]

@007 could you advise me how it was solved ? I have same problem but we dont use ingess (controller) so F5->i nternal ip of service -> pod thanks

[007]

@007 could you advise me how it was solved ? I have same problem but we dont use ingess (controller) so F5->i nternal ip of service -> pod thanks

Absolutely no idea - it's been ~5 years and 10 versions since then, my memory isn't that good.