Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Zero Pain Microservice Development and Deployment with Dapr and KubeVela - Hongchao Deng, Alibaba

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. 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.

Zero Pain Microservice Development and Deployment with Dapr and KubeVela - Hongchao Deng, Alibaba Cloud

Developing and deploying microservices could be cumbersome on Kubernetes as developers need to manage deployment configurations of the services per se, MySQL, Kafka, Redis, etc. Those config files are complex and time consuming to learn and write. It becomes a huge burden to developers as they want to focus on business logic, not underlying platform details. In this talk, we will introduce how Alibaba abstracts away infrastructure details and provides consistent experience across various deployment environments by leveraging Dapr and KubeVela. In Alibaba, many developers can now focus only on app code, and the microservice components and their environments will all be setup and managed by the platform with sidecar based approach.

A

Hi everyone welcome to cubicon in this talk, I'm going to talk about how we use cubevela and dapper to develop and build microservice applications.

A

Before we start, let me introduce myself. My name is pronounced as hong chao den I'm currently working as a staff engineer at alibaba and focusing on cloud native application delivery. I love open source and have been contributing quite a while. I am a committer of cook, vella, oem and cosplay projects in the following. I will first introduce cook valla's background and overview. Then I will dive into its architecture and provide more detailed analysis.

A

I will conclude cuba section with some of its key features for application management, and then I will give a brief introduction about dapper and finally, I will talk about how alibaba uses cubic vela and dapper in production and do a case study on application monitoring.

A

First, let's talk about cube vela. Let me start with talking about the background. First, like delivering, applications on kubernetes needs composing a couple of kubernetes resources, for example, deployment stifles that ingress services etc.

A

Usually, we not only need to bundle all those resources into a package, but we also need a composition model to parameterize and connect those resources together. A few projects have been have been trying to solve these problems.

A

One is called application crd from the kubernetes sig, why it's the earliest from upstream effort it doesn't resolve any developer operator concerns so far other than providing like basic metadata. It doesn't work for application law for this reason and there isn't any active development on it. As far as I can see, another project that a lot of people use in production to manage applications is ham. More specifically, like users just write some templates of kubernetes resources and put them in a bundle called chart uh like white hamstring like a lot of people use it like.

A

They are two black box to users.

A

uh The hammer chart is built as parameter values which is hard to like understand and invert like operational resources uh underneath additionally, the parameter values doesn't have api, schemer define for them and finally, like char, doesn't have any composition model that you can use those more use of templates to just plug and play and and like we use across different projects.

A

So very often uh platform teams decide to build their in-house application crds to solve the problems I just discussed like, for example, pinterest has built its own pinterest service and robin hood has its own application or crd, but like developing such thing requires a strong kubernetes development skills, which means like very high learning curve, and very few people can do it and can deserve the time to do it, and these apis are usually very in-house and not generic for reuse or extension. So so what pen just built for itself?

A

Well, we couldn't use it in robinhood or other companies right, and they only offer a limited composition model for their own resources so like this is very in-house and not like generic uniform experience in the open source site.

A

So um the solutions that we we talked about earlier had their own limitations and couldn't satisfy many of the use cases we have seen the application model we need are like, at the end of the day, bog down to two requirements.

A

um It should let platform teams expose high-level apis of only users, concerns and hide those infrastructure complexity it should be, and secondly, it should be an extensible model that provides uniform experience to manage all crds and compose all resources on kubernetes, not just like in-house unlimited by resource set.

A

So we would like to basically would like to have the simplicity of the hand, values file and the structural experience of like those applications, crds that we see from many for pinterest or robinhood, and also a extensible open core model that, like people, can just uh bring their own operations uh resources and they just they can just compose them together.

A

To satisfy this needs, we build a project called cryptvela, it's an application engine to assemble different resources and dispose high-level apis. It's based on open application, oem open standard which is initiated by alibaba and microsoft.

A

It uses kubernetes as the control plane, um and so you can. We, you use like group ctl too, and all those tools you're familiar with kubernetes to to do to like play with it and after its release in cubicon north america last year, like cooper, had become trending on github right that day and have been growing ever since. So it's a active growing project, so uh here's an architecture diagram of how to deliver like applications on cooper.

A

