采用Kubernetes时API网关面临的两个很重要的挑战

本文涉及的产品
云原生 API 网关,700元额度,多规格可选
简介: 使用微服务模式构建应用程序并将这些服务部署到Kubernetes上已成为当今运行云原生应用程序的实际方法。 在微服务架构中,单个应用程序被分解为多个微服务。 每个微服务均由一个小团队拥有,该团队有权并负责为特定的微服务做出正确的决策。

云栖号资讯:【点击查看更多行业资讯
在这里您可以找到不同行业的第一手的上云资讯,还在等什么,快来!

KUBERNETES和边缘计算,扩展边缘管理并支持多种需求

使用微服务模式构建应用程序并将这些服务部署到Kubernetes上已成为当今运行云原生应用程序的实际方法。 在微服务架构中,单个应用程序被分解为多个微服务。 每个微服务均由一个小团队拥有,该团队有权并负责为特定的微服务做出正确的决策。

image

这种职责通常从用户请求到达的系统边缘开始,一直到服务的业务逻辑,再到相关的消息传递和数据存储架构。

Edge和Kubernetes入口

最终用户需要访问微服务。 内部微服务和最终用户之间的边界称为边缘。 为了使最终用户访问内部应用程序,流量需要越过边缘。 在Kubernetes中,流量使用一种称为入口的软件穿越边缘。

将API网关与在Kubernetes上运行的基于微服务的应用程序集成时,您必须考虑两个主要挑战:

  • 如何扩展对100多种服务和相关API的管理; 和
  • 网关如何支持通常跨整个边缘堆栈的广泛的微服务体系结构,协议和配置。

API网关:微服务的联络点

API网关是如何管理,保护和呈现API的核心。 它作为软件组件(或一系列组件)部署在虚拟机上或Kubernetes中,并充当系统的单个入口点。 API网关的主要职责是使用户能够可靠,安全地访问多个API,微服务和后端系统。

微服务和Kubernetes提供了实现灵活性。 例如,一个团队可以选择在系统的边缘(内部服务和最终用户之间的边界)公开基于容器的微服务,作为一组基于HTTP的REST API。 另一个团队可能会选择Protobufs和gRPC。 有实时流需求的团队可以通过WebSocket API公开其微服务。 Kubernetes中部署的任何API网关都必须支持所有这些协议。

image

每个团队不仅可以自由做出这些选择,而且对后果负责。 这通常转化为"您构建,运行"。 尽管并非每个组织都完全赞同这种工作方式,但是每个微服务团队都需要能够理解,诊断和配置处理每个服务以及每个用户对应用程序的请求的各个方面。 与应用程序和API相关的运行时要求的多样性意味着,每个团队都将使用边缘堆栈中的所有层,例如,动态请求处理,WAF和任何缓存实现。

微服务的开发范例(独立,授权和负责的团队)为使用API网关,Kubernetes入口和边缘的微服务团队带来了一系列新挑战。

在本文中,我们确定了边缘的两个重要挑战:管理独立的微服务以及访问全面的边缘堆栈。

挑战1:扩展边缘管理

随着部署的微服务数量的增加,管理边缘的挑战也越来越多

在微服务架构中,工程师将管理更多的服务和应用程序。 每个团队都需要能够独立管理他们的服务,以使发布与其他团队的计划脱钩。 在边缘公开应用程序的传统方法通常是通过集中的操作或平台团队来完成的。 但是,当组织拥有数百个微服务时,一个运维团队无法扩展以处理必要的变更量。

需要在边缘修改配置的典型更改:

  • 正在部署的服务的新版本。
  • 修改端点,路由指令或关联的后端服务。
  • 身份验证和授权服务的更改。
  • 修改非功能性需求,例如速率限制,超时,重试模式和断路。
  • 用户对新功能的测试,例如,为一小部分Beta测试用户启用功能。

采用基于微服务的体系结构将导致发行数量显著增加。 这种增加只会加剧边缘管理方面的挑战,并增加集中式操作方法的压力。

挑战2:支持各种范围的边缘要求

微服务在边缘引入了许多新问题

微服务架构实现了架构灵活性。 应用程序开发人员利用这种灵活性来选择最适合服务特定要求的编程语言和体系结构。 无论架构如何,边缘都需要支持需要向用户公开的广泛功能。 这扩展了API网关的传统角色,并且与边缘整合工具需求相关的一些挑战包括:

  • 熟练地路由各种协议的能力。 常见协议包括HTTP / 1.1,HTTP / 2,WebSocket,gRPC,gRPC-Web和TCP。
  • 提供任何特定服务所需的完整边缘功能集合,范围从流量管理到可观察性再到身份验证等等。
  • 为应用程序开发人员在自助服务模型中公开这些功能。

