首先

如果说到边缘计算的代表，那一定是像树莓派和NVIDIA Jetson这样的边缘设备上的Kubernetes，对吧？k3s、k0s、MicroK8s等轻量级Kubernetes一直以来都是边缘设备上Kubernetes的代名词，而KubeEdge和Eclipse Foundation的EdgeNative WG推动的ioFog等针对边缘计算的Kubernetes相关开源项目也在增加。此外，在KubeCon + CloudNativeCon上也举办了Kubernetes on Edge Day等活动，社区的热情也在提升。

在这样的背景下，提供面向企业的Kubernetes发行版的红帽公司开始推动MicroShift作为轻量级的OpenShift开源项目；VMware的VMware Edge Compute Stack 2.0产品组合中也出现了Device Edge，这些迹象表明在边缘设备中利用Kubernetes的应用正在逐渐向早期采用者推进。

因此，本次我们将特别关注边缘计算中的“Device Edge”，并整理一下在Device Edge上使用Kubernetes的趋势以及“为什么在Device Edge上使用Kubernetes”的原因，结合自己的经验进行总结。

Device Edge refers to

最初に、エッジコンピューティングとは、「データを生成する場所（例：センサー）にコンピューティングを近づける概念」という意味です。詳細については、以前の記事でまとめているので、詳しい情報を知りたい方は以下をご参照ください。

 

在这其中，“Device Edge”指的是通过部署在现场的各种设备（边缘设备）提供的IT资源。虽然我没有经常看到详细解释边缘设备与Device Edge之间区别的网站，但边缘设备表示单独的设备，Device Edge表示资源的概念可能更容易理解。也就是说，Device Edge可以理解为只有边缘设备或者可以是多个边缘设备的想法。

以下是边缘计算的整体概述。位于最底层的设备边缘是指我们工作和生活环境中存在的设备。传统的嵌入式市场已经开始受到物联网和云原生的影响，人们对将生活环境中的系统智能化抱有期待。与此同时，传统的嵌入式市场参与者也有机会从物品销售转变为基于服务的商业模式。

使用边缘设备运行Kubernetes的案例

在这里，我们将挑选一些已经公开的案例并进行整理。

用相机拍摄Kubernetes

树莓派和NVIDIA Jetson等与相机结合的应用场景非常常见。比如，“尝试家庭监控摄像头”之类的项目，非常容易上手。树莓派也常用于企业现场的概念验证。一般来说，我们可以将树莓派等设备与现有设备进行联动，实现将现有设备智能化的模块化应用方式。将边缘计算视为现有系统的扩展，如果想要替换现有设备或改进软件，可能会面临较高的难度。我认为首先应该保持现有系统的完整性，并通过使用实惠的设备进行试验和探索，这是迈出的第一步。

 

今年四月份举办了嵌入式边缘计算展春季展览会，那里展示了许多边缘设备，非常热闹。这些设备主要针对工业应用，强调耐用性和低功耗等硬件特点，如无风扇、防尘、防水等。除此之外，令人印象深刻的是，展会上展示了许多与人工智能结合的产品。为了满足各种需求，硬件产品种类繁多，通过将最近的人工智能与硬件结合来提供附加价值，这就是嵌入式在如今人工智能需求下的竞争方式。

举例来说，我们经常听到的是，如果要对产品的划痕进行检测或者进行更深入的分析，就可以使用树莓派进行简便的试验，而如果需要进行更复杂的分析，可以尝试使用NVIDIA的Jetson设备。此外，考虑到树莓派的SD卡容易损坏，许多人在实际运营时也会考虑更昂贵的工业用电脑等设备。因为树莓派价格便宜且易购买，所以可以提前备好备用，一旦损坏就可以立即更换，这样的运营方式也较为简便。然而，如果损坏率过高，造成成本过大，就无法继续运营下去了。因此，我认为在正式的运营阶段，会倾向于使用价格高昂但坚固耐用的设备。

顺便提一下，展会上展示的硬件设备主要包括以下几种类型。

另外，从参观嵌入式边缘计算展览中进行独立调查的感觉是，单板计算机产品和组装的盒式产品大约各占一半。令人意外的是，NVIDIA GPU相对较少，大部分产品采用了Intel CPU，其次是ARM产品较多。操作系统以Windows和Linux为主，Linux主要是Ubuntu。

使用されるようになった最も重要な要因は、アプリケーションのスケーラビリティと効率性の向上です。

我认为在边缘设备和边缘服务器上运行OPC-UA客户端以从PLC获取数据是常见的用例。进一步发展，目前可以在容器中运行PLC本身的趋势也存在。原本作为硬件系统提供的PLC现在可以作为Windows应用程序等的软件PLC来使用，进一步发展，可以在工业用PC上构建容器平台，在同一平台上执行容器PLC和AI等IT应用程序的考虑正在进行中。这种趋势类似于通信行业中的NFV。

