Kubernetes中文社区
随着大量微服务向终端用户开放，边缘节点需要支持管理多种配置。
图1-学习如何使用Kubernetes管理API和edge
将应用程序重构打包为容器内的微服务风格架构并部署到Kubernetes中，这给边缘带来了一些新的挑战。尤其是，随着越来越多的微服务暴露给最终用户，边缘必须支持为各种微服务管理大量配置。
本文探讨了工程团队在迁移到微服务和Kubernetes时，可以有效管理边缘的三种策略：部署一个额外的Kubernetes API网关；扩展现有的API网关，并部署全面的自助服务边缘栈。
每种策略的介绍包括技术概述、相关优缺点的讨论，以及分析在采用Kubernetes时，该解决方案如何通过API网关来应对这两个主要挑战。
策略1：部署一个额外的Kubernetes API网关
顾名思义，该策略的实现就是在边缘部署一个额外的API网关。通常，具有基于Web的应用程序（已经存在几个月以上）的组织已经有了一系列提供edge和API管理的组件，如四层负载均衡、Web应用程序防火墙(WAF)和传统的API 网关。
通过”部署额外的Kubernetes API网关”策略，平台团队将只需在新的Kubernetes集群中部署完全独立的网关。
实施此策略有两种变体。首先是直接在现有网关“下方”部署其他API网关。此处，相关流量通过现有网关转发至新网关，然后转发到适当的服务。
第二种变体包括在现有解决方案基础上部署新的API网关。通过这种方法，流量从堆栈中较高的边缘组件（例如4层负载均衡）转发到新网关，新网关又将流量转发到Kubernetes服务。
一旦采用了该策略，就可以使用以下两种方法之一对其进行操作和维护。在某些组织中，现有平台或基础架构团队将负责部署和维护新网关。
在其他时候，完全独立的团队将拥有新的解决方案，或者将责任推给各个微服务研发团队。无论确切的组织结构如何，许多需要对边缘进行的正常变更都需要在多个API网关和相关组件之间协调。
该策略易于规划和实施：只需将现有Kubernetes专用API网关与现有解决方案一起部署和操作即可。但是，这种方法通常会为例行的API更改增加额外的管理和协调成本，并且在边缘处理额外的相互依赖的层可能会增加故障定位和修复所需的时间。
架构
下图提供了“部署额外的API网关”策略的两种典型实现的体系结构概述。左图显示了在当前网关“下方”的新网关的部署，右图显示了在现有解决方案与新网关的部署：
权衡利弊
以下部分重点介绍了“添加API网关”策略的主要优缺点：
优点
- 对核心的边缘基础架构变化很小，该策略通常允许使用所有现有的边缘组件。
- 通过同时维护两个网关，可以轻松支持基于VM和基于Kubernetes的应用程序之间的增量迁移。
- 当在边缘遇到灾难性故障时，例如，如果新的API网关遇到问题，则仅影响基于Kubernetes的应用程序，这种方法可提供有限的故障影响半径。
缺点
- 使用不同的组件会增加管理开销（并增加学习成本），例如，每个API网关最有可能具有不同的UI，SDK或API。
- 这种方法会增加维护成本，因为需要更新，维护和监控其他关键任务API网关。
- 将边缘组件的完整功能暴露给每个独立的微服务团队可能是一个挑战（很难支持协调）。例如，如果使用现有的API网关进行身份验证，则微服务团队可能无法直接配置使用它。
- 对于所有团队而言，可能很难理解由多个相似组件组成的新体系结构。在相关主题上，定位和调试边缘栈中任何出现问题的位置也可能具有挑战性。
面对的挑战
为了在此策略中扩展边缘管理，组织应实施“多层”边缘管理策略：
应将尽可能多的边缘功能推入Kubernetes API网关，并直接向应用程序开发人员公开。这样可以最大程度地提高开发团队的敏捷性和速度。
对于需要保持集中化的边缘功能，运维团队应为应用程序开发人员创建工作流，并通过设立SLA对此进行支持。
应用程序开发团队应在发布计划中使用这些SLA，以最大程度地减少发布延迟。
正确选择的附加Kubernetes API网关可以提供支持各种微服务所需的广泛功能。这包括对当代七层协议（例如gRPC和gRPC-Web）的支持，以及可观察性和弹性功能，例如断路器和自动重试。
至关重要的是，对于较新的协议，应将现有边缘组件配置为将特定路由上的流量传递到其他网关，以实现正常功能。请注意，这种方法需要权衡，因为对于这些路由，现有边缘栈的其余部分将无法使用。
策略2：扩展现有的API网关
“扩展现有API网关”策略是通过修改或扩展当前部署在生产环境中的现有API网关解决方案来实现的。该修改的主要目标是实现用户访问的API端点与在新Kubernetes集群中部署的相应服务之间实现同步。
在Kubernetes中，这通常是通过为现有的API网关或负载均衡器部署自定义ingress controller来实现的。ingress controller将解析Kubernetes中ingress controller的配置，转换为原生API网关格式，并通过它们各自的API配置API网关或负载均衡。
该策略确保平台团队将只处理单个API网关和一组边缘组件。但是，此方法需要修改现有的网关配置工作流，以避免在Kubernetes集群外部运行的现有路由/服务与在新集群中部署的路由/服务之间的任何潜在冲突。
架构
下图提供了“扩展现有API网关”策略的典型架构实现概述。在此图中，ingress controller部署在集群中的独立Pod上，读取Kubernetes ingress配置。然后，该配置将传递到现有的API网关/负载平衡器，该API网关/load blancer部署在集群外部。
权衡利弊
以下部分重点介绍了“扩展现有API网关”策略的主要有缺点：
优点
- 该策略提供了使用现有API网关的能力。该技术已经过尝试和测试，并且技术团队对该方案已经很熟悉。
- 平台团队可以利用与本地基础设施和服务的现有集成，例如，将硬件负载均衡路由到新的本地k8s群集。
- 几乎不需要学习Kubernetes网络技术，特别是对于那些不会与边缘或集群入口进行交互的开发团队而言。
缺点
- 现有配置工作流程将需要更改，以保留API网关配置的单一可靠来源。
- 大多数自定义ingress controller通过Kubernetes注释有限的配置参数，并且需要繁琐的ConfigMap或其他方法来配置更高级选项。
- 可能需要开发人员学习那些不是非原生ingress controller的配置参数。
应对挑战
为了使用此API网关扩展策略扩展边缘管理，应完全采用Kubernetes入口控制器指定的推荐配置方法，并摆脱现有网关的传统API / UI驱动的配置模型。
此外，应使用一组标准化的脚本，以便对到Kubernetes集群外运行的服务的路由进行任何修改都不会与在新集群内运行的服务冲突。
在采用该策略之前，必须对当前和预期的微服务边缘需求进行体系结构路线图审查。确保已有的网关/负载均衡支持这些需求，将避免需要添加另一个API网关来支持一些特殊需求的情况。
策略3：部署全面的自助服务边缘堆栈
部署自助服务边缘栈包括使用Kubernetes原生API网关，该网关包含其他集成的支持边缘组件，例如WAF和身份验证/授权。边缘栈已安装在每个新的Kubernetes群集中，替换且维持了之前在群集外部运行的大多数现有边缘和网关功能。
一旦部署了此策略后，通常会看到技术团队负责底层基础架构组件（以及它们的成功运行和监控），并为管理跨功能需求(例如默认超时值，重试，和熔断)提供“合理的默认值”，
然后，独立的微服务团队将获得完全授权，并负责配置边缘栈作为其正常工作流程的一部分；例如，在部署新服务时，开发团队还将指定路由配置并覆盖现有的跨功能默认值。
使用此策略可确保平台团队仅处理单个API网关和合并的边缘组件集。使用Kubernetes本地边缘堆栈还可以轻松地与此平台集成，并支持云原生最佳实践，例如自助服务，声明式配置和用于配置的“单一来源”。
架构
下图提供了“部署全面的自助服务边缘堆栈”策略的两种典型实现的体系结构概述。
权衡利弊
以下部分重点介绍了“部署全面的自助服务边缘堆栈”策略的主要利弊：
优点
- 该策略提供了与新API Gateway和周围的“云原生”栈（例如Kubernetes，服务网格和在线身份（IdP）代理）的良好集成。
- 边缘管理被简化为单个栈，该栈通过与任何其他Kubernetes配置相同的机制进行配置和部署。这可以使独立的微服务团队“自助”更改他们所有的配置。
- 这种方法使工程团队能够采用云原生的最佳实践，例如为边缘配置定义“单一来源” ，支持动态/弹性基础架构以及帮助快速配置更改（通过GitOps之类的方法）。
缺点
- 这可能是一个巨大的架构转变。现有的边缘组件将被替换，并且现有的网络体系结构和配置可能都需要更改。
- 该策略将要求平台团队学习新的代理和潜在的新边缘组件技术。
- 工程工作流程将有所变化。例如，除了独立的微服务团队具有配置边缘以支持广泛的协议和体系结构的能力之外，在设计时和操作期间的责任也越来越大。
应对挑战
在自助服务边缘栈策略中，每个微服务团队都有权维护特定于每个微服务的边缘配置。边缘栈将分布式配置聚合为单个一致的边缘配置。
为了支持边缘服务的多样性，请采用在具有强大社区的L7代理（例如Cloud Native Computing Foundation的Envoy Proxy）上构建的边缘栈。社区的广度有助于确保边缘栈中的核心路由引擎将能够支持各种用例。
总结
在迁移到部署到新Kubernetes集群中的基于微服务的体系结构时，有三种主要的API管理策略和系统边缘管理策略。本文概述了三种方法：部署附加的API网关；扩展现有的API网关，并部署自助服务边缘栈。
登录后评论
立即登录 注册