Kubernetes IoT Edge Working Group, 4 Dec 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Kubernetes IoT Edge Working Group: Using Event Driven Architecture at Edge - Steven Wong, VMware

Description

Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon Europe 2021 Virtual from May 4–7, 2021. 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.

Kubernetes IoT Edge Working Group: Using Event Driven Architecture at Edge - Steven Wong, VMware & Dejan Bosanac, RedHat

Many use cases at edge face resource limits which challenge the deployment of full K8s clusters, or even single nodes, at the edge “leaf” nodes. We will introduce some techniques that can be used to process edge generated data and commands using Kubernetes hosted applications and services in a loosely coupled tiered distributed system. Agenda: - Characteristics and challenges of Edge Applications. - Introduction to event driven architecture - What is it? How do you deploy and manage it at edge. - Using open source based event driven tools to host data collection and IoT processing on small devices feeding into K8s hosted applications and services. - Demonstration using edge generated CloudEvents with a Kubernetes hosted application. - How to get involved in the K8s IoT Edge Working Group.

https://sched.co/ekH1

A

Hi this session is presented by the kubernetes iot edge working group. This is about using kubernetes for edge applications, I'm steve wong, a tech lead of the working group. I work on kubernetes and a few other open source projects as an employee of vmware, hey my name.

B

Is dan I'm an engineer at red hit been doing a lot of iot and edge computing in the last couple of years, and also a lead of the this working group.

A

We'll give contact information and a link at the end, but here's the agenda we're going to start with a quick overview of what the exact definition is of edge applications. For the purposes of this talk, then we're going to move on to an introduction to some techniques and open source tools that are really useful when using an event-driven architecture at edge.

A

Hopefully you like this talk and if you do we'll wrap up with details on how you can become a member of the kubernetes iot edge working group, where we host ongoing discussions on subjects like this talk for the scope of this talk when we say edge application, we're not confining ourselves to just the software that runs on individual edge devices.

A

Sure there's software there, but if you're interested in getting kubernetes involved, we're going to assume that you've got multiple devices involved but are also using containerized software at some location, perhaps multiple locations that could be a high-level gateway, regional tiers or even a global tier. Our definition of an edge application is the big picture where you've got software interacting from various locations simultaneously.

A

So if this is what you're setting out to deploy and manage, you have a need for data and control, plane, communication from edge devices up to higher level tiers, and you might also want support for edge node to edge node interaction as well.

A

A lot of people have fallen in love with kubernetes lately, and it is a great tool for orchestrating containerized apps, but it's also extensible as a control plane. The fact is that, when it comes to some edge use cases, the devices simply have too little resource to run software in a container or as a kubernetes worker. Note.

A

Yes, if you've got pies with 4, gig or now 8 gig of memory, these are quite capable and you could turn these into kubernetes worker nodes. But there are a lot of far tinier devices like arduinos, where memory is measured in low single digits of megabytes, we're going to talk about a technique that can invite the little devices to the party, while still supporting containerized software running in your higher level, tiers simultaneously.

A

So, in a simple form, an event driven architecture looks like this. An event is a piece of information, often used to communicate facts like measurements or commands like statements of intent, functions and services, consume events, and it's up to these applications to decide what to do with the event. Events can be ignored, forwarded stored or transformed in a time series of events, whether the events are measurements or commands, a newer one might make an older one irrelevant if a buildup occurs somewhere in a queue.

A

Analysis of events might emit new events based on a transformation in a distributed system, an event stream is a communication fabric and when the apps and events flows are viewed together, this is actually a programming model event. Driven architecture can be helpful because it encourages some good program. Development practices, loose coupling independently maintainable components and separation of concerns, a distribution layer can help organize things and maybe even offload things you might otherwise have to write yourself.

A

An example here is a pub sub broker, eliminating the maintenance of a distribution list from the duty of an event publisher,.

A

This is a metaphor. This is how a restaurant often works in the real physical world. There are various people involved, shouting out combinations of desired state and notifications of state changes. You listen to what concerns you. You ignore the rest, so in this example, I've got a customer who shows up asking for a table for one for lunch, eventually getting assigned to a table, making an order and the waiter passing along details on that order into the kitchen.

A

Let's take a look at an alternative flow of what a restaurant would look like with a microservice implementation.

A

Yes, I think you could get it to work, but at what long-term cost, what if the menu or table layout changes, what things have to get touched now understand at many edge locations, devices often have various uncoordinated life cycles and business operations might change, maybe even seasonally.

A

The loose coupled nature of event-driven architecture with independently maintainable components and separation of concerns can really be attractive at edge. By the way, I want to shout shout out to simon aubry of thoughtworks for coming up with this nice restaurant metaphor for describing how event driven might work at edge so event driven can can originate on devices below what I'm calling the kubernetes uh water line. There are some very simple protocols like mqtt that can be implemented on things like arduinos, particularly if you can afford to skip tls.

