Skip to content
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

k8s Central management #28

Open
elevran opened this issue Sep 21, 2023 · 0 comments
Open

k8s Central management #28

elevran opened this issue Sep 21, 2023 · 0 comments
Labels
enhancement New feature or request management plane

Comments

@elevran
Copy link
Collaborator

elevran commented Sep 21, 2023

The goal is to consider how our object model can be mapped into k8s to provide a centralized management function that supports user management, security, persistency, etc.

In essence, we need to identify and define a relevant set of CRDs as well as model their creation and management using k8s facilities (e.g., namespace, RBAC).

A potential mapping would have

  • a Fabric CRD (name, root CA, etc.) - cluster scoped object
  • a Peer/Site CRD (name, certificates, gateway addresses) - these are cluster scoped and create a corresponding namespace. Parts can be read only so other peers can learn of remote's name, gateways etc. In such case, we could move the certificates as secrets to the namespace representing the peer
  • Import/Export/Bindings are per namespace CRDs and are responsible for configuring the peer identified by the namespace (note that we could also explore the use of Kubernetes Multcluster Service (MCS) Export/Import objects in some fashion).

The mapping is relatively straightforward, but limits some of the more advanced checks and use cases we may want to explore. Most of these have to do with k8s RBAC based on verb+kind in a specific namespace, whereas we may want to control per specific attributes.

The could include, for example:

  • restricting which peers you can import a service from (can be emulated by egress/ingress policies)
  • limiting which Services can be exported
  • scaling to multiple fabrics/sites (e.g., when managing multiple fabrics for namespace-scoped ClusterLink)
  • etc.

The above can be built atop of KubeStellar as the distribution where ClusterLink implements per cluster agent/operator (react to CRDs by calling API) and management hub agent (applies management logic such as creating namespaces).
The per cluster operator and CRDs can be developed to allow declarative/kubectl like management irrespective of the central management.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request management plane
Projects
None yet
Development

No branches or pull requests

2 participants