Skip to content
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

docs(MADR): meshexternalservice routed through the specific zone #11853

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
change label
Signed-off-by: Lukasz Dziedziak <lukidzi@gmail.com>
lukidzi committed Oct 25, 2024
commit ba32b227002c7ff5e3618b6e011b1d7edaa30618
16 changes: 9 additions & 7 deletions docs/madr/decisions/062-meshexternalservice-through-zone.md
Original file line number Diff line number Diff line change
@@ -17,8 +17,8 @@ Another relevant scenario is when only the Zone Egress in a particular zone is a
* Create `MeshExternalService` on a Zone.
The `MeshExternalService` would be created in a zone and exposed similarly to how `MeshService` is synced across zones.

* Add a Label
Introduce a label like `kuma.io/accessible-zone` (to determine the best name) to restrict external access to a specific zone.
* Add a label `kuma.io/zone` to `MeshExternalService` created on the global
Create `MeshExternalService` on a global with a label `kuma.io/zone`

## Decision Outcome

@@ -86,7 +86,7 @@ The traffic flow in this case is simpler:
* Adds complexity to the flow.
* Every `MeshExternalService` created in a zone is exposed via Zone Ingress.

### Add a label
### Add a label `kuma.io/zone` to `MeshExternalService` created on the global

In this approach, the user must explicitly provide information during resource creation. The resource can only be created on the global control-plane.

@@ -95,7 +95,8 @@ type: MeshExternalService
name: mes-through-zone-1
mesh: default
labels:
kuma.io/accessible-zone: zone-1
kuma.io/origin: global
kuma.io/zone: zone-1
spec:
match:
type: HostnameGenerator
@@ -106,13 +107,14 @@ spec:
port: 80
```

Once the resource is synced, the control-plane uses the `kuma.io/accessible-zone` label to generate configurations. This configuration directs all zones—except the one specified by the label's value—to use the ingress of the specified zone.
Once the resource is synced, the control-plane uses the `kuma.io/zone` label to generate configurations. Traffic from all zones different than one in a resource is going to be routed trhough this zone, and leaves the cluster from Zone Egress of zone in the resource

It's not possible to validate the zone name during resource creation, but we could log a message indicating there is no zone with the provided name. However, this is not an ideal solution.
It's not possible to validate the zone name during resource creation, but we could log a message indicating there is no zone with the provided name.
Additionally, creating a resource with both `kuma.io/origin: zone` and `kuma.io/zone` labels would not be allowed. This restriction helps ensure a clear separation between resources originating in specific zones and those configured globally, preventing potential errors.

#### Advantages:
* There's no need to expose all `MeshExternalServices` created in the zone on the ingress.
* No need to sync `MeshExternalServices` from origin zone to other zones

#### Disadvantages:
* Requires managing an additional label.
* Additional logic is needed to handle the label.