A

I know skipping tls is risky sometimes, but maybe you already live with unencrypted traffic operating on localhost with you know, within an individual system. So this concept is nothing new. By skipping encryption there is risk, but if you're connecting isolated devices that are not connected to the internet with some semblance of physical security, maybe this is an affordable trade-off.

A

The bottom line here is that there are solutions for very low end devices and if you have larger devices, there are solutions with bigger feature sets uh at gateway and higher tiers, you're likely to have plug-ins to support uh all the various open source, tooling availa available for eventing, and you can probably afford to turn on full security.

A

So here are a few uh words of advice that I've discovered out there with regard to designing an open and event-driven architecture for edge view. Your when, when you persist events view them as a persistence of a replayable stream history, uh you don't want the event. Consumers tied to specific producers view your events as a record of something that has happened, and so it can't be changed. You can't change history.

A

Messages on common delivery platforms often have certain characteristics, and there are certain things you should do and shouldn't do. Rules can be different across latency boundaries so that if you've got a failure domain and a latency domain, you can do things that maybe you should avoid when you're crossing those boundaries.

A

Synchronous might be okay within a boundary, but really that's an anti-pattern when you're crossing a big latency chasm.

B

Thank you steve. So uh one of the answers to to uh serverless rtos to event-driven architectures in in the kubernetes land is uh is uh k. Native inventing, specifically uh k native eventing is, is all about uh yeah.

A

B

uh Hooking up our k native services with appropriate uh event sources, so this diagram basically explains it in in a you know, you know a most uh simple way, so, basically, we have a source of our events which have a sync and that sync goes to uh to appropriate service.

B

uh Also, one more important detail here uh is our cloud events and and the cloud events provides us a structure to to our events, so, basically adding all the metadata that we need uh to to describe our events and and to have some consistency within our serverless applications uh and from that consistency uh comes accessibility, because then we can uh create an apis in you know, in a lot of different different languages, and- and you know, port, our our solutions and our services or our functions uh to different different environments.

B

uh Here we can see see one of the example where, where a cloud event basically adds it's uh some metadata and the data to the to the picture, uh how this looks in practice is something that that will uh demo at the end. At the end of this talk. So basically, uh what we have here is uh an edge location which run in uh steve's home, which contains uh a apache mqtt broker and and the small devices that are connected to that broker and sending sending uh their telemetry using using nqtt.

B

What we will do, we will use a comma k uh and and connect to that that broker basically uh getting all these mqtt messages, uh converting them into the cloud events and and and and pushing them to our sync, and in this demo the sync will be simple event display service, which will log these cloud.

B

Events to the console camel k originates from the apache camel project, which provides a very rich framework for for doing enterprise integrations and the camera k is basically uh a k, native uh uh implementation or adaptation of of all the camera components, and, as we can see here, we can use any of the available uh hundreds of of camel uh uh connectors uh to connect to different external systems and and uh convert them automatically to to the uh native eventing sources.

B

uh If you go to the next slide, we can see how the the k native uh uh okay native uh architecture evolves, because you know hooking one source to to one service is easy enough, but but but not enough to support all the use cases.

B

That's where we can uh bring in the the concept of channels and and with with sending uh an event from the source to the channel. We can now have multiple multiple uh services subscribing uh to the channel and and receiving all these events channels can be backed by different uh source. uh Different persistence.

B

Techniques, so in in-memory channels we have uh traditionally often use kafka channels, backed by by the uh the kafka broker, which provides a a really really good solution uh uh for for uh implementing uh iot mqtt solutions on on serverless uh extending this concept even further. uh On the next slide, we can see the concept of of uh of uh uh uh k native inventing brokers, which basically uh uh function in a similar way as as uh as a channels.

B

The only thing is that, instead of the subscriptions uh now we are defining different triggers uh for the broker, that will that will uh push events to different different services, and the only difference is that for the triggers we can, we can add a different kind of filters so that that we can say that that we are interested in only a certain type of of of cloud events, while we're doing while we're doing this.

B

And finally, if we take all this into the consideration on the next slide, we can see a little bit uh evolved scenario where, where we can, with with this uh kind of architecture, we can support multiple things. So we can have a we can.

B

We can support scenario that that we will demo soon, where we have a small uh small embedded uh devices connecting over non-tls to the local barco broker on the edge side and then having uh having a camel mqtt converting uh subscribing to the broker, converting those to the to the to the services and uh to the cloud events and sending it to the channel.

B

But we can also imagine that we can provide a a new components, naming mqtt broker source, that that would act to the external systems as an mqtt broker and where we can allow more powerful devices which can support tls to connect directly to the cloud to to this to this source, which will also uh transform these mqtt messages coming from the devices into into appropriate cloud events and sending them to the channel.

B

