Cloud Native Computing Foundation KubeCon + CloudNativeCon North America 2022, 11 Nov 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Overview Of Challenges And Solutions For Orchestrating Applications To... - Ritu Sood & Cathy Zhang

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe in Amsterdam, The Netherlands from April 17-21, 2023. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Overview Of Challenges And Solutions For Orchestrating Applications To Multiple DC And Edge Clusters - Ritu Sood & Cathy Zhang, Intel Corp

Speakers: Ritu Sood, Cathy Zhang
Deploying, monitoring, and managing complex applications across multiple clusters is a challenging task. A complex application is usually composed of multiple microservices that need to be deployed to different clusters based on the criteria like latency, bandwidth, local context, etc. Some microservices need to be replicated in multiple geo-locations. Some microservices have cross-cluster dependencies. Some of these microservices deployed across different clusters may also need to communicate with each other securely. Furthermore, various infrastructure-related configurations need to be done in order for some microservices to function properly. To reduce the operational cost of deploying and managing these complex applications, automation is a must, and the goal is to achieve zero-touch deployments. In this talk, we'll examine the landscape of available solutions such as Kubedge, ArgoCD, Karmada, EMCO, etc. and provide an in-depth analysis of each of them.

A

Hello, everyone welcome to work to our session on challenges and solutions for orchestrating applications to multiple data center and age clusters.

A

My name is Kathy Zhang I'm, a senior principal engineer at Intel, leading the company-wide contributions to the cloud native Computing Foundation I have over you 10 years of experience in the Cloud area, I co-authored several cncf white paper and specifications I was recently elected to the CSF technical oversight committee. Along with me, is written. Yeah Ritu want to introduce yourself.

B

Hello: everyone, my name, is Ritu suit. I'm A, Cloud, engineer, slash architect, working at Intel and I've, been working in the Cloud area for over uh last seven years and I have contributed to a few of the open source projects related to Cloud.

A

Covered in today's presentation and first we will touch a little bit on the current industry trend on geo-distributed, Computing and multi-cloud. Then we will go through several use cases.

A

After that we will talk about the requirements and challenges to support multi-cloud last we will Deep dive into some existing Solutions, sharing their architecture and functionality, as well as analyzing their pros and cons.

A

The industry is moving from a centralized cloud computing model to a distributed to a geodistributed cloud computing model with many workloads running under age clusters. There are several drivers behind the geodesic Geo distributed computing. Trend one is the need for low latency response time, which requires the application to run closer to the to its data sources.

A

Another is a need to reduce the bandwidth costs associated with information passing between the public cloud data center and the Aged device, and to avoid the network bandwidth caused a network congestion.

A

More and more applications run locally at the age sites. In addition, some legal and privacy considerations also require the applications to not leave a Enterprise permits as showing the right diagram. It is now very common for very common to have some applications that require a lot of computing resources to run in the public cloud, while having other applications that are latency, sensitive or privacy. Sensitive run at the age site and dedicated network channels can be set up between public cloud and age cloud.

A

And this slide shows the three use cases for geodetributed computing. Of course there are many other use cases. The first one is a 5G use case. In the 5G scenario, there are tens of thousands of distributed 5G units that need to run at the age size.

A

There are thousands of centralized 5G units that need to run at the central office site. Then there are 5G control, components and upfs that need to run at the regional Data Center. There are also some compute intensive 5G applications such as analytics that can run in the public Cloud. As you can see, 5G components need to be deployed in a geodetributed way. The Second Use case is Telco CPE use case in this use case.

A

The container Network functions need to run at the far age, Universal CPE platform, the traffic Hub and The Sassy Services need to run at the network age and other compute intensive applications such as Network analytics, can run in the public cloud.

A

The third one is retail Enterprise use case similar to The Second Use case some CAF, which we need Cloud container Network functions and the size Services need to run at the branch office, while the traffic Hub and some other Safety Services need to run and Enterprise data center, while analytics applications can run in the public cloud. As you can see, all these use cases require geo-distributed Computing to support these geocon Geo distributed computing. We need a multi-cluster orchestrator that can automatically deploy components of a complicated application to one or more age clusters.

A

Now I'm going to hand over to Ritual to work you through the challenges and the available Solutions.

