KUBERNETES和边缘计算，扩展边缘管理并支持多种需求
使用微服务模式构建应用程序并将这些服务部署到Kubernetes上已成为当今运行云原生应用程序的实际方法。 在微服务架构中，单个应用程序被分解为多个微服务。 每个微服务均由一个小团队拥有，该团队有权并负责为特定的微服务做出正确的决策。
这种职责通常从用户请求到达的系统边缘开始，一直到服务的业务逻辑，再到相关的消息传递和数据存储架构。
Edge和Kubernetes入口
最终用户需要访问微服务。 内部微服务和最终用户之间的边界称为边缘。 为了使最终用户访问内部应用程序，流量需要越过边缘。 在Kubernetes中，流量使用一种称为入口的软件穿越边缘。
将API网关与在Kubernetes上运行的基于微服务的应用程序集成时，您必须考虑两个主要挑战：
- 如何扩展对100多种服务和相关API的管理; 和
- 网关如何支持通常跨整个边缘堆栈的广泛的微服务体系结构，协议和配置。
API网关：微服务的联络点
API网关是如何管理，保护和呈现API的核心。 它作为软件组件(或一系列组件)部署在虚拟机上或Kubernetes中，并充当系统的单个入口点。 API网关的主要职责是使用户能够可靠，安全地访问多个API，微服务和后端系统。
微服务和Kubernetes提供了实现灵活性。 例如，一个团队可以选择在系统的边缘(内部服务和最终用户之间的边界)公开基于容器的微服务，作为一组基于HTTP的REST API。 另一个团队可能会选择Protobufs和gRPC。 有实时流需求的团队可以通过WebSocket API公开其微服务。 Kubernetes中部署的任何API网关都必须支持所有这些协议。
每个团队不仅可以自由做出这些选择，而且对后果负责。 这通常转化为"您构建，运行"。 尽管并非每个组织都完全赞同这种工作方式，但是每个微服务团队都需要能够理解，诊断和配置处理每个服务以及每个用户对应用程序的请求的各个方面。 与应用程序和API相关的运行时要求的多样性意味着，每个团队都将使用边缘堆栈中的所有层，例如，动态请求处理，WAF和任何缓存实现。
微服务的开发范例(独立，授权和负责的团队)为使用API网关，Kubernetes入口和边缘的微服务团队带来了一系列新挑战。
在本文中，我们确定了边缘的两个重要挑战：管理独立的微服务以及访问全面的边缘堆栈。
挑战1：扩展边缘管理
随着部署的微服务数量的增加，管理边缘的挑战也越来越多
在微服务架构中，工程师将管理更多的服务和应用程序。 每个团队都需要能够独立管理他们的服务，以使发布与其他团队的计划脱钩。 在边缘公开应用程序的传统方法通常是通过集中的操作或平台团队来完成的。 但是，当组织拥有数百个微服务时，一个运维团队无法扩展以处理必要的变更量。
需要在边缘修改配置的典型更改：
- 正在部署的服务的新版本。
- 修改端点，路由指令或关联的后端服务。
- 身份验证和授权服务的更改。
- 修改非功能性需求，例如速率限制，超时，重试模式和断路。
- 用户对新功能的测试，例如，为一小部分Beta测试用户启用功能。
采用基于微服务的体系结构将导致发行数量显著增加。 这种增加只会加剧边缘管理方面的挑战，并增加集中式操作方法的压力。
挑战2：支持各种范围的边缘要求
微服务在边缘引入了许多新问题
微服务架构实现了架构灵活性。 应用程序开发人员利用这种灵活性来选择最适合服务特定要求的编程语言和体系结构。 无论架构如何，边缘都需要支持需要向用户公开的广泛功能。 这扩展了API网关的传统角色，并且与边缘整合工具需求相关的一些挑战包括：
- 熟练地路由各种协议的能力。 常见协议包括HTTP / 1.1，HTTP / 2，WebSocket，gRPC，gRPC-Web和TCP。
- 提供任何特定服务所需的完整边缘功能集合，范围从流量管理到可观察性再到身份验证等等。
- 为应用程序开发人员在自助服务模型中公开这些功能。
鼓励微服务团队实施的多样性使工程师可以选择"适合工作的工具"。 但是，基础平台的整合提供了许多好处。 与其允许开发人员构建定制的实现以提供额外的协议支持或安全处理，不如让其在边缘具有预先批准的"自助"选项，从而使他们可以选择最合适的选项，从而更加易于管理和扩展。 功能组合。
摘要
随着组织采用Kubernetes并转向基于微服务的体系结构，最终用户与内部微服务之间的边界出现了一系列新的挑战。 因此，系统的"边缘"以及相关技术(例如API网关)是采用微服务时的重点。 微服务的组织模型驱动着边缘的这些新挑战，在这种模型中，独立团队有权并负责为微服务制定正确的体系结构和实施决策。
管理系统边缘一直很复杂。 添加具有多种体系结构的更多服务只会增加对边缘的需求。 平台团队必须相应地设计，选择和实现其API网关和边缘工具。
