...
| PlantUML Macro | ||
|---|---|---|
| ||
@startuml skinparam roundcorner 20 title Register placement and action controllers via Controller API actor Admin box "Distributed Application Scheduler\n(orchestrator)" #LightBlue participant Controller_API participant GRPC_Server_info participant scheduler end box box "EMCO DB" #LightGreen database mongo end box box "AppContext" #LightGreen database etcd end box box "Placement Controller(s)" #LightBlue participant UpdateContextAPI_place end box box "Action Controller(s)" #LightBlue participant UpdateContextAPI_action end box loop for all placement and action controllers Admin -> Controller_API : POST controller\nregistration information\n(Name, Host, Port, Type, Priority) Controller_API -> mongo : Save controller record Controller_API -> GRPC_Server_info : add a GRPC connection\nto controller to\ninternal table Controller_API -> Admin : Return end == Some time later - orchestrator\nis preparing an AppContext\nfor deployment == ||| scheduler -> etcd : Prepares initial AppContext\nfor the composite app\nusing the generic\nplacement intents scheduler -> mongo : Retrieve all controllers\nrequired for this AppContext\ndeployment loop for all placement controllers in priority order scheduler -> GRPC_Server_info : Retrieve gRPC connection\nfor controller scheduler -> UpdateContextAPI_place : GRPC UpdateContext API call (AppContext identifier) UpdateContextAPI_place -> etcd : updates AppContext according to\nthis controllers placement function UpdateContextAPI_place -> scheduler : return end ||| loop for all action controllers in priority order scheduler -> GRPC_Server_info : Retrieve gRPC connection\nfor controller scheduler -> UpdateContextAPI_action : GRPC UpdateContext API call (AppContext identifier) UpdateContextAPI_action -> etcd : updates AppContext according to\nthis controllers action function UpdateContextAPI_action -> scheduler : return end ||| @enduml |
Onboard Clusters
...
Clusters are onboarded to EMCO by first creating a Cluster Provider and then adding Clusters to the Cluster Provider.
When a cluster is created, the KubeConfig file for that cluster is provided as part of the multi-part POST call to the Cluster API.
Additionally, once a Cluster is created, labels and key value pairs may be added to the Cluster via the API. Clusters can be specified by label when preparing placement intents.
The sequence diagram illustrates the process onboarding the cluster and a couple examples of how other sequences in the EMCO system obtain cluster information during operation.
| PlantUML Macro | ||
|---|---|---|
| ||
@startuml
skinparam roundcorner 20
title Onboard clusters
actor Admin
box "Cluster Manager\n(clm)" #LightBlue
participant Cluster_API
participant Cluster_Module
end box
box "Distributed Application Scheduler\n(orchestrator)" #LightBlue
participant Controller_API
participant GRPC_Server_info
participant scheduler
end box
box "EMCO DB" #LightGreen
database mongo
end box
box "AppContext" #LightGreen
database etcd
end box
box "Resource Synchronizer\n(rsync)" #LightBlue
participant rsync
end box
box "Edge Cluster"
participant K8S_API
end box
Admin -> Cluster_API ++ : POST cluster_provider (name)
Cluster_API -> Cluster_Module ++ : call create cluster\nprovider handler
Cluster_Module -> mongo : Save cluster provider record
Cluster_Module -> Cluster_API -- : return
Cluster_API -> Admin -- : return
Admin -> Cluster_API ++ : POST cluster (name, kubeconfig file)
Cluster_API -> Cluster_Module ++ : call create cluster\nhandler
Cluster_Module -> mongo : Save cluster record
Cluster_Module -> Cluster_API -- : return
Cluster_API -> Admin -- : return
Admin -> Cluster_API ++ : POST label(s) or kvpair(s) (optionally)
Cluster_API -> Cluster_Module ++ : call create cluster label\nor kv pair handler
Cluster_Module -> mongo : Save cluster label or\nkv pair record
Cluster_Module -> Cluster_API -- : return
Cluster_API -> Admin -- : return
== Some time later - generic placement controller\nis preparing an AppContext\nfor deployment ==
|||
scheduler -> Cluster_Module ++ : GET clusters by label (or name)
Cluster_Module -> mongo : retrieve cluster records by label
Cluster_Module -> scheduler -- : return
loop for all resources in a cluster
scheduler -> etcd : Create cluster key(s)\nin AppContext and add\nappropriate resources
end
== Some time later - rsync is\ndeploying resources to a cluster ==
|||
loop for all clusters in a composite application
rsync -> rsync : get k8s client for cluster
rsync -> Cluster_Module ++ : if no k8s client, GET kubeconfig for cluster
Cluster_Module -> mongo : retrieve cluster kubeconfig
Cluster_Module -> rsync -- : return
rsync -> rsync : create k8s client with kubeconfig
loop for all resources in a cluster
rsync -> K8S_API : apply resource to cluster
end
end
|||
@enduml |
Create Network Intents
(show how network intents are defined and deployed to clusters)
...