External profiles seem to be broken

007 commented 5 years ago

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 commented 5 years ago

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

olix0r commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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

vojtechvelkjop commented 2 months ago

@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 commented 2 months ago

@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.

linkerd / website