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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default bastion public DNS name should be generated from dns zone #1322

Closed
itskingori opened this Issue Jan 3, 2017 · 6 comments

Comments

Projects
None yet
2 participants
@itskingori
Copy link
Member

itskingori commented Jan 3, 2017

Some context:

We now have this 馃憞馃徑 ... which builds the DNS entry name for the bastion ...

// Default to a DNS name for the bastion
cluster.Spec.Topology.Bastion = &api.BastionSpec{
    BastionPublicName: "bastion-" + clusterName,
}

... but with kops, if you don't specify a dns-zone, kops will ...

... list all your hosted zones, and choose the longest that is a a suffix of your cluster name. So for dev.kubernetes.example.com, if you have kubernetes.example.com, example.com and somethingelse.example.com, it would choose kubernetes.example.com. example.com matches but is shorter; somethingelse.example.com is not a suffix-match.

... so we can see that with kops the expectation is that the pattern is something like --name=dev.kubernetes.example.com and --dns-zone=kubernetes.example.com. Or at least that's what the docs say and probably what most people will follow.

The problem I'm having:

I kinda deviated a bit. My cluster name is not a subdomain of dns-zone. So ... let's say I want to have a cluster set to kubernetes.example.com and set my DNS zone to kubernetes.example.com ... then I do something like this:

$ kops create cluster \
  --name=kubernetes.example.com \
  --bastion=true \
  --cloud=aws \
  --dns-zone=kubernetes.example.com \
  --out=. \
  --target=terraform \
  --topology=private \
  ...
$ terraform apply

... then I get this error ...

[ERR]: Error building changeset: InvalidChangeBatch: RRSet with DNS
name bastion-kubernetes.example.com. is not permitted in zone
kubernetes.example.com.

What I think:

  1. I'm wondering if we should be building the DNS entry from dns-zone which is really the name of the hosted zone that kops will use?
  2. The cluster name could be anything really, the only part of it we are guaranteed of is it's suffix i.e. dns-zone.
  3. And ... this i.e. the hosted zone, is probably where most people would like the bastion's DNS entry to be in?
  4. Seems more appropriate for the bastion DNS entry to be a subdomain in the dns-zone hosted zone.

IMHO.

@itskingori

This comment has been minimized.

Copy link
Member

itskingori commented Jan 3, 2017

@justinsb

This comment has been minimized.

Copy link
Member

justinsb commented Jan 3, 2017

What do you think @kris-nova? bastion.<clustername> actually feels more natural to me - just like we have api.<clustername>

@justinsb justinsb modified the milestone: 1.5.0 Jan 3, 2017

@itskingori

This comment has been minimized.

Copy link
Member

itskingori commented Jan 3, 2017

... bastion.<clustername> actually feels more natural to me - just like we have api.<clustername>

I'd like to take it a step further and suggest we use <dns-zone> as the suffix instead of <clustername>.

<clustername> is by default assumed to be a sub-domain in <dns-zone> (unless you override that behaviour by setting --dns-zone) since kops chooses the longest that is a suffix of your cluster name.

I haven't got that working quite yet though but I think I can figure it out with some help.

@justinsb

This comment has been minimized.

Copy link
Member

justinsb commented Jan 9, 2017

I'd like to take it a step further and suggest we use as the suffix instead of .

I don't really understand why? dns-zone is an identifier for your hosted zone, so it could be example.com or even an ID like ABCDEFG123 or maybe in future something like dyndns://accountid/zoneid. We don't want to use dns-zone when it is an ID. But we also don't want to use it when it is a suffix, or else if we have two clusters cluster1.example.com and cluster2.example.com, we might end up with both bastions as bastion.example.com

@justinsb justinsb reopened this Jan 9, 2017

@itskingori

This comment has been minimized.

Copy link
Member

itskingori commented Jan 9, 2017

@justinsb ...

We don't want to use dns-zone when it is an ID. But we also don't want to use it when it is a suffix, or else if we have two clusters cluster1.example.com and cluster2.example.com, we might end up with both bastions as bastion.example.com.

Ok. I see your point. 馃

@itskingori

This comment has been minimized.

Copy link
Member

itskingori commented Jan 9, 2017

#1364 by @kris-nova fixes the error I was getting here and new docs on bastion show you how to change it to bastion.<clustername> ... which is what I wanted so no longer an issue.

@itskingori itskingori closed this Jan 9, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment