Many users provide services to their customers using the OpenYurt platform. To ensure the security and isolation of resources and business operations, it is generally necessary to create separate OpenYurt clusters for each user. However, as the node scale for individual users is relatively small, this leads to users having to manage a large number of small-scale clusters, thereby facing significant management cost pressures. Additionally, Kubernetes itself only supports resource isolation based on namespaces, which does not fully meet the requirements for multi-tenant isolation.
The goal of this research is to make non-invasive modifications to Kubernetes to achieve exclusive use of edge resources and shared management, supporting efficient multi-tenant isolation capabilities. This approach aims to effectively reduce cluster maintenance and operational costs, optimize resource allocation, and improve service quality while meeting the needs of multiple users.
Objectives
The primary objectives of this issue are to:
Develop Non-Invasive Enhancements to Kubernetes
Design and implement modifications to Kubernetes that enable efficient multi-tenant isolation without invasive changes to the core architecture of Kubernetes. This includes enhancing namespace capabilities or introducing new mechanisms to manage access and resource allocation among multiple tenants at the edge.
Each end user has a full K8s cluster
Each user can only get resources(include namespace scope or cluster scope) of their own, whether using kubeconfig file or a bearer token in the pod, or node certificate.
Don't effect the scalability of the K8s cluster
This means the feature of multi-tenant is not the bottleneck for building large-scale K8s cluster. For instance, it is feasible to incorporate more than 1000 nodes into a single cluster.
Output Requirements
Develop comprehensive design documentation for the multi-tenancy isolation solution, outlining the architecture, components, and interaction mechanisms.
Write and integrate code for the multi-tenancy isolation solution, ensuring it is merged into the community's master branch.
Create unit test cases and end-to-end (E2E) test scenarios to thoroughly validate all relevant functionalities of the solution.
Motivation
Many users provide services to their customers using the OpenYurt platform. To ensure the security and isolation of resources and business operations, it is generally necessary to create separate OpenYurt clusters for each user. However, as the node scale for individual users is relatively small, this leads to users having to manage a large number of small-scale clusters, thereby facing significant management cost pressures. Additionally, Kubernetes itself only supports resource isolation based on namespaces, which does not fully meet the requirements for multi-tenant isolation.
The goal of this research is to make non-invasive modifications to Kubernetes to achieve exclusive use of edge resources and shared management, supporting efficient multi-tenant isolation capabilities. This approach aims to effectively reduce cluster maintenance and operational costs, optimize resource allocation, and improve service quality while meeting the needs of multiple users.
Objectives
The primary objectives of this issue are to:
Develop Non-Invasive Enhancements to Kubernetes Design and implement modifications to Kubernetes that enable efficient multi-tenant isolation without invasive changes to the core architecture of Kubernetes. This includes enhancing namespace capabilities or introducing new mechanisms to manage access and resource allocation among multiple tenants at the edge.
Each end user has a full K8s cluster Each user can only get resources(include namespace scope or cluster scope) of their own, whether using kubeconfig file or a bearer token in the pod, or node certificate.
Don't effect the scalability of the K8s cluster This means the feature of multi-tenant is not the bottleneck for building large-scale K8s cluster. For instance, it is feasible to incorporate more than 1000 nodes into a single cluster.
Output Requirements
Related issues