B

Thank you, Kathy Also, let's walk through the requirements and challenges of multi-cloud orchestrator. The obvious requirement is to deploy these microservices with one click across large number of clusters, and some of these microservices may require customizations based on which cluster they are being deployed. Another role that the orchestrator must play here is to make decision about the best cluster to run the workloads based on the requirements like Hardware latency cost localization Etc, some of the Clusters are push paste and some are pool based also known as a GitHub space clusters.

B

Another aspect is tenant management and to deploy these microservices in a multi-tenant aware, environment. uh Another very important aspect is monitoring these microservices once they are deployed and also monitoring the cluster resources where these are installed. Deploying them on microservices is just the start. These micro Services require multiple infrastructure services and these Services need to be configured on the cluster based on the microservice being deployed on the cluster.

B

For example, uh there can be service meshes which need to be configured like sto, Linker, D, Etc and another example is configuration required for service Discovery across these clusters.

B

All the kubernetes Clusters are not um equal with respect to resources, so this because of this, some of the micro Services may need to be brought up with different profiles on different clusters.

B

For example, a 5G UPF may need to be assigned with 16 number cores if it is being deployed on one kind of an edge and two cores if it is being deployed on a different kind of an edge and deployment of these microservices is just one part, and some of these microservices may require configurations after they are deployed, and the challenge is to configure these microservices in an atomic operation.

B

Many microservices across many kubernetes clusters are to be configured in some cases. Microservices are expected to be configured directly and in some cases they may be configured via restful, apis or other means. Some of these configuration may need to be done over unreliable networks, so having a workflow based approach is required to help with retries timeouts Etc.

B

So during this presentation we will keep these requirements uh in mind and then see how different solutions are come across on these requirements.

B

So I'm going to break up these requirements little bit more and going to talk about each of these requirements, one by one in the first stage before any microservices are deployed, the orchestrator needs to onboard clusters and tenants. Some of these clusters can be shared across tenants. Some clusters are get top spaced, they should be. The orchestrator should be able to onboard different types of clusters, for example azur, Arc, anthos flux or any on-prem clusters.

B

Etc each tenant requires an ability to use tenant, specific oauth, 2 servers.

B

The tannins are required to be to be created across clusters and we are calling that as a logical Cloud, the tenants are required to be created with some rbac rules and permissions.

B

Next uh step is to onboard the micro services with the orchestrator, along with the microservice. There are. Some profiles also need to be onboarded, which will help to deploy these microservices on different types of clusters. The placement policies are also required to be defined so that the microservice can this or that the orchestrator can make the best decision to place the microservices on the best possible clusters.

B

um Some some of the microservices may have placement constraints like platform capabilities, latency cost and the orchestrator should be able to take these decisions to find the best cluster for the microservice, and some microservices may require replication or some microservice may require getting distributed to different clusters. So all these things need to be taken care by the orchestrator.

B

So for an example, let's say there is an application which needs to be um to be deployed on all the Clusters with label usfest and needs to be deployed on only one cluster with the label Us East.

B

uh In the case where there is a choice of clusters, uh the orchestrator should be able to take a decision based on the best possible cluster to deploy the microservice.

B

uh The next stage is um workload customization, uh and these need to be done based on the uh the type of cluster that a micro service is deployed on, for example, the image repository to be used or replicas or storage class may need to be configured based on the cluster, where the microservice is being deployed.

B

Enabling, inter microservice, communication within or across clusters is another important function and enabling of this may require, with or without Mutual TLS, and also the management of multi-cluster DNS.

B

So once uh all these configurations are done, um the the life cycle, management of the application is also required, where an application can be started, terminated, updated or rolled back, and all those functions need to be done by the orchestrator.

B

Another very important requirement from the orchestrator is that it should be extendable because there can be different Technologies, for example, being used for connectivity like there can be different kind of service meshes being used on different clusters, or there can be other infrastructure elements that need to be automated for these microservices, so the orchestrator should be extendable so that it can work with any of these new technologies and new requirements can be easily made met with the orchestrator.

B

