-
Notifications
You must be signed in to change notification settings - Fork 0
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
(feat) central cluster ADR #1
base: main
Are you sure you want to change the base?
Conversation
## Decision Drivers | ||
|
||
* **Network Compatibility** | ||
It assumes that the network zone of the central Greenhouse cluster is suitable for all organizations and cloud providers. |
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.
Explicit mention: This would enable use cases residing in different hyperscalers.
|
||
* No user-configurable plugins should be allowed in the Greenhouse central cluster. | ||
* Maintain restrictive permissions within the central cluster limited to Greenhouse resources. | ||
* Introduce `AdminPlugins` to utilize the plugin concept for handling core responsibilities. |
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.
Adding context from Slack DMs: AdminPlugins
in this case could be Plugins such as IdP Integration, Cluster Registry, Greenhouse Teams to Slack syncing, ... . These would all be Plugins which are close the backend (e.g. use Greenhouse CRDs) but are developed separately from the Core Operators.
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.
TODO: Sharpen definition AdminPlugins.
kubeconfig generator, CAM integration - things not directly configurable by the user
TODO:
|
Thus workload in the central cluster is charged on the provider. | ||
|
||
Moreover, workload within the central cluster is neither transparent nor accessible to the customer. | ||
It cannot be configured, its metrics, logs, etc. are not exposed and access (kubectl exec/delete pod) is restricted. |
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.
It cannot be configured, its metrics, logs, etc. are not exposed and access (kubectl exec/delete pod) is restricted. | |
It cannot be configured, and its metrics and logs are not exposed. Access to operations like 'kubectl exec' or 'kubectl delete pods' is restricted in the central cluster. |
This PR is stale because it has been open for 45 days with no activity. |
This PR is stale because it has been open for 45 days with no activity. |
This PR introduces an ADR for the central clusters.
TLDR: I'd like to disallow plugins in the central cluster and move them to a customer-owned cluster to address the various disadvantages and risks the current situation imposes. This should be decided and implemented asap.