OpenInfra Edge Computing Group参加了最近的PTG活动，讨论了必须解决的关键问题，以便为工作负载构建一个健壮、灵活和可维护的边缘基础设施。

建设基础设施从来都不是一件容易的事。随着边缘计算将云从这些大型且集中的位置中解放出来，从需求和解决方案的角度来看，它更接近边缘，为分布式系统带来了新的契机。Edge工作组意识到了这一挑战，并一直致力于收集新的需求并提出解决方案。在2021年10月的PTG期间，工作组深入探讨了关键主题，包括便携式自动化、信任与验证、边缘网络、容器等。

可移植自动化

自动化是每个行业领域的关键和驱动力，但同时也是最具挑战性的愿望之一。工作组从边缘站点的角度关注自动化。如何为可重用和可移植的边缘创建自动化？

第一个挑战是面对并接受边缘环境是异构的——这从硬件开始。在许多情况下，要将硬件送到边缘站点并不容易，而且由于这样或那样的原因，它是一个不能经常升级的组件。这就导致了一个有很多硬件变化需要板载和管理，并且需要对软件进行版本控制的系统——这并不容易。与会者经常提到Redfish，但它本身并不是一个解决方案。说到标准和规范，似乎一切照旧。两个阅读相同规范的人不会以相同的方式实现它。由于时间因素，这一点变得更加困难。供应商的实施需要时间，而你的一部分需要集成他们提出的内容。要做到这一点，可能需要一年多的时间。你需要学会如何处理技术债务。

当涉及到版本控制时，依赖关系仍然需要保持在控制之下，这可以更容易地使用版本号。在部署时，即使某些配置值可能不同，也要记住不可变性，这将使自动化工具和流程在现场保持相同。

工作组一致认为，软件应该能够尽可能地照顾自己，但这总是伴随着复杂性。复杂性是我们一直试图减少的东西，但即使尽最大努力也无法消除，因此你需要学会处理它。

然后是可移植性部分，它有两个方面，站点到站点和团队到团队。人为因素也无法消除，重要的是要避免无法在团队之间转移的解决方案。更详细地说，从团队以及工具和流程的角度来看，计算和网络是两个不同的领域，但当涉及到为边缘创建自动化时，这可能是一个奢侈品。是时候放手了！

和往常一样，我们是自己的敌人，这在超尺度上也没有什么不同。我们总是假设核心系统可以扩展，容错通常是事后考虑的问题，但这些都不是可以遵循的模式。

信任与验证

由于边缘的高度分布式特性，很难验证在远程位置交付和部署并连接到控制器的软件和硬件。作为一种广泛使用的解决方案，围绕TPM展开了大量讨论，例如，它是SD-WAN系统中验证设备可靠性的首选方法。TPM实际上是一种加密处理器，它提供了多种方式和用途，用于在大型系统的组件之间建立信任关系。

整个行业的讨论往往集中在第二天开始的问题上。最大的挑战之一是如何将自动化与同时提供信任和验证结合起来。一旦硬件在边缘交付，它就需要连接和设置，而不必担心在到达远程位置的途中被篡改。奇怪或自然的是，取决于你问谁，他们倾向于尽可能地将人类的参与从这个过程中移除。这就引出了一个问题：“供应链可以被信任吗？”答案通常是否定的，并将讨论转移到零信任上。

在会议期间，与会者讨论了应用程序层和API。通常应用程序需要在不受信任的网络上运行，重点是如何保护API和系统，而不是开发新的API。在安全系统方面，工作组讨论了签名和在边缘保护密钥的方法，这是一项长期的挑战。即使在今天，获得机器的签名仍然是体力劳动，需要打电话或派人来处理。此外，你可能已经准备好了密钥，但后门仍然使用主密钥实现。我们怎样才能做得更好？

讨论的要点主要包括TPM、SmartNIC和VPN，用于在不受信任的网络上安全地访问节点。

DDI–DHCP、DNS、IPAM

第二天重点关注边缘的关键部分，即连通性！或者，更确切地说，是下面的网络和那些经常被忽视或只是盲目假设存在的部分。当天讨论了两个主要话题，第一个是DDI，换句话说就是DHCP、DNS和IPAM（IP地址管理）。第二个主题是在更高的层次上研究网络，超越工具，关注网络的用途和方式。

这一天从DDI开始，大部分对话围绕DHCP展开，因为在设置边缘站点和连接新设备时，这似乎是一个挑战。挑战的核心是DHCP最初设计并用于局域网（LAN）。还有一点很重要，DHCP并不完全是IPv6友好的。在边缘环境中使用它是为了可发现性，以及将其与引导（包括PXE引导硬件设备的方法）配对。

当涉及到局域网（WAN）网络时，DHCP在资源调配和切换方面存在问题。为了克服这些挑战，你可以使用固定的IP地址，并在DHCP服务器上注册它，以确保环境中发生的事情始终保持透明。但是，在某些情况下，固定IP可能会变得具有挑战性。另一种方法是设置VPN连接，并在该网络中运行DHCP配置和管理步骤。