So once the applications are deployed, there is a need to continuously monitor them, and this is to be done across these clusters and there is a requirement to get like a comprehensive report of the status of these applications across these clusters. There's also need for collecting metrics on the Clusters and based on the metrics. Some closed loop policies may need to be taken. For example, if the load of one cluster is too high, then some microservice may be needed to be moved to another cluster.

B

uh Also uh like I mentioned before some microservices require some configurations after they are brought up, uh so the orchestrator should be capable of taking care of that. Also.

B

So now that we have looked at um uh what are the requirements or challenges that an orchestrator needs to um needs to have to fulfill this, uh the use cases that we were looking at next, we are going to look at some of the projects that are trying to solve uh these challenges and we will go through their architectures and look at their pros and cons and keep these requirements in mind and see how they do against these requirements.

B

So the first project that we are going to take a look at is Q badge. Cube Edge is an ad solution that was initially built mainly to manage smart iot devices at Edge and to run microservices on top of them. These devices generate a huge amount of data and it is possible to send the data to the cloud and it's not possible, to send the data to the cloud to analyze and send the results to the edge uh doing that will make the latency very high, which is unacceptable in managing some of these devices.

B

Security is also a concern, and these Network edges may have connectivity challenges and also limited resources. So Q badge mainly tries to solve these issues. It is a remote node architecture, which means that the remote edges are treated as nodes of the kubernetes cluster.

B

So, as you can see from the picture on the right hand, side the edge node is treated as a node or a kubernetes cluster, and it has uh the cube. Edge has three distinct components: a cloud edge and a device layer, so the edge core which is running on the edge module, manages the life cycle of the pods and it is actually a lightweight cubelet.

B

It helps to exploit the containerized workloads, OR microservices, at the edge node Edge core is optimized to run with a very small memory and CPU footprint like one vcpu and 128 kilo bit memory, and and as we can see, there is a you know, we can have a mix of cloud node and Edge node on the same kubernetes cluster.

B

uh There is a websocket based communication uh between the control, plane and the edge nodes, and, and we can see on the edge node, uh there can be number of device models that can be supported using uh Cuban.

B

uh There is a edge mesh technology which enables use the ability to access edge to edge and Edge to cloud and Cloud to Edge microservices across different networks. It provides simple service, Discovery and track traffic proxy functions for microservices, um so this slide was taken from kubecon 2022 Europe.

B

As you see, there is a the Cloud Core here, watches uh for any changes to pods and the pods need to be um labeled in a certain way and uh Cloud Core uh watches for these pod um changes in the hcd, and at that point uh the Cloud Core sends a websocket based notification to the edge core and the uh and the pods are sent to the edge core where the HD, which is a lightweight cubelet, will create the Pod and then run the pod on the edge and also uh the Pod state is persisted on the Node, and this is required so that the edge can continue to operate.

B

Even if there is a connectivity lost with the control plane so as we can see that this is a very specialized implementation and this is suitable, mostly for iot use cases.

B

uh The next um project that we are going to look at is Argo CD application set. So Argo CD is a declarative, github's continuous delivery tool for kubernetes, and it is implemented as a kubernetes controller, which continuously monitor running microservices and compares the current and live State against the desired state um uh in a git repo and the deployed application.

B

If a deployed application deviates from the target state, it is considered out of sync and Argo CD uh monitors these differences and tries to sync uh the livestake pack automatically, so that uh what is running on the cluster matches with what is there in the git location? uh This is the Sim. This is the regular git Ops um uh principles, so Argo CD um also has multi-tenancy and single sign-on support uh inbuilt so, but for what is interesting from a multi-cluster perspective in Argo, CDs Argo CDs application sets and application set controller.

B

An application set controller allows to automatically generate what is known as an Argo CD application. So, with application sets, you can Define multiple clusters on which you want to deploy your application and you can define a template on which which can be used, which will be used to create these applications.

B

um So application set is responsible for reconciling um the application on these various clusters. um The controller generates one or more application and based on the contents of the template field of the application set. There is also dependency management within an application which is available in Argo CD and it meets you know, like you know. The first requirement that we had of like a single click, deployment of applications or microservices across clusters, so Argo CD meets those requirements very well, but it stops there.

B

