[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign kimwnasptd for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Please add a script in /hack
Do you know whether the architecture works? Where do you want to have the L7 proxies based in the discussion in #2676 ?

@peterj can you help here?

As per #2676, we could maybe focus on static namespaces for which a waypoint proxy would get created and we may need to configure a few stuffs. As for dynamic namespaces, I'm not sure if to proceed but as per @peterj we could just use sidecar mode before figuring out the L7 processing...

As per #2676, we could maybe focus on static namespaces for which a waypoint proxy would get created and we may need to configure a few stuffs. As for dynamic namespaces, I'm not sure if to proceed but as per @peterj we could just use sidecar mode before figuring out the L7 processing...

If we can run it in parallel, yes let's do so.

As I suggested in #2676, I think it would be safer to follow these steps first as a preparation for a move to ambient:

1. Migrate to Kubernetes Gateway API - this would involve installing K8s gateway API and replacing VirtualService resources with HTTPRoutes.
2. Move to the latest istio (1.22.3), continue with profile: default (or whichever was used).

After this, you could commence the move to ambient by identifying the components needing L7 proxies, deploying them and then moving to ambient (profile=ambient).

Yes, @juliusvonkohout should I migrate to Gateway API in this PR or make another one?

Yes, @juliusvonkohout should I migrate to Gateway API in this PR or make another one?

If it works also with the legacy and istio-cni i prefer a separate PR.

As I suggested in #2676, I think it would be safer to follow these steps first as a preparation for a move to ambient:

1. Migrate to Kubernetes Gateway API - this would involve installing K8s gateway API and replacing VirtualService resources with HTTPRoutes.

2. Move to the latest istio (1.22.3), continue with profile: default (or whichever was used).

After this, you could commence the move to ambient by identifying the components needing L7 proxies, deploying them and then moving to ambient (profile=ambient).

Yes lets do so. That means

1. in a separate PR the istio upgrade
2. Afterwards ina nother PR the k8s gateway API
3. adding the ambient option

Hey @biswajit-9776 @peterj, could you also add instructions in the description of the PR on how to also test this PR?

Hey @kimwnasptd thanks for hopping in, apologies from my side as I have been working on PSS workflows since last week.
As for the testing of this PR, the pipelines and m2m tests in our present workflow need to be modified for Istio using ambient profile.
Istio with ambient profile doesn't use the ingress gateway and would be using the Kubernetes Gateway API. So, the port forwarding tests in current github workflows need to be modified accordingly and I will post the findings in my local system accordingly.