Let's take a look so first, the platform teams need to set up deployment, environments and capability templates. Basically, the capabilities are defined as workload or change definitions, which include the templates to expose the high level apis.

A

These definitions are all registered in kubernetes as crds when developer users want to deploy their apps, they choose the target environments and pick the high-level templated apis and compose application objects and, finally, roll out the applications objects to live clusters.

A

That's basically the general workflow and here's more details about like the kubernetes application object. An application consists of multiple components. Each component is a separate service that contain the basic parameters to run a service workload and a component could be attached with multiple chains, and each chain is a operations enhancement to the app. For example, you may, you might add all the scaling cheat and to a component, and the component will have the auto scanning operations like automatically done, and here the component and tree definitions are also like fully extensible.

A

You can add more like component type and trade types to it, and so that, like your user, can use it also. We will look at that later in, for example, let's take a deeper look into the component definition object. Basically it it encapsulates a workload type that takes the major role to run the service.

A

It provides a couple of templating methods and for platform teams to choose. You can use ham queue or terraform like hcl languages. It also writes back like useful information in status, for example, the schema of the exposed parameters and there's other things like you can write like health chat back to the status as well.

A

So now, let's take a deeper look into the trade definition object. It refers to a crdr that provides the operations capability.

A

It tells the workload types that it can apply to, and it also provides a couple of templating methods for platform teams to choose, like you, can use ham queue or terraform to write the modules. um It also writes that useful information in standards, uh which is the digital schema of the parameters.

A

Now, let's walk through an example, how cooperate works in like real world organizations. First, the platform team creates uh an operator called matrix.

A

They write a they write, they use the matrix as a cheater, so they need to write a tree definition as a images yaml file and the preferred admin. Now. Usually, uh this is the platform team itself as well could execute the command to apply these definitions files, along with the operator resources onto the cluster.

A

In this way, the the capability will be registered on kubernetes on cook vela automatically, but then the developer users can just use the matrix as a cheat in their application objects and and finally roll out it uh to to dive note that, like uh there's, no need to restart or upgrade the platform itself. uh That's how um you see like that's how well I will will take the registration and handle this automatically and that that's you can see how cookware solves some critical team collaboration problems.

A

But there are many other features.

A

uh Then we don't have enough time to cover the details, uh notably like we have the application rule object, which is during the progressive road upgrade also at deployment uh object that can do multi-class, multi-revision uh application route and there's some health policy to do health checking and customer status that you can write some status with using q and there are some catalog environments, some control plane features as well, if you're interested please check out the website below and and secondly, uh let's talk about the dapper, so dapper is a polyglot distributed like application runtime.

A

So this means that it's it can work for multi languages. It provides like basic building blocks, such as state management, pops up, rpc, routing and actual programming models is etc as an extensible and pluggable design as a community driven open source project and also like providing consistent, portable and open uh apis.

A

uh It's a platform agnostic, which means it could run on cloud or edge like across different clouds, um so so that now, finally, let's take a look at how cook, valla and back are adopted and used in alibaba.

A

So alibaba, like contributes a lot to both projects um like we basically have like five committees on cube, bella and three committees on developer projects and and like they are widely adopted in alibaba, like we have more than 10 platforms like thousands of apps and like that, that's running them in production and there are solutions across wi-fi industrial scenarios.

A

So let me give a case study of how we use kubella and dapper to achieve application monitoring.

A

We first developed the matrix chait that basically uh translates the app commission values, which is the the port and also the export type into like kubernetes resources that actually made the dapper sidecar and dapper resources that will trigger the sidecar to connect matrix from the application port. The device sidecar will then pushes the matrix uh to open, telemetry uh collector, which will be a which is basically an intermediate storage.

A

um The collector will finally uh export the matrix data for s-turn systems to consume and display, and, and that depends on the environment right like for for uh open source uh users like they can use a chromophilus and grafana to to export the data to and and show it on, gofundme dashboard and for for cloud. uh There are other more smooth integrations like we can use alibaba arms services or cloudwatch or datadock like those kind of services to to get the matches and show it on dashboard uh all right.

A

So that's, basically uh all I have to talk about bella and dapper today. Also, if you interested definitely like follow us on cooper project and get let us know if you have any questions yeah. Thank you.