Feature request: Add --master-public-name as a parameter to kops

[mdavidsen]

Hi,

In order to get going without the requirement for external DNS, i could't find a way that would not break the initial certificates generated.

Challenge:

I'm trying to deploy kubernetes to AWS, but can't use Route53 (for reasons).
I also have to use the Terraform.

In order to use Gossip (meeting the requirement of no Route53), we have to append k8s.local to the cluster name. This again causes issues with certificates, as the api-server only have a certificate that's valid for api.my-k8s.deployment.com.k8s.local.

This results in us having to either:

• Generate a new certificate for the master/api role and update the state store before initializing the cluster in order to support the api.my-k8s.deployment.com
• Ignore certificate checks.

Current version

In order to meet the requirement regarding Route53:

./kops create cluster\
  --name=$CLUSTER_NAME.k8s.local\
  --dns-zone=$CLUSTER_NAME\
  --dns=private\
  --out=./terraform/\
  --target=terraform\
  --zones us-east-2a\
  --state=$KOPS_STATE_STORE\
  --cloud=aws

One way we could solve this, is to run kops edit cluster and change the master-public-name (remove the k8s.local part). But, when you run kops update cluster the certificates involved does not get updated, so we are back to scratch.

Proposed solution

Add --master-public-name as optional argument to kops.

This would allow the following to command to work:

./kops create cluster\
  --name=$CLUSTER_NAME.k8s.local\
  --dns-zone=$CLUSTER_NAME\
  --dns=private\
  --out=./terraform/\
  --target=terraform\
  --zones us-east-2a\
  --master-public-name=$CLUSTER_NAME\
  --state=$KOPS_STATE_STORE\
  --cloud=aws

Expected result:

The resulting configuration and certificates generated includes the correct SAN-properties (e.g. api.my-k8s.deployment.com

All you would need to do after deploying, is pointing a Cname for api.my-k8s.deployment.com to the resulting ELB address.

Current progress:

I have created a patch, and are ready to submit a PR for this, but would like to get some feedback on the design.

[chrislovecnm]

One way we could solve this, is to run kops edit cluster and change the master-public-name (remove the k8s.local part). But, when you run kops update cluster the certificates involved does not get updated, so we are back to scratch.

Shouldn't kops update fix the cert? That would allow a users to either do an edit or use manifests to create the cluster.

[mdavidsen]

Definitively, but I'm not sure what other complications that could occur if you start updating those certificates during production.

From what I understand right now at least, the certificates are only updated during provisioning of the master/node, I am correct?

Is there a reliable way of updating the certificates on the masters during production currently? I absolutely think this something that should be fixed, but I also believe that it might be a larger task to complete.

[blakebarnett]

Depends on this being done first: #1919

[mdavidsen]

@blakebarnett I'm not sure that #1919 is required before implementing this. I was able to solve this specific issue with: #3385 But it definitively related.

[justinsb]

Looks good, I just want to retrace your steps - commented at #3385 (comment)

[ferdy-lw]

I have a similar issue with a private zone and terraform, all my topology is private and in an existing vpc. The resultant certificate does not include the ELB or any publicly resolvable address so I can't use kubectl from outside the vpc (without modifying etc/hosts). If I could specify the public api name I can then setup a cname to the elb. This isn't just helpful for gossip.

Is there a timeline for #3385?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[mdavidsen]

This issue should've been closed a while back, as the related PR was merged. Sorry for the dangling issue.