Cloud Native Computing Foundation KubeCon + CloudNativeCon Europe 2020 - Virtual, 4 Sep 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Using Argo and Knative to Orchestrate Media-intensive Services in 5G Edge - David Breitgand, IBM

Description

Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.

Using Argo and Knative to Orchestrate Media-intensive Services in 5G Edge - David Breitgand, IBM

Kubernetes is at the core of the cloud-native transformation. In this talk, we will discuss how Argo Workflows, Argo Events and Knative can help with cost-efficient and extremely flexible orchestration of complex network-intensive services on Kubernetes. We will discuss a Knative based deployment of Argo Workflow and Argo Events and demonstrate how we used these technologies in 5G-MEDIA (http://www.5gmedia.eu/) to orchestrate media intensive network services, such as tele-immersive gaming and mobile journalism in a 5G Edge. We argue that CNCF technologies can very efficiently complement traditional orchestration tools used by telcos, such as OSM, which are not sufficiently flexible to orchestrate highly dynamic session-oriented container based workloads of this kind.

https://sched.co/ZesQ

A

Hi, my name is david. This work has been done in collaboration with my colleagues, avi and pavel all three of us work for ibm research and we are based in haifa, israel.

A

Today, I'm going to share with you some experience from our journey into orchestrating media intensive services in 5g edge.

A

I will start by giving you some background and motivation and then I'll talk how we used argo and k native in our project. Then I'll show you a short demo and provide some concluding remarks.

A

This work was part of an eu horizon 2020 project called 5g media. As you can see, there have been many partners in this consortium we started in june 2017. It was almost a three-year project. We've been developing a programmable edge to cloud service, virtualization platform for media intensive application in 5g networks.

A

Ibm's focus in this project was on integrating serverless technology into the platform, helping the use case partners to leverage it for applications and harmonize it with the standard management and orchestration approaches such as etsy mana used by telcos.

A

Also, we've been an integration partner responsible for tying bits and pieces together so that they would play out nicely. So naturally, this included lots of orchestration work, both intra and inter use cases.

A

So, let's define our problem first, we want to facilitate third party applications deployment at the 5g edge. We want to do it cost efficiently, with instantaneous elasticity and have fast time to market.

A

It's difficult to achieve his traditional vms. We don't know in advance where and when to deploy them. We can cannot just deploy them everywhere in the edge waiting for events that may never come.

A

The amps are notoriously difficult to right. Size scaling out might be a problem scaling in might be even a greater problem. Pay as you go is not really what happens with the m, and there are many problems related to infrastructure.

A

So serverless many media intensive applications are session-based and event-driven, so what serverless can potentially give us is an ability to spawn cnf's container network functions just in time when needed and for the exact time duration. They are needed and it will be portable and it will take away the infrastructure issues.

A

So these are the use cases that we've been looking at in this project. Tele immersive media, we'll take a closer look just in a second remote media production, you're going to see a short demo of it and ultra high definition. Cdn. That's an extremely interesting use case where we dealt both with vms and containers, but obviously I don't have enough time to cover it. So we are not going to discuss it today.

A

Just to emphasize ibm was on the infrastructure side of things. The applications have been developed by other partners.

A

All right so tele-immersive media, it's a use case family actually, rather than a specific use case in 5g media. We use a tele-immersive game as an example of such an application, but this was just a demo to play this very briefly. There are two players, so here are two players: um each player is in a specific geographical location, but they are close enough and use the same. 5G media slice.

A

Each player is surrounded by four cameras producing a time varying match stream. The players are embedded into a virtual world in which they can freely move in any direction.

A

The players interact via a cnf container network function called virtual broker, the broker for sure the broker starts at the beginning of a gaming session and lives throughout the session. Spectators can join from anywhere at any time, then they might have very different terminal capabilities.

A

Of course, they can also leave at any time those spectators who have ar vr equipment or high-end equipment, and that close enough to the players and enjoy good 5g local coverage might consume. Time-Varying meshes directly from the broker.

A

Other spectators see transcoded two-dimensional video, where the service automatically maintains a mixture of transcoders, with one transcoder pair transporting profile to optimize the total quality of experience for all spectators and to do it at the lowest price for the provider.

A

Spectators also can move freely in the 3d virtual world, but they are unseen to the players and to each other. If a spectator joins from a remote location and she's the first one, there we span another broker at that edge and connected to the main one so that every frame produced by a specific transcoding profile is delivered only once over. The expensive long fall links in if an event of interest occurs in a game, a v-replay, a virtual replay cnf, is being provided on demand.

A

It creates a clip that shows, for example, how one player has grabbed the flag and how interesting it was from the sport point of view, and so on. So you've got the idea, and I hope it's clear why serverless is a good paradigm for this type of workload.

A

Mobile journalism is another use case and, as its name suggests, it's about producing a live contribution with production support functions, set up on demand in the 5g edge itself. Close to the event. Basically, a journalist working for a broadcaster is involved in some newsworthy events, so she uses her application on the 5g mobile phone to talk to the part of the application running in the 5g media platform collaboratively the application and the platform select an optimal edge to spawn production support functions based on the journalists selection of functionality.

A

In this example, the journalist selects speech to text and face recognition functionality as supporting production. The choice can be different in another session or it can change in the ongoing session. So after the edge is selected.

A

The v-splitter v-detect and this speech are spawned as a function as a service orchestrated to work together, and this splitter is externally exposed as a service. The video comes into a splitter, a splitter forwards it to this patient. We detect, which produce the metadata upon finalization of the session. The metadata and video are synced to the non-volatile storage and the broadcaster is informed that the contribution is ready. The broadcaster fetches, the files merges them edits them and introduces them into the news program.

A

Similar applications are in use today, so it's not such a big invention on the application side, but uh making a full production remotely on demand just in time, so that it shortens time to. The news. Broadcast is a new opportunity for the broadcasters and it can make a real difference for them.

A

All right, so uh this is all good and nice, but uh when we say that the applications are executing at the edge, what do we actually mean by that conceptually 5g media forward, the etsy multi-access edge computing mac framework architecture?

A

It's not important to understand every little detail about the mac architecture. What is important is that there is a cnf for something that is called mac platform.

A

This cnf runs in close proximity to the 5g, ready access network and offers services such as, for example, function as a service to the applications.

A

That run in the mac hosts.

A

This would be a good point to make a distinction between serverless that they use so far in this presentation and fast serverless is a broad concept and when I say serverless and everybody in this audience can think about something. Different fast is a specific serverless programming model where the level of abstraction is a function, not a container or a service that scales to zero. So, for example, k native is obviously a framework for developing serverless http servers, but it's not fast. It's not function as a service in general.

A

Every fast framework is a serverless framework, but not every serverless is fast, so openwhisk. That is the logo that is shown here. Openvis was our serverless was our fast framework, basically okay. So let's move on um a typical use case for fast in mac is iot. We pushed an envelope a bit and we use it for media intensive applications.

A

As I said, we use apache openvis as our fast framework and the functions run on kubernetes, so basically apache open risk of loads functions to kubernetes. That's a standard feature in apache, open, whisk and kubernetes serves as our network function, virtualization infrastructure, all aspects of mac, including the application themselves, are managed by manual. We used open source manual, osm um and sam can be deployed anywhere. It can deploy it somewhere in the cloud, for example.

A

So uh this is our environment. In a nutshell, and at this point you might be wondering- um where is argo? Where is canadian and what about the orchestration so we're getting just just getting there.

A

So remember I told you that it was a journey for us. So initially we created this osm openwhisk plugin, and this allowed us to leverage kubernetes, networking and shadowing while maintaining high level of fast abstraction by using openwhisk.

A

But then we understood that we cannot really orchestrate serverless applications with manu. What we needed to do was to store some functions upon service instantiation. Potentially, nothing should be started upon. Instantiation upon some event, for example, originated in an application in the application itself start more functions, configure the rest of the service to work with them. Then, when this function is finished, they die out, so the service should continue.

A

So it's reconfiguration and we do do it again and again and again with custom management flows, and we wanted to have for the network service developer and operator. We wanted to have for them. The kubernetes native experience we had with manu was no real modeling concept for serverless, no custom management flows, no natural hooks uh to cater for events, no kubernetes native devops experience and increasingly it felt like an exercise in fertility because we were trying to orchestrate containers from outside of kubernetes.

A

Better than kubernetes would do it itself, and that was exactly the point where we've discovered argo about one year. One half year ago.

A

Now I need to walk you um quickly through this animated diagram, because it understanding it is important to understanding the demo that I'm about to show. So we have kubernetes. We have argo workflows and argo events installed. I spliced gateway and sensor controllers into one line, but they are separate controllers. Of course, it's just for breathing an administrator awesome application, automation, script, requests an instantiation of a service package previously on boarded to osm.

A

Let's say for the sake of the discussion that the functions are uh by the way I should have called them c and fs, not vnfs their name, bootstrap, the nf1, vnf2 and then f3 bootstrap is a special function that service developer persona adds when she assembles services from individual vnfs.

A

That's uh our invention, our addition um to the method, um and it will become clear in a second. What we mean by that osm would unpack these functions in the order of a pure appearance in the service package, one by one, so bootstrap would go first and then f1, then f2 and f3, and so on now each time um osm unpacks a vnf, a vnf descriptor.

A

It requests a fast swim to instantiate. It in the background there is a polling task that continuously pulls vim to get the metadata of the vmfs, that it asked the veeam torque to instantiate, for example, ip and port of these vnfs. So bootstrap goes first, okay, now the first thing that it does. It actually applies gateway and sensor yaml crs to kubernetes.

A

And then what happens is that controllers of the gateway and the sensor pick the cr up? They are watching them and then the gate and sensor pods start executing.

A

Together this pair gateway and sensor is what we call serverless orchestrator.

A

Now the entry point for the service orchestrator is gateway, it's exposed externally as a service, and it's a private serverless orchestration for this service. It can be very customized to this service now uh because of this polling. In the background, the metadata about the gateway um can be added to the metadata of the bootstrap, this url of the gateway, and now you can question osm and get uh this url, and this is your handle for orchestration.

A

Now, at some point request, an http request just comes into the gateway asking to instantiate serverless, fast vnf1 and vnf2. Okay, so what happens? Gateway passes it to sensor. There is a payload on the message with the operation and day zero configuration and sensor conditionally triggers argo workflow. That just does the orchestration.

A

So here the argo workflow appears and it runs using the argo, workflow controller and then uh instantiation and configuration of enf1 and the nf2 just happens, managed by argo workflow. Now after that happens at some point in time.

A

Another request comes in, for example, to instantiate the nf3 and then a similar thing happens. It goes to sensor sensor triggers another orchestration flow, okay because of this polling happening in the background you see that the metadata such as ipn port of the functions also is propagated to the orchestrator, such as osm okay.

A

So it's not uh very complex, so essentially that was step two of our journey, so what they created on the right side. It's uh basically serverless orchestration, based entirely on argo, workflows and dargo events to orchestrate everything we had to orchestrate in our use cases and across use cases which was related to fast and event-driven activities.

A

In this architecture, every service has its own customizable, event-driven management and orchestration plane running entirely in kubernetes, the service developer persona gets all these different cnfs from network equipment providers and assembles them together into services and along the way she can now create kubernetes native orchestration flows with argo pack. It in a standard way with by using this bootstrap configuration just adding a couple of yamls there, which will bear uh this configuration when instantiated would create this gateway and sensor and bingo. You have your service orchestration for this instance of the service um all right.

A

So this is all nice, but uh then we scratched our heads and said: uh hey gateways and sensors would proliferate in this architecture.

A

Wouldn't they even if there are no events to orchestrate the gateway and sensor pods still sitting there and consuming resources yeah, it might be peanuts for one service, but across a portfolio it can amount to some serious figures, and somebody has to pay for that and it's not exactly pay as you go right, so we decided to make both gateways and sensors canadian services and I'll show you how it worked out in a second you're. Welcome to check the repository that contains k native events fork to see if it what we did make sense to.

A

You also we'll be happy to hook up his argue events folks to hear what they think. In any case, we thought- maybe this can be a good feature uh in argo events, irrespective of our specific use case.

A

Okay and now it's time for a demo um right, so the demo uh will be based on on use case of mobile journalism. This is just to recap. I hope you still remember this splitter face recognition, speech, recognition, rtmp server in this demo, splitter uh image face recognition and speech. Recognition will be really fast functions and rtmp is pre-instantiated.

A

Okay, so, let's see will be a very simple demo without osm and to the end, also without open whisk, we'll just spawn post directly on kubernetes, so uh we just apply gateway and sensor yamls, as if that bootstrap function would do it, but we can do it directly right. So that's exactly what we are doing now, so we've applied both uh gateway and sensory ammos and they start executing. You can see it in the middle window.

A

At this point, the service is on boarded on kubernetes and it's ready for orchestration, but there is nothing to orchestrate. There are no events, so why waste resources, since our implementation is based on a k native for both gateway and sensor, then after a grace period, they should scale to zero. So, let's fast forward a little bit. Oh they start terminating, so uh gateway gateway goes down first scales to zero first and then the sensor scales to zero.

A

So give it a little bit more yeah, let's fast forward.

A

Okay, yeah so in the middle. uh So at this point the service is there, but gateway and sensor are not consuming resources and now to the orchestration part on the left, you see the application progress. Okay,.

A

So at this point, gateway receives an http request, asking to start a new session for mobile production and the sensor triggers the orchestration flow that we follow in argo gui we expose uh in this demo. We expose every port is not port.

A

So that's why you see so many of them and in the uppermost window we can see which pods are actually running right now, so we see that splitter turbo detector with speech.

A

Everything is running and there are some completed steps. These supports that. Basically, argo was running to complete uh the management and ex and orchestration flow related to the session. Okay. So at this point everything is ready and stream uh content starts go into the edge into the splitter, and you see in the bottom window that media files start accumulating.

A

We just use some test file here and just playing it right. Just simulating a journalist.

A

It's not a real event that we are showing you just some tests.

A

By the way, did you notice that in the middle window the gateway and sensors started to terminate, because there are no events right now to orchestrate? So they are not basing resources anymore, they did the orchestration part, and now they scale down to zero again. Okay.

A

So at this point, um basically we are drawing to the conclusion yeah the stream is completed, and so the media files and method that are created- and we just need to finalize the session uh which includes maybe terminate you know, for example, creating the urls for the files and notifying the broadcaster.

A

So let's see what we've got in our test file.

B

Time is what stops everything from happening at once.

A

Oh, uh there is no.

B

I wish my voice would be like for there not to be time.

A

That was not something that I.

B

Was like, I think we experienced anyway, there is a face recognition here.

C

I actually don't think it's that mysterious we live in a world. That's.

A

C

And this world happens over and over again with the stuff in slightly different positions,.

A

They are talking about time, there's a physicist talking about time, so my time is up or almost up. Thank you for your attention. This concludes the demo and now I want to provide some remarks as I'm concluding remarks. So uh first thing uh argo was a lifesaver for the project.

A

We found it really really delivering on its smartphone, getting things done with kubernetes, and we love that um remember. I was talking about the journey, so at this point in our journey we started wondering that maybe we do not need other orchestrators at all. Maybe kubernetes was just enough and just see the demo that I've just showed you right.

A

Everything has been done by kubernetes, argo, argo events and so on. So uh indeed, what's the osm role in this architecture, or even if it was something else, for example, it was on up, for example, instead of it. What would its role be? Of course there are many more uh topics than orchestration. There are, for example, oss, bss governance whatever, but orchestration.

A

Maybe we just need kubernetes and at the very least I would say that even if traditional orchestration 8 engines are still around much more functionality should be delegated to kubernetes, as it can complete a lot of stuff autonomously.

A

I'm sure many people might disagree, but I'd rather to spark a discussion about this.

A

Another point is that we basically followed mano mindset, because that's how we progressed in this project and manu is very workflow oriented but workflows and not really kubernetes native style for orchestration. Admittedly, we pushed the envelope here. We used argonaut for data pipelines orchestration by the way we are doing this in another project, but for a network function virtualization orchestration. But if you want to be kubernetes native, we need to have sort of never-ending workflows, because we never really deploy anything in kubernetes and assume that applications components are continuously failing.

A

So operators are more natural in kubernetes and we're looking at them, but we don't want to cancel advantages of the workflows, so this journey kind of continues, and hopefully next time I will be smarter and can share some answers to these questions that they pose. Until then. Thank you very much for your attention. I will be happy to answer your.

C

A

um Hello, um so.

A

Hello, um thank you very much for um um coming to this session. um It's a little bit uh like experiencing out of body experience kind of I see myself from the outside, so I don't have the contact with the audience and it's a bit difficult. But let me let me try answering your questions if you have any um so, let's go to the chat.

A

A

Let me go to the chat back.

A

A

All right, so uh one question was about whether this is a reconstruction of the players. It was about the first use case that we have about tele-immersive media. Yes, it was a 3d reconstruction of the players. It's a time-varying mesh.

A

It's a very heavy uh application on traffic. You, you cannot uh achieve it on scale for um for gamers, without moving to really to this new generation of uh of the net network of the mobile network, known as 5g. It's a very 5g use case.

A

These uh people um are actually moving inside um a virtual reality. It's a virtual world. They can move 360 degrees in this world, and this is what was also another question of what tele-immersive gaming actually. Is it simulates your presence in in this world and contact with other gamers?

A

So basically, the next generation of these games is going maybe to have a haptic response uh so that if somebody throws something, it's you in this virtual world you're going to feel it so you're going to feel pushback and stuff like that. So this is. This is a family of use cases. Basically, it's not about gaming. It's also about learning it's about um teleconferencing.

A

um I think that uh if we had had a platform like this uh at this time, then maybe our experience at coop con 2020 would look a little bit different. Maybe you could throw some things at me and I would feel it for my bad answer, so you would upload. I would hear you and all that without you know, special sensors just using cameras and gestures and stuff like that, any other questions.

A

um Okay, I'm familiarizing myself with this interface. As I go so question seven, I don't actually see.

A

It so question seven, I don't see questions I only have quit. um Okay, thank you. Argo functions streaming media or are they just passing files? Okay, the role of argo is in orchestration.

A

uh You have two projects right, argo workflows, which is currently a part of the cncf sandbox landscape. I think- and you have- um and you have argo events which is not yet part of cncf.

A

In both cases, both argo workflows and argo events. They are just about orchestrating things triggering resources in kubernetes and one of the resources can be a workflow. Now the actual job is being done by containers which we pack, which are obtained from serverless functions. So basically the developer creates uh things like transcoders, for example, in whatever language of choice.

A

We had some functions in a created in in python and we have some functions created in java in in node.js, and we had something in c plus plus. So, basically, wherever you can, you just create these functions uh on um on the fast framework and then containers are created for you. You don't need to think about containers.

C

A

Are managed by kubernetes, and by this you can you can have all the advantages of the kubernetes scheduling and networking and and stuff like this and with argo. You can also have orchestration, but argo itself doesn't have to do anything with you know streaming media or passing media or doing things like that.

A

Wouldn't it be better to use om argo workflows instead of openvis to bootstrap our goal um workflows instead of openvis to bootstrap the production of argo events. I guess this general pattern can be applied also to ym argo workflows. I'm not sure that why amargo workflows have been around when we needed them, but we definitely because it's it's. The project actually started three years ago, but um I think we definitely need to take another look at this. Thank you thanks for the lead, so thank you very much for coming.

A

I will be lingering for another 15 minutes, at least on slack and I'll, be happy to take your questions from there.

A