例如，Red Hat和Intel正在合作开发Intel ECI（Edge Controls for Industrial）和OpenShift。

英特尔负责时间协调计算（TCC）和缓存分配技术（CAT）等实时处理和硬件加速，红帽负责将OpenShift安装到工业PC上，构建容器平台。OpenShift在远程工作节点的拓扑上进行展开，Master节点在数据中心的服务器上，Worker节点由工业PC组成。然后，在工业PC的主机操作系统上安装实时RHEL，并通过OpenShift的性能插件运营商调整主机操作系统的内核，以便设置和实现容器PLC的实时运行。

如果您对评估结果的报告感兴趣，可以参考博客上公开的内容。

 

当工业用PC成为容器平台时，每个工厂都会建立私有云，给人一种真正的分布式云的感觉。以前的私有云主要是为了满足公有云难以满足的服务级别协议、成本、数据安全、内部网络连接等要求而存在。然而，从网络虚拟化（NFV）和容器PLC等趋势来看，我觉得这可能是再次定义私有云存在的时代。私有云的接近现场使得以前只能通过专用硬件进行的功能现在可以通过通用硬件来执行，这可能意味着我们正在进入与公有云相结合的整体优化时代。

使用自动化车辆运行Kubernetes

尽管SDV（软件定义汽车）的发展势头很热，以汽车为例子的Kubernetes案例可能要称赞2018年左右由电装公司发布的名为“Misaki3”的平台的努力。他们利用Kubernetes Worker作为电子控制单元（ECU）来执行控制汽车功能，并在汽车内进行数据收集和控制应用的实践。
在这个项目中，他们通过VPN连接汽车和云，建立了一个平面底层网络，并从云端的Kubernetes Master向汽车部署容器。他们在云端实现了开发控制台，并验证了将在云端开发的应用部署到汽车上的数字双胞胎平台。此外，Misaki项目中，考虑到汽车的ECU资源是有限的，他们还进行了云爆发（Cloud Bursting）的尝试，将云端资源作为补充资源来解决汽车计算资源不足的问题。

用机器人运行Kubernetes

最近有一些研究在使用容器化技术来运行机器人控制的中间件，例如ROS和ROS2，然后在机器人上运行Kubernetes来执行ROS应用程序。有一些实例可以作为例子，比如索尼R&D4的研究、谷歌的Google Cloud Robotics Core和Intec Advanced Technology Research Institute的RDBOX。

每个都以将机器人和云集成起来，实现一个统一的平台为目标。通过使用 Kubernetes 对应用程序的管理平台进行标准化，解决了边缘和云端管理平台变成孤立的问题。

在一个餐饮店使用Kubernetes

北美的Chick-fil-a7在展开汉堡店的时候，为了精细化炸鸡需求预测，它公布了一种在店内使用POS和炸锅等烹饪设备收集数据，并在店内通过由Intel NUC三台构成的Kubernetes集群进行数据分析的平台。这是一个在2018年KubeCon+CloudNativeCon上宣布的著名案例。
原本，总部收集了POS等数据，然后将全店共享的需求预测结果传送到各店铺，这是业务流程。但现在他们使用各个店铺的POS、烹饪设备等实时数据进行修正，计算出每个店铺的优化需求预测，以提高店内员工的工作效率。据说他们已经在大约2000家店铺中部署了这个分析平台，这是一个相当创新的案例。他们并不是从一开始就考虑边缘计算，而是一开始是在云端构建，但后来考虑到即使发生与外部网络的断开也能够继续业务，并且存在网络连接性本来就差的店铺，所以他们转向了边缘计算并推行。在将来，他们似乎也有自动化烹饪的计划。

在中文中，可以将”スーパーでKubernetes” 一句译为”在超市中使用Kubernetes”。

沃尔玛正在努力改善其体系结构，通过在商店内部部署Kubernetes集群，将云端POS的支付交易处理移到商店内部，将分析应用程序（如BI）在云端处理。这一举措在2019年的KubeCon North America8峰会上进行了报告。云端POS由于支付交易在云端进行，所以在与外部网络断开连接时会对业务产生重大影响。沃尔玛就是为了解决这个问题而投入了实例。

通过卫星使用Kubernetes。

Red Hat和IBM Space Tech在名为ENDURANCE9的太空任务中，将Red Hat推动开源开发的轻量级版OpenShift的”MicroShift”搭载到小型人造卫星（CubeSat）上，通过SpaceX的太空船将其送入太空，并在IBM Cloud上实现一个平台，可以从地面对卫星的遥测数据（如磁力计、太阳传感器、电压、温度等）和CubeSat的相机进行控制和照片拍摄。

