Dynamic ZoneDelegations

[k0da]

..

HOW TO RUN CI

---

By default, all the checks will be run automatically. Furthermore, when changing website-related stuff, the preview will be generated by the netlify bot.

Heavy tests

Add the heavy-tests label on this PR if you want full-blown tests that include more than 2-cluster scenarios.

Debug tests

If the test suite is failing for you, you may want to try triggering Re-run all jobs (top right) with debug logging enabled. It will also make the print debug action more verbose.

[k0da]

@ytsarev Documentation added

[k0da]

@donovanmuller Updated documentation with pursued use case

[k0da]

@ytsarev it is backed by feature flag. And be enabled on explicit request. It is not meant to change default k8gb behavior.

[ytsarev]

@k0da feature flag is great, we still need more detailed documentation for substantial changes in the codebase. We can work on the docs together when I return from Atlanta 👍

[sudhamshk]

Hi @k0da

I tested the Dynamic Zones feature with the following setup:

Clusters: cluster1, cluster2, cluster3

ZoneDelegation:

parentZone: app.example.com
loadBalancedZone: gslb.app.example.com

Application placement: app1 → cluster1 and cluster2 app2 → cluster2 and cluster3

With Dynamic Zones enabled, the expectation I was having was that each cluster would only serve the zones it participates in.

Observed behaviour:

app1.gslb.app.example.com

• resolves correctly when NS points to cluster1 or cluster2
• returns NXDOMAIN when NS points to cluster3, since cluster3 does not host the Gslb for app1

app2.gslb.app.example.com

• resolves correctly when NS points to cluster2 or cluster3
• returns NXDOMAIN when NS points to cluster1, since cluster1 does not host the Gslb for app2

I think to match how Dynamic Zones is designed, each app (or service) needs its own delegated sub-zone. That way, only the clusters hosting that app receive NS delegation, and clusters that don’t host it won’t return NXDOMAIN.

[k0da]

Hi @k0da

I tested the Dynamic Zones feature with the following setup:

Clusters: cluster1, cluster2, cluster3

ZoneDelegation:

parentZone: app.example.com
loadBalancedZone: gslb.app.example.com

Application placement: app1 → cluster1 and cluster2 app2 → cluster2 and cluster3

With Dynamic Zones enabled, the expectation I was having was that each cluster would only serve the zones it participates in.

Observed behaviour:

app1.gslb.app.example.com

* resolves correctly when NS points to cluster1 or cluster2

* returns NXDOMAIN when NS points to cluster3, since cluster3 does not host the Gslb for app1

app2.gslb.app.example.com

* resolves correctly when NS points to cluster2 or cluster3

* returns NXDOMAIN when NS points to cluster1, since cluster1 does not host the Gslb for app2

I think to match how Dynamic Zones is designed, each app (or service) needs its own delegated sub-zone. That way, only the clusters hosting that app receive NS delegation, and clusters that don’t host it won’t return NXDOMAIN.

yes. That the intent. A team who deploys app to a particular cluster brings delegation along with the app. So cluster which have ZoneDelegation have app, be healthy or unhealthy but it would have gslb resource to participate into app queries.

Our internal setup works in a way a team owns subdomain exclusively and not shared with the other teams