uh The next project that we are going to take a look at is karmada karmada is a continuation of kubernetes federation uh project, no used to be known as cube fed uh and it's an open, multi-cloud multi-cluster, kubernetes orchestrator. uh It supports deploying um multiple applications to multiple clusters, cluster mapping. It has the concept of cluster mapping policies, uh so these are known as the propagation policies where the user can specify how they want their application to be propagated.

B

To different listeners- and it has a concept of override policies where you can- a user can Define how they want their application to be customized for a cluster, and the placement is based on cluster Affinity. They installed rations like node, port tense and tolerations, uh and uh Karma also supports multiple multi-cluster application connectivity and in the upcoming releases they will be also adding the sdo based multi-cluster connectivity uh from the original five requirements that we saw. Karmada meets the first requirements very well and provides a service mesh that is STO for cross cluster communication.

B

uh But if there is some other service mesh technology being used, then that support will not be possible with karmada.

B

uh So this is um just what we were talking about. uh How karmada has these propagation policies based on the proposition propagation policies? uh Various clusters can be decided and once the Clusters are decided, then you have override uh overrides which are applied based on where the application is being deployed and in the end, uh work resource is created, and this is the one-to-one mapping with the member cluster. So this is what gets deployed, which this work will deploy the actual resources to the Clusters.

B

Okay, so the last um project that we're going to look at is Amco. uh Amco is a Linux networking Foundation project and it was open sourced under Linux Foundation about a year back, M2 Amco was built from ground up keeping all the requirements that we discussed at the beginning of the presentation. Amco is an intent based architecture. It supports deploying multiple microservices to multiple clusters.

B

It spots various types of edges on clouds, on-prem, Data, Centers, Public clouds and also has support for GitHub space clusters like flux, V2, Azure, Arc and Google anthos Amco isn't highly extensible architecture with entry and third third-party controllers users can specify placement. Intense and Amco makes intelligent selection of clusters to place workflows based on criteria like Hardware capabilities, latency cost Etc. Currently, Amco comes with Hardware platform, aware controller and other type of placement controllers can be easily added into Amco, as it is very extensible.

B

Our tenant isolation is provided using logical clouds. Logical clouds are group, logical crowds, grip and partition clusters for multi-tenants. This partition is made by creating distinct, isolated namespace in each of the kubernetes cluster, where the application is going to be deployed or which is part of the logical Cloud. Our back policies and resource code tasks can be applied to The Logical cloud Amco supports a customization of resources uh based on which cluster the microservice is going to be deployed on and Amco has a comprehensive status.

B

Man monitoring framework for all the resources which were deployed by Amco across all clusters. Amco provides a Consolidated status of the application across clusters and provides a notification set framework where an external application can register to get grpc notifications when an application is either deployed on all the Clusters or any cluster, or is ready on these clusters.

B

Amco provides um an intent based distributed. Traffic management for plus cluster communication users can specify which microservice needs to communicate with, with which other microservice, these intents will be fulfilled by registered subcontrollers based on the cluster on which microservice get deployed. I am co-out-of-the-box, supports, SEO controller for Mutual TLS based cross cluster communication uh based on the cluster.

B

The microservice is getting deployed on uh the relevant sdo policies will be automatically applied so, as mentioned before, Amco is extensible, so other controllers can be written and will work seamlessly with amcode to provide automation of cross cluster communication. If some other service mesh technology is being supported on some clusters, other controllers can be added for automation of other infrastructure services.

B

um Amco takes care of resource customization based on cluster types. Amco also has support for a temporal engine and that can be used for the purpose of configuring, the microservices after they are deployed.

B

So some of the use cases which are made possible with Amcor the use cases that we saw at the beginning of this presentation, the 5G use case um sassy based use cases, neh, Computing application, uh distributed apps, spread across multiple clusters and multiple edges. Amco is capable of supporting all these different kind of multiple, um a different kind of applications.

B

So in summary, there are many solutions which are available in the market and some of these Solutions are specialized for some use cases. uh We also saw how Amco meets many multi-cluster requirements like Dynamic application, orchestrator, along with application, automation of infrastructure, Services selection of kubernetes cluster matching with various criteria, and also the fleet deployment of application with auto customization based on cluster capabilities.

B

um With this um we come to the Q a section and thank you, everyone for listening.