docs(MADR): meshexternalservice routed through the specific zone

[lukidzi]

Motivation

There is a use case where a service is not part of the mesh and is only accessible or resolvable within a single Datacenter (DC). Without the proposed functionality, there is no way to expose this service to other zones.

Implementation information

MADR https://docs.google.com/document/d/12YrUy-kV3JZu9K4tSv6V6q4Dx8v7mp41_SdxJ0kQ_tc/edit?tab=t.0#heading=h.n6cmlf1eel2z

Supporting documentation

part of #11071

[jijiechen]

I would prefer creating the resource on global CP with a label.

Because when we ask the user to create a resource in the zone, it implies the resource is "owned/maintained" by the zone. But this is not the case here.

Zones are phsically located at different clusters/places, so they may have very different permissions when considering the underlying Kubernetes/VM cluster. However, an external service that is only accessible through a zone does not belong to the zone. When the mesh admin/operator decides to open this accessiblity to other zones in the mesh, the responsibility of managing/maintaining this relationship with the external service should be shared by the whole mesh. So the MeshExternalService should be shown/managed through the global CP.

Let me raise an example scenario:

When the external service fails because of the IP address had been changed by it owner and the consumers within the mesh just found it. So they want to correct the address in MeshExternalService defined in the mesh.

In this case, I think they should go to the global CP admin, instead of the zone admin.

It's slightly different than the MeshService case. MeshServices are normally generated automatically and it originates from the Service objects on a Kubernetes cluster.

So it's reaonable for MeshServices to be "owned" by zones, because:

1. They originate from Services, which are owned by zones
2. People don't need to manage/maintain MeshServices directly, so the operational cost is low

[lukidzi]

That makes sense I can agree with most of this. I have another use case that could involve a dedicated database team maintaining a cluster independently. In this scenario, permissions for exposing services from other zones would be managed by the Mesh Operator, while the database team could handle the creation and maintenance of MeshExternalService resources. This setup would provide flexibility, allowing the database team to manage their resources without impacting broader mesh configurations.

[lukidzi]

I am going to move it to the google docs

[slonka]

@lukidzi I feel like there is nothing to add more from my side but there are some discussions that are not closed. Should we create a meeting and talk through them?

[github-actions]

Reviewer Checklist

🔍 Each of these sections need to be checked by the reviewer of the PR 🔍:
If something doesn't apply please check the box and add a justification if the reason is non obvious.

• Is the PR title satisfactory? Is this part of a larger feature and should be grouped using > Changelog?
• PR description is clear and complete. It Links to relevant issue as well as docs and UI issues
• This will not break child repos: it doesn't hardcode values (.e.g "kumahq" as an image registry)
• IPv6 is taken into account (.e.g: no string concatenation of host port)
• Tests (Unit test, E2E tests, manual test on universal and k8s)
  • Don't forget ci/ labels to run additional/fewer tests
• Does this contain a change that needs to be notified to users? In this case, UPGRADE.md should be updated.
• Does it need to be backported according to the backporting policy? (this GH action will add "backport" label based on these file globs, if you want to prevent it from adding the "backport" label use no-backport-autolabel label)