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