feat: Auto-provision domain for TLS Edges #386
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
contributes to #375. Pulling this change out for easier review.
What
The hostports for a given TLS Edge need to be reserved as domains in ngrok before they can be used. Because of this, it makes sense that the TLSEdge handles reserving the domains if they aren't already reserved in the same way that the TCPEdge controller will take care of reserved addrs and the same way that the ingress controller builds the list of domains to reserve in its store across namespaces.
How
Parse out the hostports defined in the TLSEdge and automatically find or reserve the necessary domains. Also, populate a new field
cnameTargets
map in theTLSEdge
'sStatus
that contains the CNAME target from the domains. This will allow other controllers which may create TLSEdges to use the CNAMETargets map. For example, Services can use this to update the.status.loadBalancer.ingress
fields.Also handles dangling CNAME records more gracefully in the domain controller by retrying them.
Breaking Changes
No