-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Stop registering Kube cluster named after Teleport cluster #6786
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK to me.
Tagging @klizhentas for UX approval |
@nklaassen LGTM after you update CHANGELOG.md with a breaking change notification similar to others (see examples in changelog) (so we don't forget) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM assuming changelog update
Thanks, I started a placeholder 7.0 section in CHANGELOG.md with a Breaking Changes section including this |
0644fbd
to
5171690
Compare
Issue #6226
There are essentially 3 ways a Teleport Kubernetes service can be configured inside a Kubernetes cluster, listed below.
This PR only changes the first case where the new style Proxy Service is used (
kube_listen_addr
set, nokubernetes:
subsection) inside of a Kubernetes cluster. Currently, in this case, the Proxy service will publish a Kubernetes cluster with the same name as the Teleport cluster. This is not desired - the Kubernetes cluster name should only be published by thekubernetes_service
.1. New Proxy Service style with Kubernetes Service
Current behaviour:
New behaviour:
2. Legacy Proxy Service style without Kubernetes Service
Current behaviour (unchanged):
3. Legacy Proxy Service style with Kubernetes Service
Current behaviour (unchanged):
Backwards Compatability
Anyone currently using the new style Proxy Service with
kube_listen_addr
set, inside of a Kubernetes cluster, will have the current listed Kubernetes cluster named after the teleport cluster "disappear". This may break automation that relies on that "cluster".Testing
configuration_test.go
andauth_test.go
updated