istio
Waypoint Extensions
(This is used to request new product features, please visit https://discuss.istio.io for questions on using Istio)
Describe the feature request
As part of the work to allow for vendors to create their own waypoint implementations we're going to need a mechanism to configure which GatewayClass.gateway.networking.k8s.io Istiod should consider waypoints. Present proposal is to use mechConfig
Describe alternatives you've considered
Using label selection ambient.istio.io/waypoint: true on the GatewayClass or Gateway Resources
Affected product area (please put an X in all that apply)
[ ] Configuration Infrastructure [ ] Docs [ ] Installation [X] Networking [ ] Performance and Scalability [ ] Policies and Telemetry [ ] Security [ ] Test and Release [ ] User Experience
Additional context Istio’s Layered Future, Policy and Conformance
Can we discuss this further before execution? I think we can use 100% standard Gateway API with no custom annotations with some tweaks. I will present in WG wednesday.
threw out a quick PR with a meshConfig update, we can just close if there's a better direction
(updated PR to be WIP)
@hzxuzhonghu, I'm not sure I understand your proposal. Do you propose there should be some convention used in this field to identify controllers outside of istiod which have configured waypoint proxies?
I mean user can do any customization deploying of waypoint based on ControllerName. For istio, istiod gateway deployment controller will handle it. Maybe i misunderstand your use case
This was meant to provide a way for non-istio waypoints to be discovered in the mesh. If you've got controller-x which configures a waypoint for some namespace/SA but istiod/ztunnel aren't aware that it's a waypoint (vs it being any other implementation of kube gateways) we won't send traffic to it and it won't be enforcing any policy.
Edit, I added a link to the doc which provides background in the Additional Context section above.