On Mon, Mar 7, 2022 at 11:52 PM Ali Ok <aliok at redhat.com> wrote: > Hi, > > I recently read a number of articles about how to offload workloads onto > containers that run on vehicles. TheChief IO article here [0] summarizes > some of the things tried out there and these are the experiments I've read > in detail: > > - Mercedes-Benz did a POC [1] where they run containers in a vehicle to > run relevant tasks. The focus here is on the development and CI/CD of these > software. > > - Denso had a similar POC [2] [3]. They ran an entire Kubernetes cluster > in the vehicle. Again, the focus here is the development ease and CI/CD. > Development teams simply develop and distribute software just like a web > application. There's also mentions of used concepts like digital twins, > request queuing (in the vehicle when offline) and few other interesting > concepts. > > How do these efforts align or relate with the automotive initiative? > What I understand from CentOS automotive SIG and the POCs I mentioned > above is that there are a lot of overlapping areas (being independent of > the underlying hardware, faster software distribution, etc.) done in > different levels (OS/Kube). > Some of this aligns well with our current initiative, while the other seems wildly unrealistic to me. We believe that deploying applications in the car via containers is a good idea for a couple of core reasons: * More isolation between apps at runtime means more robust, safe, secure software. * Containerized applications can be updated and managed independently of each other and the host os version. * Containerization enforces a development model with strict interface boundaries, similar to what you'd call a "microarchitecture" in the cloud (although not necessarily using the exact same tech). This matches what the expected development model is in the new "Software Defined Vehicle" world. * The abstracted interfaces described above allow containers to run outside of the actual car, using virtualized components for the rest of the car. This is great for doing CI and development in the cloud and on a developers local machine. Kubernetes is highly valuable in this model both for the CI/dev environment and for running the cloud side of the services required for a network-connected car. However, running kubernetes itself in the car itself is not a great idea. The requirements that the code running in the vehicle is operating under are very different from the cloud. For functionally safe code like this you must know exactly ahead of time exactly what is running where and when, in a predictable, repeatable fashion, ideally with a minimum of unnecessary code running (as everything has to be validated in a very expensive process). The dynamical nature of kubernetes just isn't a great fit, as well as the high resource requirement and the fact that most of the abstractions it provides wrt multi-node distribution and management just isn't needed. Our plan is instead to run containers in the car more directly, managed using systemd. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alexander.larsson at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-automotive-sig/attachments/20220308/22cb6389/attachment-0002.html>