除此之外，Hypergiant在军事卫星轨道上引入了基于k3s的Kubernetes集群，以及在卫星边缘计算中自然而然地采用了Kubernetes的感觉。这是一个让人激动的时代，卫星上可以运行Kubernetes…令人兴奋…

在使用Device Edge时选择Kubernetes的原因。

目前正在考虑在各个行业的设备边缘引入Kubernetes并运行应用程序，那为什么要在设备边缘考虑Kubernetes呢？Kubernetes作为在云端和数据中心使用的软件，最初就是基于分布式系统思想而实现的，从某种意义上说，它从一开始就非常适合边缘计算。因此，在考虑边缘时，将Kubernetes作为候选方案似乎是必然的选择。另一方面，作为以边缘设备为主战场的开发者，他们对Kubernetes有什么期望呢？根据案例和与客户的讨论，我整理出以下三点。

作为应用程序管理的自动化软件，Kubernetes

这就是我们对Kubernetes这个软件本身的价值期望。对于设备边缘的应用开发者来说，他们认为Kubernetes具有基于API的应用部署功能，自动化更新功能（如滚动更新）等，可以轻松实现应用的生命周期管理的效率提升，而无需从零开始实现。

作为云计算的核心，Kubernetes

这是开发人员对云原生趋势的强烈需求。Kubernetes是一种软件，就像在硬件中有操作系统一样，它标准化了应用程序和计算资源的管理作为云的内核。我们希望以Kubernetes作为核心设计一致的平台来在多云和混合云中进行运营，并确保在边缘环境中也以Kubernetes为核心，确保云和边缘的运营一致性。

我想使用在边缘上也能实现云原生的开源技术。

这也是云原生开发者的强烈需求之一。例如，希望能够跨边缘设备构建服务网格，实现无服务器平台等等，这些都是希望在边缘环境中利用CNCF等推动的开源技术的需求。

未来的边缘计算技术发展方向（基础设施角度）

在我个人看来，尽管边缘计算的实现形式多种多样，但我认为设备边缘才是边缘计算的真正精髓。当设备边缘和云端以Kubernetes为核心进行集成时，边缘和云端的运营都能具备一致性，这正是计算融入网络的世界的真正面貌。
存在于各个地方的计算环境通过线条连接起来，形成一个群体，并且形成一个逻辑上的大型计算资源的分布式系统，这让人充满期待。

Eclipse Foundation的Edge Native Working Group正在推动一种名为”EdgeOps11″的概念，通过将DevOps原则应用于边缘，解决边缘独有的特点。

作為實現EdgeOps的開放源碼，我們有一個名為「ioFog」的開放源碼。ioFog是由北美邊緣平台初創公司Edgeworx領導開發的開放源碼，被用作該公司的邊緣PaaS基礎設施，如”Darcy.ai”。ioFog的核心概念就是將邊緣設備作為群體來整合管理計算資源，並構建跨越邊緣設備的服務網格平台。各個邊緣設備和邊緣設備上的微服務都在控制平面上進行統一管理。因此，我們認為未來邊緣計算的方向是控制平面、數據平面與邊緣和雲端相結合的平坦平台。

总结

根据Device Edge的Kubernetes趋势，本文总结了“为什么在边缘设备上期望使用Kubernetes？”这个问题。如果还有其他类似的案例，或者有其他的理由使用Kubernetes，请务必与我们联系，我们将非常乐意听取您的意见。感谢您读到最后，谢谢！

以下是对提供的链接的本地化中文释义：1. “State-of-the-Edge/glossary”：《边缘计算术语表》
2. “Red Hat和Intel合作推进工业4.0生态系统”：红帽和英特尔合作推进工业4.0生态系统
3. “将服务网格与基于Kubernetes的互联车载平台集成”：将服务网格与基于Kubernetes的互联车载平台集成
4. “使用Kubernetes构建的ROS2分布式系统”：使用Kubernetes构建的ROS2分布式系统
5. “Google Cloud Robotics核心”：谷歌云机器人核心
6. “rdbox”：rdbox
7. “在Chick-fil-A的边缘计算应用”：在Chick-fil-A的边缘计算应用
8. “Manesh和Siram：新的V2″：Manesh和Siram：新的V2
9. “IBM太空技术旨在实现太空民主化”：IBM太空技术旨在实现太空民主化
10. “日本企业的边缘计算投资增长”：日本企业的边缘计算投资增长
11. “Eclipse Foundation EdgeOps白皮书”：Eclipse基金会EdgeOps白皮书