EMCO Architecture
In the previous blogs we explored what EMCO project is all about and why it is needed in the market today. In this blog we dive further into the architecture and working of the project EMCO.
We know that EMCO is an extensible platform, it has multiple controllers which can help us to extend its functionality depending on the use case.
Some of the functionalities EMCO provides are enrolling multiple geographically distributed clusters, orchestration of composite applications (composed of multiple individual applications) across different clusters, deployment of edge services and network functions to different nodes spread across different clusters, monitoring the health of the deployed edge services and network functions across different clusters, orchestration of edge services and network functions with deployment intents based on compute, acceleration, and storage requirements and supporting multiple tenants from different enterprises while ensuring confidentiality and full isolation between these tenants.
Currently EMCO provides both a command line interface as well as a web graphical user interface for a project deployed over it, keep in mind that an EMCO project means of grouping collections of applications. Multiple applications may exist for any project. Projects allow for defining applications with different tenants - i.e. a given tenant is associated with one or more projects that are distinct from other tenants' projects.
Controllers
The first controller, Cluster registration controller, loads the target Kubernetes cluster on the EMCO platform. The cluster provider is the entity that owns and registers clusters with EMCO.
Once the clusters are registered with EMCO., we can access a given cluster via the kubeconfig file or via one of the supported gitOps methods.
The Hardware platform aware controller enables scheduling with auto-discovery of platform features/ capabilities.This helps in specifying placement intents, so when an application is being deployed EMCO internally figures out the best suitable cluster for its deployment.
For example we have seen how a composite application is a set of multiple applications working together. Through the use of placement intents, EMCO allows different applications in the composite application to be deployed (and replicated as necessary) to different sets of clusters. Say a composite application composed of a user facing application along with a database application could be deployed by EMCO such that the user facing application is deployed to many edge clusters while the database application is deployed on a centralised cluster.
The Network configuration controller handles creation and management of virtual and provider networks. Some services which are to be deployed may require a secondary network, this controller automates the creation and management of these secondary network interfaces.
The Distributed cloud manager presents a single logical cloud from multiple edges.
A logical cloud is an EMCO concept that groups a number of clusters together and provides a common set of namespace, permissions and quotas. Logical clouds are defined under projects and are the target deployment destination of EMCO Composite Applications. Placement scheduling will ultimately determine which cluster(s) in a logical cloud any specific component of a composite application will be deployed to. This is used to stitch the various clusters together that we have on-board, and it is done to make it the target for specific deployment intent groups.
Logical Clouds
A Logical Cloud is the overall target of a Deployment Intent Group and is a mandatory parameter. Logical Cloud must be explicitly created and instantiated before a Deployment Intent Group can be instantiated. Currently EMCO is designed such that even if you are using a single cluster, it still requires the instantiation of a logical cloud, we will see this in the subsequent blogs.
There are 3 types of logical clouds Standard Logical Clouds, Admin Logical Clouds and Privileged Logical Clouds.
Logical Clouds were introduced to group and partition clusters in a multi-tenant way and across boundaries, improving flexibility and scalability. A Standard Logical Cloud is the default type of Logical Cloud providing just that much. When projects request a Logical Cloud to be created, they provide what permissions are available, resource quotas and clusters that compose it. The Distributed Cloud Manager, alongside the Resource Synchronizer, sets up all the clusters accordingly, with the necessary credentials, namespace/resources, and finally generating the kubeconfig files used to authenticate and reach each of those clusters in the context of the Logical Cloud.
In some use cases, and in the administrative domains where it makes sense, a project may want to access raw, unmodified, administrator-level clusters. For such cases, no namespaces need to be created and no new users need to be created or authenticated in the API. To solve this, the Distributed Cloud Manager introduces Admin Logical Clouds, which offer the same consistent interface as Standard Logical Clouds to the Distributed Application Scheduler. Being of type Admin means this is a Logical Cloud at the Administrator level. As such, no changes will be made to the clusters themselves. Instead, the only operation that takes place is the reuse of credentials already provided via the Cluster Registration API for the clusters assigned to the Logical Cloud (instead of generating new credentials, namespace/resources and kubeconfig files.)
The Privileged Logical Clouds provides most of the capabilities that an Admin Logical Cloud provides but at the user-level like a Standard Logical Cloud. New namespaces are created, with new user and kubeconfig files. However, the EMCO project can now request an enhanced set of permissions/privileges, including targeting cluster-wide Kubernetes resources.
Until the 22.03 release of EMCO, once a logical cloud is created, i.e. the clusters are added in the logical cloud, there was no provision to modify it, if you specified quotas and permissions once there was no provision to modify the instantiated logical clouds. With this release you can now modify it throughout its life cycle.
The Secure Mesh controller auto-configures both service mesh (ISTIO) and security policy (NAT, firewall).
EMCO uses auto-configuring service mesh (ISTIO) and security policy (NAT, firewall), which enables the communication between deployed apps or between a deployed app and an external service within or across clusters with/without mutual TLS.
(A service mesh is a dedicated infrastructure layer that you can add to your applications. It allows you to transparently add capabilities like observability, traffic management, and security, without adding them to your own code.)
Some other controllers are the Distributed Application Scheduler which provides simplified and extensible placement, the Resource Synchronizer manages instantiation of resources to clusters, Secure WAN Controller automates secure overlays across edge groups and monitoring covers distributed applications.
In addition to the above components, EMCO provides a number of other controllers. All of the EMCO micro-services will be summarised in the subsequent blogs.
Thanks a lot for reading!