在进入边缘计算主题之前，了解对这种基础架构方法的真正需求至关重要。 IT世界已经看到了从传统的客户端-服务器架构到云计算的演进。这还不够，原因很简单：与计算世界相比，访问基础结构的设备数量呈指数增长，因此生成的数据量也呈指数增长。截至目前，无论是智能手表，智能手机，智能电视还是自动驾驶汽车，世界上所有事物都已连接到互联网。
这引起了对现有云基础架构所需要支持的带宽，每个请求的延迟，在设备和云之间传输的数据的安全性和安全性方面的担忧。让我们以自动驾驶汽车的简单紧急情况为例，假设自动驾驶汽车必须为在同一轨道上的救护车铺平道路。为此，汽车必须将其当前的交通信息发送到云中，并且必须通过比较相同和最近轨道上的其他车辆来执行一些分析。然后必须向汽车发出指示以离开道路。所有这些只需几秒钟即可完成。但是，仅云基础设施位于离数据源设备几英里远的地方，这是一个很大的挑战。这使我们想到了边缘计算的概念。
那么，什么是边缘计算？这是关于将智能推到网络边缘。这意味着将计算，存储，分析（+缓存）功能与设备本身相提并论。我们如何实现这一壮举？通过在设备和云数据中心之间引入网络层（边缘系统）。因此，数据并不需要一直传输到云中进行处理，而是边缘系统可以满足需要。首先，我们从这种方法中获得的好处是超低延迟，因为边缘系统位于设备附近。其次，数据过滤和缩减：意味着，所有数据都不会发送到云中，从而减少了对带宽需求的压力。第三，数据的安全性和隐私合规性可以得到满足，因为它不会一直发送到云中。

但是，在设备和云之间引入Edge Systems并非易事。 我们需要补充有效的配置和编排功能，以使其具有弹性。 因为我们要管理的系统数量不如上面的图片那么简单。 它将有数十亿个设备。

重要的是要记住，边缘设备不会将自己局限于一种通信协议。它依赖于广泛的机制，例如蓝牙，WiFi，3G / 4G / 5G等。因此，边缘服务器也不会运行属于相同架构/运行时的应用程序。因此，最好借助docker之类的运行时容器化应用程序，以将其部署在边缘服务器上。在我们这么说的同时，我们显而易见的是Kubernetes来协调这些应用程序容器。可悲的是，由于计算资源有限的性质，直接在边缘服务器上运行Kubernetes并不是那么简单。即使这些服务器允许我们安装所有Kubernetes组件，客户也可能不愿意花费宝贵的计算资源来管理Kubernetes控制平面，而是希望将其用于处理数据。
这里出现了需要紧凑/优化版本的Kubernetes（即KubeEdge）的情况。 KubeEdge是一个开放源代码系统，用于将本机容器化应用程序编排功能扩展到Edge上的主机，并且通过从Kubernetes二进制文件中剥离大量功能，使其具有轻量化的特性。显着的区别是在有边缘的轻量级节点代理（等效于kubelet）上完成的，使用SQLite代替etcd。另外，业务流程功能从边缘节点到云端都是分离的。意味着，Kubernetes控制平面[主节点组件]将放置在云侧，而计算功能[pod部署]将在边缘侧处理。下图显示了Kubernetes和KubeEdge之间的架构差异。

IBM拥有名为Edge Application Manager的产品，它也具有独特的功能集，特别是与自治管理有关的功能！
我希望本文能使您深入了解什么是边缘计算以及Kubernetes在使其更有效方面所扮演的角色。

原文：https://itnext.io/edge-computing-journey-to-kubeedge-13bd4febf8b