Versions Compared

Key

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

Here is the list of features that will be released at end of this year. 

Complex applications would have front-end microservice and backend microservices.  Backend microservices may be distributed across multiple clusters.  This feature enables connectivity among the microservices in different clusters by automating the ISTIO configuration. Also, it automates the configuration of the ingress proxy to expose the frontend microservice to external users and route the traffic from the external users to the frontend microservice. As a test case, we will use EMCO to deploy Google's Online Boutique which consists of a 10-tier microservices application. This application is a web-based e-commerce app where users can browse items, add them to the cart, and purchase them. Google uses this application to demonstrate the use of technologies like Kubernetes/GKE and Istio. The feature will ensure that EMCO can deploy these microservices properly and can set up a communication channel between these microservices seamlessly through integration with Istio. The work involves creating helm charts for GMS, deploying GMS, automatically creating data traffic controller intents for the GMS, and interacting with Istio control plane to deploy the intents, inject envoy into each microservice POD, and set up the network communication between the deployed microservices as well as the network communication from external users to the frontend microservice. 

Helm provides a hook mechanism to allow the users to specify additional action/logic at certain points in an application's life cycle. Helm supports pre-install, post-install, pre-delete, post-delete, pre-update, and post-update hooks. Add support of these hooks in EMCO.

Azure Arc, Google Anthos, AWS GitOps all implement a GitOps way of deploying applications to K8s clusters. That is, when the CI/CD or users write an application in a git repository, the sync agent in a cluster will be notified of the new application and will read the git repository, and will send the app to its local K8s API server. For geo-distributed applications, intelligent and on-demand deployment, as well as automatic setup of network connections between these apps, is needed. EMCO can act as an intelligent entity that adds intelligent deployment decision to the app in the git repository. Selected clusters' sync agents can be notified at the right time to read the app for deployment. In this release, we will support the integration of EMCO with Azure Arc. That is, after EMCO makes the intelligent decision, EMCO will create an Azure k8s configuration that triggers the Azure Arc to program the selected edge cluster's sync agent. EMCO is responsible for monitoring status, customization of the resources based on intents, inter-app dependency, etc.

Current EMCO's status notification is a poll model. That is, the user needs to explicitly call the EMCO status API to get the status of an app. Some users don't like to poll for the status on a periodic basis. EMCO needs to provide a mechanism for the users to automatically get notified whenever the status of an app changes. EMCO will provide a "status notification" registration API in which a user or a microservice can register interest for one or more apps' status change notifications. This new API will allow the user/microservice to specify appContext and notification criteria (e.g. any change, change for a set of resources across a set of clusters). EMCO will notify those entities when there is a status change

There are cases where one application can not run until another application has been deployed. EMCO will support this inter-dependency between applications. A new API will be added for the app to specify its dependencies. This API will also allow "optional" specification of delay after the depended app is "Ready"/"Deployed". EMCO will make sure an app is deployed after its dependent apps are properly deployed or are in a "ready" state. 

Referential Integrity currently relies on a combined configmap with the schema for all controllers. When a new controller is dynamically added, we need to dynamically incorporate its schema with the existing schema. To support this, EMCO will add a new API for all the new controllers to register their schema and EMCO will automatically merge the new schema with its existing schema. 

The Distributed Cloud Manager (DCM) is an integral in EMCO supporting multiple clusters to be grouped as a Logical Cloud. DCM will be overhauled with the introduction of Logical Cloud labels (which will support K8s namespace labels), JSON-based API validation and the ability to query its status using a Status API, allowing deployments to be more easily enrolled and monitored.

These features have been created and tracked in GitLab: https://gitlab.com/project-emco/core/emco-base/-/issues