The channel could be backed by by kafka, providing all the the the persistence and reliability that that we would need in such a solution and then push these two to different uh different services. So event display service, which is like most basic one, that we can imagine that can be used just just for debugging purposes, but most commonly you will push this to some kind of influx db or prometheus, backed by a grafana dashboard, to have more better of observability and and be able to create different dashboards.

B

Where you can, where you can see, see all these data. So this is uh a call for for action uh on on the next slide and something that we can.

B

We can try to solve uh uh in the in the in the working group and and trying to to make mqtt, which is the default iot uh messaging protocol of a first-class citizen in the k-native inventing world.

B

This is you know. All the examples shown here is is just a tip of the iceberg: iceberg uh showing how things could work, but there's a lot of things that that usually in this kind of systems, needs to be solved like uh device security and and sending commands back to devices.

B

We can provide a lot of integration with the existing rtf platforms like eclipse, honor or aws or azure.

B

Offerings in this area uh provide an easy way to to to run all these using different, clies and uis, and and provide some of these services out of the box that you know, people can get really really quickly to get started with, with the with iot, on on on a platform like like this and finally uh uh do something: uh uh an extended extending uh a solution like this to to the multi cloud or or, let's say, edge edge nodes uh uh environments using using uh uh something like uh like a scupper.

B

And if, if you're interested in in that topic, I would suggest you to to take a look. Take a look at the recording of the video of of the of of another session by my colleague ted, which is happening at the same time as as this one, which explains a little bit more of of how how serverless uh uh workloads can can be pushed from from the edge to to the cloud to the different clouds and different serverless deployments.

B

So for the end, I would like to do uh to to go back and and do a simple demo of of of all this. So let me just quickly share my screen and and try to try to do that, uh steve, uh I'm not allowed to so here we are going going back uh to the to the original idea, having one source and one sync and connecting them via cloud events, as I said, uh uh our service is is, is a very simple.

B

I think the simplest possible k native series that that we could have it's named, camel event display and, and uh it uses the event display image. So what will what this image will do it? It will just receive events on its serving endpoint and and log them to the console, uh and our source will be.

B

Let me do this like this, so it's it's a it's! It's visible better, so we're using camel source uh k native uh eventing uh come with a lot of uh out of shell shelf uh sources and camel source is, is one of them and, as I explained earlier, once you have a camel source you, you can use different, different chemical components to to to connect to different external systems.

B

So right here we are using the pajo uh pajo uh component, which will uh connect using the paco, mqtt client to us a broker. uh This is just a template because we don't want to give a steve's mqtt broker details to the public, but uh it will connect to the steve's mqtt broker, running it at his home, uh using appropriate username and password and connect two to one mqtt topic in this case.

B

Topic is a w date saturday at the slash temperature, one f, uh uh assuming it's a it's a temperature temperature sensor and uh that in in this camel source we can see that this is. uh This is a definition of of of our source.

B

You know in in the down part here we we here, we see how we can do a definition of the of the sink and for the thing we can see that we are directly calling the the service and and the service will be, the the aforementioned camel event display display service so to not disturb demo gods.

B

I have all this uh running in in advance, and what we can see in in this other other uh window is that uh we can pick up now the the the logs uh from the from uh coming from the from the uh from our from the pod uh serving serving this event, and as we can see, uh these events are uh mqtt. Messages are now uh uh changed to different uh to appropriate cloud events.

B

uh We can see uh some of the the the metadata the headers of the cloud events like type which meaning that it's generated by the camel component uh from which source is coming, the the the time step of the event and then finally, uh finally, the data, so the data now is 74.12 fahrenheit degrees. I I assume, uh and if we go back to the to the definition of our source, what else you can see here is that I have uh commented out a different thing.

B

So, instead of going to directly to the service, we could go to the in-memory channel or kafka channel or or or some kind of broker defined by the k-native infrastructure and implement all these other other architectures that that you saw on on the slides on the slides before so so. This. This is an example of of another service.

B

uh So, uh basically reading the events coming from the steve's mqtt broker, uh pushing them to the to the uh influx db and and then having a grafana dashboard connected to that input vp and showing this uh this temperature in the real time.

A

So if you find content like this useful, we want to invite you to become a member of the kubernetes iot edge working group. We're not really writing code on kubernetes, but we are focused on applying kubernetes, with open source tools to edge and iot use cases.

A

We have online zoom meetings every two weeks at alternating times to accommodate members in different time zones, as shown here. There's one series uh earmarked for north america, the other one for eastern europe and china. We encourage a member-driven agenda so once you join, you can nominate topics for presentations or discussions.

A

We're also operating a group channel on the kubernetes slack.

A

So we can be contacted using our github ids that same id as my twitter handle it okay. So these are our github candles and you can use that to reach out to us or we're also available on the kubernetes slack. You see here on this slide the link uh in the sked site to get a copy of this presentation. Deck yeah thanks for joining us for this, and we're going to hang around for a few minutes to for q a and at this point, I'm going to turn it back over to the cncf administrative.

A