8000 Support for ingress-use-waypoint · Issue #8338 · kiali/kiali · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Support for ingress-use-waypoint #8338

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Tracked by #8250
josunect opened this issue Apr 16, 2025 · 3 comments · May be fixed by #8439
Open
Tracked by #8250

Support for ingress-use-waypoint #8338

josunect opened this issue Apr 16, 2025 · 3 comments · May be fixed by #8439
Assignees
Labels
enhancement This is the preferred way to describe new end-to-end features.

Comments

@josunect
Copy link
Contributor
josunect commented Apr 16, 2025

What do you want to improve?

Using the label istio.io/ingress-use-waypoint=true on a service, the gateway generates L7 telemetry for a waypoint proxy.
In this case, this is not identified as a waypoint proxy.
The graph in bookinfo, labeling the productpage service, looks like this:
kubectl label service productpage -n bookinfo istio.io/ingress-use-waypoint=true

Image

See: https://ambientmesh.io/docs/traffic/gateways/#gateways-and-waypoints

What is the current behavior?

What is the new behavior?

Maybe there would be some way to improve the graph when using this label.
Should be the waypoint proxies recognized as waypoints here as well?

Epic: #8250

@josunect josunect added the enhancement This is the preferred way to describe new end-to-end features. label Apr 16, 2025
@jshaughn
Copy link
Collaborator

Using the label istio.io/ingress-use-waypoint=true on a service, the gateway routes generates L7 telemetry for a waypoint proxy.

According to JohnH in Slack, ingress is sort of "Application+Ztunnel" bundled into one . So we wouldn't expect any ztunnel telem here. The gateway directs the traffic directly to the waypoint assigned to the service and generates typical source telemetry for that hop, it could be HTTP or TCP, depending on the request.

Here is an initial idea of what we could do here:

  • If ShowWaypoints is disabled:
    • continue to show this traffic because in this case the waypoint is not embedded in an all-ambient flow
      • this visualizes the special handling based on the istio.io/ingress-use-waypoint=true label
      • as suggested by Josune, the node should be badged as a waypoint
  • If ShowWaypoints is enabled:
    • don't show two instances of the same waypoint
      • merge this waypoint node into our "injected" waypoint node.

@jshaughn jshaughn added the refinement Still being full defined before taking any action label Apr 16, 2025
@josunect
Copy link
Contributor Author

Using the label istio.io/ingress-use-waypoint=true on a service, the gateway routes generates L7 telemetry for a waypoint proxy.

According to JohnH in Slack, ingress is sort of "Application+Ztunnel" bundled into one . So we wouldn't expect any ztunnel telem here. The gateway directs the traffic directly to the waypoint assigned to the service and generates typical source telemetry for that hop, it could be HTTP or TCP, depending on the request.

Here is an initial idea of what we could do here:

* If `ShowWaypoints` is disabled:
  
  * continue to show this traffic because in this case the waypoint is not embedded in an all-ambient flow
    
    * this visualizes the special handling based on the `istio.io/ingress-use-waypoint=true` label
    * as suggested by Josune, the node should be badged as a waypoint

I'm agree.

* If `ShowWaypoints` is enabled:
  
  * don't show two instances of the same waypoint
    
    * merge this waypoint node into our "injected" waypoint node.

I think the main challenge here would be deciding how to visualize this node, because in the case of the ztunnel telemetry it is shown as a workload, but in the L7 telemetry it is shown as an application.

@jshaughn jshaughn removed the refinement Still being full defined before taking any action label Apr 28, 2025
@josunect josunect self-assigned this May 19, 2025
@josunect josunect moved this from 📋 Backlog to 🏗 In progress in Kiali Sprint 25-08 | Kiali v2.11 May 19, 2025
@jshaughn
Copy link
Collaborator
jshaughn commented May 19, 2025

@josunect After thinking more, I think I'm going to change my opinion. I don't think we should show the waypoint node unless Show Waypoints is enabled. I think it's confusing to have waypoints show up, even for this different use case, when the option is disabled.

Assuming we hide all waypoint nodes when Show Waypoints is disabled, we could still add something to a gateway node if it has istio.io/ingress-use-waypoint=true. We could add a decorator, similar to what we do for a virtual service:

Image

That would indicate that this gateway is directing traffic directly to a waypoint, without actually showing a waypoint node.

If Show Waypoints is enabled, we should add in the edges.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement This is the preferred way to describe new end-to-end features.
Projects
Status: 🏗 In progress
Development

Successfully merging a pull request may close this issue.

2 participants
0