Versions Compared

Old Version 37

changes.mady.by.user Kuralamudhan Ramakrishnan

Saved on

compared with

New Version 38

changes.mady.by.user Kuralamudhan Ramakrishnan

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. For a service provider, a tenant is basically a group of end-user sharing the same cluster, we have to make sure that the end user resources are tracked and accountable for their consumption in a cluster
  2. In a few cases, admin or end-user application is shared among multiple tenants, in such case application resource should be tracked across the cluster
  3. Centralization resource quota or the allocation limits record should be maintained by admin or for the end user. For example, just a kubectl "query" to Kubernetes API should display the resource quota and policy for each end-user or tenant
  4. In Edge use case, the service orchestration like ICN should get the resource details across multiple clusters by resource orchestration, should set the resource allocation for the cluster and decide the scheduling mechanism
  5. User credential centralization with application orchestration

Cloud Native Multi-tenancy Proposal - Tenant controller

Cloud Native Multi-tenancy proposal reuses the Kubernetes Multi-tenancy works to bind the tenant at the service orchestration and resource orchestration level.

...

Tenant controller architecture

ICN Requirement and Tenant controller gaps


ICN RequirementTenant  Controller

Multi-cluster tenant controller

  1. Tenant created at Multi scheduler site (ONAP4K8S)
Cluster level  tenant controller

Identifying K8S clusters for this tenant based on cluster labels

  1. Send the Tenant details to the K8s cluster
Tenant is created with CR at cluster level [Implemented]

At K8s cluster level

  1. Creating namespace
  2. Creating K8S users (Tokens, Certificates and User/Pwds)
  3. Creating K8S roles
  4. Creating permissions to various roles.
  1. Tenant controller at K8s cluster level [Implemented]
    1. A tenant can have multiple namespaces 
      1. Tenant-a
        1. ns1
        2. ns2
      2. It creates Tenant-a-ns1 and Tenant-a-ns
  2. Cluster-admin: This persona has full read/write privileges for all resources in the cluster including resources owned by various Tenants of the cluster [Not implemented].
  3. Cluster-view: This persona has read privileges for all resources in the cluster including reasources owned by various Tenants [Not implemented].
  4. Tenant-admin: This persona has privileges to create a new tenant, read/write resources scoped to that Tenant and update or delete that Tenant. This persona does not have any privileges for accessing resources that are either cluster-scoped or scoped to namespaces that are not associated with the Tenant object for which this persona has Tenant-admin privileges.[Implemented]
  5. Tenant-user: This persona has read/write privileges for all resources scoped within a specific Tenant (that is resources that are scoped within namespaces that are owned by a specific Tenant) [Not implemented].

Certificate Provisioning with Tenant

  • Suggestion to use Isito using citadel
Suggestion to bind the tenant with kubernetes context to see namespaces associated with it[Not implemented].
  • Quota at the application level.
  •  Tenant group support: Quota at the tenant group level (Multiple namespaces), ISTIO at the tenant group level.
  • Resource quota based on the tenant with multiple namespace[Not implemented].

Multi-Cluster Tenant controller

<This section is incomplete and a work in progress ... needs rework and further updates ... >

Image Added

Srini notes:

  1. Define CRUD API - add/delete/modify/read MC Tenant.
  2. Design note :
    • On how this would be done as Micro-service in the ONAP.
    • How does interact with K8S clusters.
    • How does it ensure that all the configuration is applied (rollbacks, unsuccessful edges).
    • Visibility of the configuration applied on per MCTenant basis.
    • When new K8S cluster is added with the label of interest, taking care of creating tenant-specific information in that edge etc..
    • Extensibility (future K8S clusters having some other features that require configuration for multi-tenancy).

Reference

Kubernetes Multi-Tenancy Draft Proposal
Tenant Concept in Kubernetes

...