Cloud Native Computing Foundation Kubernetes on Edge Day EU 2021, 14 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Develop once, deploy anywhere: flexible infrastructure extends to the edge - Frank Zdarsky, Red Hat

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.

Develop once, deploy anywhere: flexible infrastructure extends to the edge - Frank Zdarsky, Red Hat

Edge computing use cases can be highly diverse: Workloads ranging from cloud-native web services to AI to real-time control to legacy virtual appliances. Hardware footprints ranging from micro data centers to embedded compute units. Environmental challenges on networking, security, energy, … How do you go about solving this? When is Kubernetes the right choice and when not? What is important in a Kubernetes distribution for the edge and what is not? How to ensure your dev+ops complexity doesn’t explode? In this session, hear how to address many of these challenges and provide the flexibility to scale with the tools you’re already using.

A

Hi everyone and welcome to this kubecon on edge virtual session about develop ones, deploy anywhere flexible infrastructure extends to the edge. My name is frank starsky and I'm a senior principal software engineer at red hat's office of the cto.

A

For almost two decades now, there's been this trend for businesses to centralize its services in large data centers on public cloud and that made sense respectively. It still makes sense in many cases, because this way they can leverage economies of scale, outsource infrastructure operations and capital expenditures to somebody else and somewhere else.

A

However, most businesses are still brick and mortar. Their production has a physical location. Their customer contacts happen at a physical location.

A

Edge computing is gaining momentum exactly because businesses are increasingly discovering the value they can generate by bringing services again closer to where they are needed, where their operations are or where the data is edge. Computing and cloud computing are somewhat counter trends, but they are not an either or decision. In many cases, services will be distributed between cloud and one or more tiers of edge computing, with hundreds or thousands of deployments.

A

For example, many businesses start with collecting data and pre-processing it at the edge while aggregating and storing the data for later analysis. In the cloud over time, though, businesses then discover they can generate even more value to their operations and their customers if they not only collect more data but also analyze it and take decisions and actions locally. At the edge advances in artificial intelligence in robotics in imaging visualization in real time process control, they will further increase the momentum back towards the edge.

A

The challenge in adopting edge computing is, then that use cases are extremely diverse and so is the edge computing infrastructure in support of these use cases. Let me give you a couple of examples from our customers. Folks, coming from iot tend to focus on devices like sensors and actuators that are microcontroller based. They only have a few tens of kilobytes of memory.

A

Without memory management, these devices run free, rtos, arduino, but not linux and most definitely not kubernetes others, looking in automotive, robotics, smartest place, etc, often interested in single board, computers that have lower end intel or arm cpus a bit of ram but all kinds of networking, and I o already on board talking to people from telco, about 5g or from manufacturing about process control.

A

They tend to require powerful servers with lots of cores in ram that are extensible with all kinds of specialized hardware accelerators and are remotely manageable.

A

Now, if your business use case requires some services at the edge and others in the cloud will be wondering what kind of infrastructure to support this with to keep end-to-end service development and infrastructure operations as simple and consistent as possible, and to be able to evolve your architecture by adding or moving services later and a typical response, I hear is why not simply run kubernetes everywhere.

A

So let me briefly discuss when kubernetes is the right choice for the edge and when it isn't, there are two fairly obvious cases: if the services you'll be running and the load on them is known in advance and stable over time, so you can right size your hardware, to the use cases, if you don't need high availability, if you're embedding a computer unit and therefore can only ever fit a single unit anyway then realize you do not need a container orchestration layer and no matter how lightweight this layer is you're, better off, using something like podman as an extremely low overhead way of running parts of containers, updating, restarting them, etc.

A

On the other hand, if you do not know your service profile or load in advance- or it may change over time or if you need multiple compute units to provide higher capacity or higher availability, you'll eventually need clustering and orchestration, and then kubernetes, of course, is really your best. Your best choice, I often get the question, though you know, is there a case where anyone would run a clustering solution like kubernetes on a single node? Is that something between these extremes?

A

And the answer is that it's a good idea to decouple the design time decisions of platform to develop against and how to operate it from the deployment time decision of how much capacity and availability a given deployment needs.

A

Not all edge service areas have the same load on services and not every service area is important enough to have redundancy. Therefore, you may deploy one node for some areas and three and more nodes for others, and then it doesn't make sense to develop against different targets or use a different management approach.

A

You'll notice that it's mainly operational criteria that decide whether kubernetes is right or not. The currently and protected workloads, the load on the system, the need for high availability, the security, the performance to cost ratio.

A

Consequently, when choosing a kubernetes distribution for your edge use case, your primary decision criteria should be whether the distribution adapts to your evolving use cases, maybe running some web services and virtual appliances today and hardware accelerated video analytics tomorrow, whether it scales to your capacity demand both in terms of number of nodes, but also from low resource single board, computers to high-end servers where that comes pre-integrated with the linux. That's designed for edge computing, for example, by being able to update and auto roll back, transactionally makes bars, use of networking, etc.

A

Whether the way you develop services or manage deployments scalably is consistent across all the footprints from cloud to the device edge.

A

Interestingly, though, developers, starting with edge computing, pocs, often initially focus on criteria like whether cuban distribution runs on their favorite linux distribution or it uses, let's say, 800 megabyte memory instead of one gigabyte memory, like other distributions, considering the cost of ram these days and the much higher transitioning effort from pocs into prioritization, this really shouldn't be high in your priority list, but look into these other criteria.

A

A

In that context, let me just briefly highlight a couple of open source projects that we at red hat believe, are super relevant for edge computing and are therefore, and we are therefore investing into them on an operating system level.

A

We are investing into rpm, os3 and green boot, and they together allow safe transactional, operating system updates and auto rollbacks, because the last thing you want to do is to brick a field deployed device that you cannot service later on secure device on board to take securely, take ownership of devices and to have an optimized supply chain from your hardware vendor to your deployment sites, lime for remote attestation.

A

That devices haven't been tampered with on a kubernetes level. It's about the ability to download operators from an application store that extend your cluster's ability to manage non-kubernetes resources or non-native resources, as if they were kubernetes native resources, for example, virtual appliances using the cubework project or by metal servers using metal cubed and that's very powerful, because modeling resources as kubernetes resources, allows you to manage everything in your edge. Computing stack using a single set of skills and tools and that vastly simplifies operations on an operation management level.

A

We are investing into tactile and algo cd to manage whole edge computing deployments from the infrastructure to the clusters to the services using github's principles, also using open cluster management for observability auditing and to apply policies and enforce policies to clusters.

A

So far, of course, we've only talked about edge computing infrastructure and, of course, it's the services on top of this infrastructure that solve your use cases unfortunately discussing those would be a completely separate talk. So let me just name drop a few on this slide that we're actually using with customers to solve industry. 4.0, predictive maintenance use cases.

A

Thank you very much for attending and please contact red hat or myself in case you'd like to learn more details.