鼓励微服务团队实施的多样性使工程师可以选择"适合工作的工具"。 但是,基础平台的整合提供了许多好处。 与其允许开发人员构建定制的实现以提供额外的协议支持或安全处理,不如让其在边缘具有预先批准的"自助"选项,从而使他们可以选择最合适的选项,从而更加易于管理和扩展。 功能组合。

摘要

随着组织采用Kubernetes并转向基于微服务的体系结构,最终用户与内部微服务之间的边界出现了一系列新的挑战。 因此,系统的"边缘"以及相关技术(例如API网关)是采用微服务时的重点。 微服务的组织模型驱动着边缘的这些新挑战,在这种模型中,独立团队有权并负责为微服务制定正确的体系结构和实施决策。

管理系统边缘一直很复杂。 添加具有多种体系结构的更多服务只会增加对边缘的需求。 平台团队必须相应地设计,选择和实现其API网关和边缘工具。

【云栖号在线课堂】每天都有产品技术专家分享!
课程地址:https://yqh.aliyun.com/live

立即加入社群,与专家面对面,及时了解课程最新动态!
【云栖号在线课堂 社群】https://c.tb.cn/F3.Z8gvnK

原文发布时间:2020-06-22
本文作者:闻数起舞
本文来自:“51CTO”,了解相关信息可以关注“51CTO

相关文章
|
5月前
|
Prometheus Kubernetes Cloud Native
云原生周刊:Argo Rollouts 支持 Kubernetes Gateway API 1.0 | 2024.7.1
探索开源世界:Kubetools的推荐系统[Krs](https://github.com/kubetoolsca/krs)助力K8s优化,追踪K8s组件清单,指引IAC集成。阅读建议: Prometheus与Thanos的进化故事,Adidas容器平台管理经验,K8s请求实现详解。关注云原生:Argo Rollouts支持Gateway API 1.0,Kubewarden v1.14强化策略与镜像安全。
|
2月前
|
Kubernetes 安全 Cloud Native
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
本文介绍了云原生环境下Kubernetes集群的安全问题及攻击方法。首先概述了云环境下的新型攻击路径,如通过虚拟机攻击云管理平台、容器逃逸控制宿主机等。接着详细解释了Kubernetes集群架构,并列举了常见组件的默认端口及其安全隐患。文章通过具体案例演示了API Server 8080和6443端口未授权访问的攻击过程,以及Kubelet 10250端口未授权访问的利用方法,展示了如何通过这些漏洞实现权限提升和横向渗透。
256 0
云上攻防-云原生篇&K8s安全-Kubelet未授权访问、API Server未授权访问
|
4月前
|
Kubernetes Serverless API
Kubernetes 的架构问题之利用不可变性来最小化对API Server的访问如何解决
Kubernetes 的架构问题之利用不可变性来最小化对API Server的访问如何解决
92 7
|
4月前
|
资源调度 Kubernetes API
在K8S中,能否实现不通过api-Server创建Pod?
在K8S中,能否实现不通过api-Server创建Pod?
|
4月前
|
应用服务中间件 API nginx
微服务从代码到k8s部署应有尽有系列(二、网关)
微服务从代码到k8s部署应有尽有系列(二、网关)
|
4月前
|
Kubernetes 负载均衡 API
在K8S中,api-service 和 kube-schedule 高可用原理是什么?
在K8S中,api-service 和 kube-schedule 高可用原理是什么?
|
4月前
|
Kubernetes 监控 API
在k8S中,各模块如何与API Server进行通信的?
在k8S中,各模块如何与API Server进行通信的?
|
4月前
|
存储 Kubernetes 负载均衡
在K8S中,api-server究竟是如何实现高可用?
在K8S中,api-server究竟是如何实现高可用?
|
5月前
|
Kubernetes 监控 Java
有了k8s还需要gateway网关,nacos配置中心吗
在Kubernetes环境中,服务网关(如Spring Cloud Gateway)和Nacos配置中心补充了k8s的不足。Nacos提供灵活服务路由和动态配置更新,超越k8s基础服务发现。它还支持更复杂的配置管理和实时推送,以及环境隔离和版本控制。作为服务注册中心,Nacos增强k8s服务治理能力,保持技术一致性,并提供额外的安全层及监控功能。
330 0
|
5月前
|
Kubernetes Java 应用服务中间件
Kubernetes 上搭建一个 Nginx 的 Pod,并确保传入的 API 请求被均匀地分发到两个 Java 业务 Pod 上
Kubernetes 上搭建一个 Nginx 的 Pod,并确保传入的 API 请求被均匀地分发到两个 Java 业务 Pod 上
97 0

热门文章

最新文章

推荐镜像

更多