Skip to content

separate public and private domains, allow to choose for stacks #698

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

linki
Copy link
Member

@linki linki commented Jul 7, 2025

Alternative for #696 so we can compare what the difference is.

It introduces two more flags and should be fully backwards compatible. The first new flag --cluster-internal-domain works similar to --cluster-domain but tells stackset-controller that it's an internal domain (e.g. ingress.cluster.local). By default external and internal domains are both processed (like today) so there's no change when moving a domain from --cluster-domain to --cluster-internal-domain.

However, the second flag --ignore-public-domains-on-stacks can be used to tell stackset-controller to not use public domains for stack hosts. So, once the domains have been split into two separate groups, this flag can be used to change the behaviour.

Below is the intended usage. The first example is the setup on current clusters, the second one will be the setup on legacy clusters and the third one will be the setup for EKS clusters (only difference is the value of the flag).

Imagine a stackset specifying the following ingress section:

spec:
  ingress:
    hosts:
    - my-app.teapot.zalan.do
    - my-app.ingress.cluster.local

Running stackset-controller with the following configuration will result in the following:

--cluster-domain teapot.zalan.do --cluster-domain ingress.cluster.local (current setting)

main ingress stack ingress
my-app.teapot.zalan.do my-app.ingress.cluster.local my-app-v1.teapot.zalan.do my-app-v1.ingress.cluster.local

That's the current result and backwards compatible.

Then, split cluster domains into a public and private group. There's no change and therefore backwards compatible.

--cluster-domain teapot.zalan.do --cluster-internal-domain ingress.cluster.local (future setting for legacy clusters)

main ingress stack ingress
my-app.teapot.zalan.do my-app.ingress.cluster.local my-app-v1.teapot.zalan.do my-app-v1.ingress.cluster.local

Finally, switch the flip on EKS clusters to skip public domains on Stacks.

--cluster-domain teapot.zalan.do --cluster-internal-domain ingress.cluster.local --ignore-public-domains-on-stacks (future setting for EKS clusters)

main ingress stack ingress
my-app.teapot.zalan.do my-app.ingress.cluster.local my-app-v1.ingress.cluster.local

The idea is to run with the public/private split and without --ignore-public-domains-on-stacks (false) on legacy clusters. On EKS clusters we would run it with --ignore-public-domains-on-stacks.

If the Stackset doesn't make use of the ingress.cluster.local domain in its definition, then the results above are the same but with the internal domain (i.e. just the teapot.zalan.do DNS names and no DNS name at all for the stack on EKS).

@linki linki added the minor label Jul 7, 2025
@@ -64,7 +64,9 @@ type StackSetContainer struct {

// clusterDomains stores the main domain names of the cluster;
// per-stack ingress hostnames are not generated for names outside of them
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like "per-stack" is already somewhat supported. I'm getting quite the same (correct) results on the master branch when running with: --cluster-domain ingress.cluster.local. Maybe worth looking into if that already solves our problem.

image

Copy link
Member

@demonCoder95 demonCoder95 Jul 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we define only the --cluster-domain ingress.cluster.local then we will indeed get the correct behavior as you point out. If we have multiple domains, then of course the per-stack domains generated will be multiple, like you also describe in the PR description.

@linki linki force-pushed the internal-domains branch from 384b272 to 2cfc7c1 Compare July 9, 2025 13:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants