（红帽）该如何在汽车中运行容器？

　　一年多前，红帽宣布了与汽车行业合作的意向，帮助推动实现软件定义汽车（SDV）。2022年5月，随着红帽和通用汽车公司宣布合作，这一愿景变得具体，双方将在边缘开创SDV的先河。我们的目标是开发一个基础操作系统，以运行各种车载软件，既适用于安全关键用例，也适用于非安全用例。

　　容器已经成为更广泛的IT行业中事实上的标准，在软件定义汽车的愿景中，它们处于前沿和中心位置，允许隔离应用，为开发人员和部署提供更大的灵活性，并允许更快的创新。红帽公司领导了云端容器的工作，现在是时候把这项专业知识应用到汽车行业了。

　　

　　然而，“容器”一词可以表示很多东西，其含义常常因个人和组织而异。这包括从“容器意味着对应用隔离的内核支持”这样的细节，到“容器意味着支持在全球规模的集群上运行分布式软件”这样的大型想法。

　　虽然这些含义对于某些用例有意义，但并非所有含义都一定适用于车内用例。本文讨论了一些特定于汽车行业的需求，以及如何在这些情况下利用容器。

　　功能安全

　　汽车行业软件的核心差异之一是围绕功能安全的需求。功能安全的主要目标是确保产品不存在不合理的风险。功能安全超出了传统的硬件和软件问题，如“产品是否符合用户的期望?”（质量）到“该产品是否会因故障行为而失效，并对人造成身体伤害?”（安全）。理论上说，最安全的车是从来没人开过的车，但这显然不切实际。这意味着，开发汽车体验的关键因素不仅仅是质量，还包括可用性、可靠性、安全性和功能安全。

　　Linux，尤其是红帽的产品，得到了广泛的使用和测试，因此质量水平普遍很高。但是在传统的开源开发中，功能安全通常没有得到解决。为了证明系统满足所要求的“安全”级别，开发人员必须为整个系统中要处理的所有风险提出安全论证。红帽从2021年初就开始做了。

　　

　　系统越复杂，就越难对其功能安全进行论证。因此，使用更少的代码并使用更简单的结构和技术（如形式化方法）是有帮助的。

　　并非系统上的所有软件都需要具有相同的安全需求。通常，安全级别是多种多样的。这被称为“混合临界”。本质上，容器允许系统运行多种类型的工作负载和应用，无论是否通过安全认证。这种灵活性使容器技术成为混合临界的理想解决方案。然而，要在容器中运行功能安全的代码，容器运行时和管理系统也必须是功能安全的。

　　为了交付一个功能安全的代码可以在容器中运行的系统，对于进入容器运行时和管理系统的内容，我们需要非常小心。

　　分布式系统

　　容器的概念在分布式系统中经常使用。分布式系统是将许多松耦合的、通常是地理上分布的系统组合成一个集群的系统。分布式系统通常也是可伸缩的，这意味着随着时间的推移，随着需求的变化，您可以在运行时通过向集群添加更多的计算机来扩展资源。

　　分布式系统是复杂的，因为网络是不可靠的和并发的。例如，个别计算机可能出现分歧或故障，或者网络故障会将集群划分为单独的子集，而分布式系统需要考虑到这些情况。

　　这种复杂性是通过资源过度分配和复杂的算法（如投票），和一个称为“最终一致性”的概念来处理的。最终的一致性意味着系统可能不总是处于一致的状态，但总是朝着它前进。

　　总的来说，分布式系统是不确定的。例如，单个的运行可以以不同的顺序执行，或者在不同的系统上执行不同的代码路径，而事先不知道哪一条会被执行。这也增加了系统的复杂性，反过来又增加了关于整个系统的功能安全论证的难度。

　　对于许多用例来说，使用分布式系统的复杂性是值得的，因为使用这种系统可以获得巨大的灵活性和动态特性。此外，由于它们要解决的问题性质，许多用例必须保持分布式。例如，Netflix在世界各地的流媒体将永远是分布式的。

