Versions Compared

Old Version 124

changes.mady.by.user Byung-Woo Jun

Saved on

compared with

New Version 125

changes.mady.by.user Byung-Woo Jun

Saved on

Key

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

...

PlantUML Macro
titleASD Onboarding
@startuml
participant Designer
participant Admin
participant SDC
participant Catalog_Manager
participant Helm_Registry
participant SO_Client
participant SO
participant SO_CNFM
participant CNF_Adapter
participant K8S_Plugin
participant AAI
participant K8S_Cluster

autonumber 

group ASD App PACKAGE Distribution
	hnote over SDC : SDC supports ASD-based Service CSAR
    Designer -> SDC : Onboarding ASD App Package
    SDC --> SDC : Onboards ASD App Package and\ngenerates Resource VF(s) & Service CSAR
    SDC -> SO : Distribute Service CSAR
    SDC -> AAI : Distribute Service CSAR
end  

group ASD, Helm Chart and Image Distribution
    hnote over Catalog_Manager
    Catalog_Manager --> SDC : Get ASD App Artifacts
    Catalog_Manager --> Helm_Registry : push Helm Charts
    Catalog_Manager --> K8SImage_ClusterRegistry : push Images Distribute  Service CSAR
end  	

group K8S Cluster Admin
	hnote over Admin : Admin accesses K8S Cluster
    	Admin -> K8S_Cluster : Create/Update/Configure K8S Cluster
    Admin -> AAI : Add/Register K8S Cluster 
    AAIAdmin --> AAI : Add the tenant
	K8S_Cluster -> AAI  AAI: Auto Discovery (optional)
	Admin -> K8SSO_PluginCNFM : PostPOST Connectivity Info (KubconfigKubeconfig file)  
end



@enduml

Instantiation of ASD Service CSAR - Day 1

...

Assumption & Requirements (from cloud.google.com)

source: https://cloud.google.com/kubernetes-engine/docs/best-practices/enterprise-multitenancy 

The best practices in this guide are based on a multi-tenant use case for an enterprise environment, which has the following assumptions and requirements:

  • The organization is a single company that has many tenants (two or more application/service teams) that use Kubernetes and would like to share computing and administrative resources.
  • Each tenant is a single team developing a single workload.
  • Other than the application/service teams, there are other teams that also utilize and manage clusters, including platform team members, cluster administrators, auditors, etc.
  • The platform team owns the clusters and defines the amount of resources each tenant team can use; each tenant can request more.
  • Each tenant team should be able to deploy their application through the Kubernetes API without having to communicate with the platform team.
  • Each tenant should not be able to affect other tenants in the shared cluster, except via explicit design decisions like API calls, shared data sources, etc.

Access Control

TBD

Network Policies

...