为了避免和绕过DHCP，从虚拟介质引导已经开始成为一种有趣的方法。虚拟媒体镜像可以位于系统控制器或其他本地源上，也可以从BMC检索可引导镜像，这在高安全性系统中常见。这种方法也有一些困难需要解决。供应商支持是一个大问题，因为只有少数供应商支持介质连接，这当然是目前ARM的一个禁忌。

本次讨论还涉及DNS，因为系统需要名称以获得唯一标识符。尽管出于这个目的使用IP或MAC地址很有诱惑力，但归根结底，这些都是不可行的选择。DNS对于证书管理、SSH等都是必不可少的，但从信任的角度来看，它也是一个具有挑战性的组件。处理问题的一种方法是在边缘使用一个小型DNS服务。除此之外，DNS劫持也是一个更加频繁的问题，需要处理。

与会者还检查了使Neutron更适合边缘的进展情况。该服务处理边缘和中心站点之间的连接丢失，并保持数据网络正常运行，而一旦连接再次可用，就可以与控制器同步。还有一些领域，如管理网段的改进，需要重新审视，看看是否有更多的步骤需要采取。

网络在边缘做什么？

为了更好地了解底层网络中要使用的一些工具和组件，工作组继续从更高的层次上研究网络。有两个项目提案即将启动。其中一个是定义一组API，以允许服务提供商和消费者连接到边缘。这是一项以电信为重点的工作，性能指标等将发挥重要作用。MEF下的工作是在与邻近社区（如OpenInfra Edge Computing Group和Anuket）合作的同时，寻求解决此类挑战。

虽然OpenInfra Edge Computing Group的范围内没有应用程序层，但了解底层网络如何更好地支持工作负载仍然很重要。讨论的结论是，应用程序在某种程度上与网络断开连接，并期望它就在那里。它通常通过VPN和IPSec隧道进行处理，因为SD-WAN隧道实际上就是这样。这导致了电信部门和应用程序开发人员之间的脱节，由于对网络的进一步期望，这成为一个挑战。也就是说，网络应该对应用程序流量有一定程度的了解，以便通过映射等技术提高性能。确定网络流量的优先级非常具有挑战性，有时会被忽略。语音数据是一个优先级更高的例子，但随着新用例的出现，例如远程医疗和其他有安全问题的实时应用程序，这些应用程序现在也应该排在列表的首位。

边缘的容器——OpenYurt

第三天，也是最后一天，从一个非常流行的话题开始——容器。会议包括了一个关于OpenYurt的演示，这是CNCF生态系统中的一个沙箱项目，旨在将Kubernetes延伸到边缘。该项目的贡献者参加了边缘PTG会议，描述了该项目背后的动机以及为面临的挑战提供解决方案的一些细节。

其中一些挑战与边缘工作组关于集中式和分布式控制平面架构模型的研究结果产生了共鸣。当边缘上的工作节点通过公共互联网连接时，将控制服务置于中心站点会产生问题。如前所述，站点之间的连接可能不可靠，这使得管理设备和资源池非常重要。OpenYurt的创建是为了解决这些问题，它添加了可以作为扩展与上游Kubernetes集成的服务。通过新组件，该项目提供了边缘站点的自主权、更可靠的云边缘通信以及设备和资源池管理。该演示文稿还包含一张幻灯片，用于比较OpenYurt、KubeEdge和K3s。介绍后的问题和讨论集中在自治、资源池和集群管理等领域。

边缘架构

当天还进行了关于边缘架构的会议，这是对OpenYurt演示在该领域强调的一些挑战的自然跟进。

当涉及到端到端边缘基础设施时，问题似乎总是在于它应该遵循集中式还是分布式控制平面模型？或者让空间看起来更混乱，是应该分层配置，遵循联邦模型，还是边缘基础设施应该包含拉伸的控制平面？

工作组达成了一致，即伸展的控制平面不能提供自主性，云模式对于跟随并向边缘推进至关重要。创建一些非常边缘化的东西将无法扩展并具有长期生存能力。还有人质疑在整个边缘站点中应用程序应该如何结构化和调度。pod和应用程序不应跨越一个单一边缘站点的边界，但始终存在例外情况。例如，由多个微服务组成的NFV应用程序通常需要将不同的部分放置在不同的站点上，以提供完整的功能。

会议还讨论了其他重要项目，如命名空间和命名约定、分布式数据库解决方案以及物联网设备生命周期管理标准化的必要性。

边缘API——缺少什么？

最后一个主题是API，更具体地说，是否需要新的API来更好地满足边缘计算用例和工作负载的需要？

与会者再次讨论了应用程序，以确保考虑到所有需求和方面。一个有趣的角度是如何处理大量数据，这些数据需要在边缘进行过滤和处理，而其中一些数据也需要发送回区域或中心站点。本主题的结论是将重点放在API上，这些API关注的是应用程序需要的资源，而不是应用程序需要执行的功能。

共识是避免创建新的、特定于边缘的API。然而，现有的API需要不断发展，以支持边缘用例的新需求，行业还需要关注策略、元数据处理和对具有实时含义的用例的支持等方面。

原文链接：

https://superuser.openstack.org/articles/__trashed-2/