　　另一方面，汽车中的软件并不是真正意义上的分布式软件。硬件是固定的，这意味着它不会在汽车使用过程中发生变化，因此也不需要担心真正的可伸缩性。此外，通过在以前未测试的降级模式下运行系统来处理故障的典型方法通常是不安全的。汽车中的任何这种降级状态都应该被视为不安全，并切换到安全模式（例如缓慢停车），而不是继续以最佳状态行驶。

　　很多容器生态系统都集中在分布式系统上，这些系统根本不适合车内使用。事实上，从功能安全的角度来看，这些系统的优势带来的复杂性不利于车内用例。

　　容器的要求

　　那么，车内容器的实际要求是什么呢？当然，这完全取决于您想要做什么。我们一直在与汽车行业的主要参与者进行讨论，并出现了一些共同点。

　　首先，我们相信容器将成为汽车工业向软件定义汽车发展的一个组成部分。我们还认为，这些容器必须与运行在其他地方的容器相同，例如在您的笔记本电脑或云上。这对于开发人员的体验和帮助在云中进行测试都是很重要的。

　　第二，容器需要在资源使用方面是有效的。与老式汽车相比，现代汽车拥有强大的计算机，但仍然存在一些硬性的资源限制。

　　第三，需要某种形式的高级容器管理。例如，所需的容器必须在汽车发动时启动，以正确的顺序启动，并具有足够的监控，以确保它们的行为符合预期。

　　第四，我们期望整个系统处于一组固定的全局状态中，每个状态都有自己的工作负载在运行，并且主系统将能够在这些状态之间转变整辆车。所有这些状态都需要提前进行计划和验证，以确认它们符合资源需求。

　　最后，整个容器和管理系统必须足够简单，证明我们可以在车辆上的容器中运行功能安全的代码。

　　我们的想法

　　红帽长期致力于Podman项目。Podman是一个功能齐全的容器系统，是基于Kubernetes的红帽OpenShift的核心部分。Podman也经过了良好的测试，在世界各地的关键系统中运行了数百万小时。

　　我们相信Podman将成为车载容器系统的一大优势，特别是与crun结合使用时，crun是RHEL9中默认启用的一种新的、重量更轻的容器运行时。

　　说到编排，虽然OpenShift是云领域中非常强大的产品，但它并不太适合车载用例，因为它针对的是分布式系统用例。但是Podman也可以很好地与systemd集成，systemd是RHEL中的常规服务管理器。Systemd更适合我们在车载容器管理方面看到的需求。特别是，它更简单，更确定，并对汽车中所需的全局状态转换具有原生支持。

　　当涉及到云工作时，Kubernetes是首选的工具，包括其他服务和解决方案中的开发人员/测试体验。如果我们能够集成和重用所有可用的软件、工作流程、经验和概念，这些在车载用例和汽车行业中都是有意义的，也是有益的。

　　在Podman最近的工作中可以找到一个例子，在与systemd一起使用时支持Kubernetes应用描述。这就形成了一种理想的组合，即Kubernetes可以在云中使用，而同样的Kubernetes描述可以在车辆中使用，而不需要Kubernetes本身的开销和复杂性。这将是加入汽车和云这两个世界的优势的第一步。

　　结论

　　本文，我们描述了从与一些汽车行业公司的交谈中收集到的实在需求。我们还透露了正在考虑哪些解决方案来满足这些需求。如果您对更多技术细节感兴趣，或者对红帽的车载容器运行愿景感兴趣，请继续关注。我们将在以后的文章中讨论这两件事。

上一条：趋动科技基于红帽开源技术，推出面向AI算力资源池化的云原生解决方案

下一条：红帽成为中国汽车基础软件生态委员会（AUTOSEMO）成员，加速软件定义汽车愿景实现