cluster-api-provider-aws

cluster-api-provider-aws copied to clipboard

/kind feature

Describe the solution you'd like Currently CAPA will always use the DNS name for the ELB that it gets from AWS, this results in having a cluster named bob you will probably get a DNS name of bob-cluster-apiserver-12345678.${AWS_REGION}.elb.amazonaws.com. This can be problematic for a couple reasons:

• If you are to delete the ELB you are actually in a completely unrecoverable state, see https://github.com/kubernetes-sigs/cluster-api-provider-aws/issues/2608
• You don't want your users seeing the underlying DNS name (maybe because it's not pretty?)
• You are using multi-cloud solutions or other things that might create a strong desire to have a better vanity DNS entry for your API servers. (For example: providing a single UX for developers logging into their k8s clusters.)

I would like a partial solution while we wait for the community to figure out the Load Balancer proposal.

When I create my AWSCluster I will populate spec.controlPlaneEndpoint.host with my own vanity URL, like bob.kubernetes.example.com. CAPA will accept that value, and will still create an AWS ELB. CAPA will then pause until the DNS I provided bob.kubernetes.example.com resolves to CAPA's internal ELB bob-cluster-apiserver-12345678.${AWS_REGION}.elb.amazonaws.com. CAPA does create the ELB, but does not create the DNS entry linking the ELB name to the vanity URL, and instead has an expectation that I will handle it. CAPA will expose that unfriendly DNS name bob-cluster-apiserver-12345678.${AWS_REGION}.elb.amazonaws.com somewhere (ideally in the status of AWSCluster or a similar custom resource that is easily identifiable) so that I can retrieve it and update my DNS records accordingly (see next section).

A "more" complete solution

It would be wildly convenient if CAPA could also create a Service with External Name setup in this process, which should allow External DNS to facilitate creation of that pairing from my selected vanity URL over to the AWS actual ELB name:

apiVersion: v1
kind: Service
metadata:
  labels:
    cluster: bob
    cluster.x-k8s.io/cluster-name: bob
  name: bob-elb-dns-name
  annotations:
    external-dns.alpha.kubernetes.io/hostname: bob.kubernetes.example.com # contents of `spec.controlPlaneEndpoint.host`
spec:
  externalName: bob-cluster-apiserver-12345678.us-east-1.elb.amazonaws.com
  selector:
    cluster: bob
    cluster.x-k8s.io/cluster-name: bob
  type: ExternalName

Anything else you would like to add: This is primarily meant as a "break glass" workaround to the issues we're experiencing with losing access to the AWS ELB that was around during creation of clusters. Getting from unrecoverable to recoverable is really the primary goal here, with the vanity URLs being a pleasant side-effect (that is also desirable, but less important)

Environment:

• Cluster-api-provider-aws version:
• Kubernetes version: (use kubectl version):
• OS (e.g. from /etc/os-release):

Wondering if using this in conjunction with https://github.com/kubernetes-sigs/cluster-api-provider-aws/pull/2787 might help since the clusters with the vanity URL would have an empty name. :shrug:

Wondering if using this in conjunction with #2787 might help since the clusters with the vanity URL would have an empty name. shrug

#2787 lets the user define their own ELB (and therefore their own ELB name).

I agree that another level of indirection, in the form of a user-defined DNS name for the control plane endpoint, separate from the AWS-managed ELB DNS name, is a good idea for the reasons you wrote in the description.

If only we could use deletion protection, but that's only available for ALB.

Honestly, the user-defined DNS name for the control plane endpoint sounds like a good default, too, but I think that would requires the user to control a domain name.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

Still very much a strongly desired feature.

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.