DataWorks 微服务集群的 Service Mesh 落地实践

阅读数:3 2020 年 3 月 14 日 10:00

DataWorks 微服务集群的 Service Mesh 落地实践

初心

DataWorks 是集团内外广泛使用的全域智能大数据平台,包含了 DataStudio、StreamStudio、HoloStudio、AppStudio、GraphStudio、PAIStudio、WebExcel 等众多的线上产品,每个产品都是类似于 IDE 形态的富交互单页应用。

DataWorks 微服务集群的 Service Mesh 落地实践

但是,DataWorks 服务于集团各大业务线上万名数据开发者和数据生态的参与者,这艘巨大的航母却不能准确地表达每一个用户的述求,「众口难调」。

因此,DataWorks 在架构升级的关键节点,决心将插件化、服务化定制的能力彻底落地,解开过重的业务共建模式在研发上的耦合羁绊,向更轻量的更开放的平台化迈进,不忘服务初心,帮助我们内外客户的业务定制快速落地。

那么如何开放 DataWorks 的定制化能力?

我们建立了一整套完整的微服务研发管控体系, DataWorks 微服务平台(DMSP:DataWorks MicroService Platform),以满足业务开发者定制服务化需求,帮助业务整合 DataWorks 输出的中台能力,重新定义属于自己的业务数据研发平台。

轻车快马

轻装上阵,是对用户(开发者、业务方)而言的。要做到用户的轻,作为平台方,我们就要做得更多。

对于业务而言,最轻量的,就是「只需要关注业务逻辑」。

即,业务开发者仅仅专注在业务逻辑上,而不需要再自己关注 入流量 的安全认证、路由、负载均衡、镜像、限流;出流量 的超时、重试、访问控制;服务间调用的隔离策略、熔断、分布式追踪等与业务逻辑无关的内容。

过去,微服务生态周边发展出了大量组件、框架,帮助我们很好地解决上述的业务以外的问题。但是这些组件框架门槛高、维护成本高、开发语言耦合,对于大多数开发者而言,成本太高,不适用于有敏捷开发需求的新兴业务。

近年来火热的服务网格(Service Mesh)技术,正能够解开这一困局。参见《Service Mesh 入门》

微服务集群能力

DMSP 是一套基于 Kubernetes 集群的微服务运行平台。我们在 K8S 的基础上,基于 Operator 开发打造了一个完整的微服务生命周期管理体系。

整体上, DMSP 分成几个领域的能力来增强微服务:

领域 说明
Service Service 相关的功能包括:
1、服务注册
2、多版本部署
3、AutoScaling
4、资源 Quota 管理
等 workload 相关的能力。

主要关注 service mesh 管控之下的 workload 生命周期,不属于 mesh 层有
Route Route 是指服务路由控制相关的功能(区别于 Traffic 中的高级流量控制能力),主要包括:
1、金丝雀部署流量控制(按流量比例权重的灰度)
2、规则灰度(基于 header、params 等判断的规则灰度)
Security 服务安全相关的管控,也包括一些全局的安全 Filter:
1、CORS
2、CSRF
3、Ingress 流量登录认证
4、Egress 流量访问白名单
5、服务 mTLS 认证与访问权限控制(Authentication and Authorization)
Traffic Traffic 中包含高级的流量控制能力,除了 Route 流量路由以外的其它功能,包括:
1、限流(Rate Limit)
2、熔断(Circuit Breaking)
3、镜像(Mirroring)
4、超时(Timeout)
5、故障注入(Fault Injection)
Telemetry Telemetry 翻译过来是遥测,这里我们称为服务治理,包括:
1、访问跟踪(Tracing)
2、日志归集(Logging)
3、服务监控 & 访问统计(Metrics)
4、可视化(Visual)

DMSP Service Mesh 架构

基于上述集群能力的要求,我们将 Istio 的 Service Mesh 能力落地。整体架构如下:

DataWorks 微服务集群的 Service Mesh 落地实践

下层 SOA 服务包括了 DataWorks 已有的许多重量级服务,包括租户、数据开发、AI 平台等。

DMS Console 是微服务管控台,它是微服务开发者与服务集群之间的管控交互唯一路径,负责管控所有(包括阿里巴巴内部、阿里云公有云 22 个 Region )的集群,前面提到的部署、流量控制与灰度、动态的安全策略、服务治理(日志 & 监控 & 报警)等能力都会在这里承上启下。

管控台与集群控制平面 Control Plane 之间的交互,完全基于 K8s ApiServer,通过抽象的一层 CRD 进行交互,再由特定的 Operator 基于 CRD 执行管控逻辑。透过对 Istio 的管控,基于服务 Sidecar 达到对服务能力的延展。业务服务就像插上了翅膀,无缝地获得了集群赋予的能力,用最小的开发成本,享受最多的最健全的微服务能力。

Why Operator and CRD?

扩展 K8s 的最佳实践,是以 Operator + CRD 的方式来实现扩展。

Operator:

https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

基于 Kubernetes 的 Operator ,将服务部署和 Service Mesh 控制层面的工作直接前移到集群上,降低原本需要多集群多配置需求中心部署管控的复杂度

DataWorks 微服务集群的 Service Mesh 落地实践

最终一致性保证

管控操作的可靠性强,能够保证最终一致性,依靠两个优势:

1、Operator 框架基于 K8s 的 Event&Watch 机制( Reconcile Cycle ),事件触发通过多发 + 幂等保证最终一致性。(而实际上幂等性不需要开发者过分关注,因为有下面第二个优势)。

2、 K8s Resource CRUD 的 Generation 机制能保证 CRD 操作的原子性

基于这两个优势,开发 Operator 时只需要专注于最终结果是什么,在任何情况下都往最终你想要的结果推进即可。

业务逻辑边界清晰

利用 Kubernates Operator 操作自定义的一套 CRD ,业务逻辑配置的复杂度降低了,将每一个业务逻辑抽象出一个 CRD 定义,业务功能边界清晰可维护,健壮性非常高。

管控链路安全可控

基于 CRD 的交互,集群不需要透出额外的控制接口,所有外部管控操作都可以基于原生的 apiserver 规范进行控制,完全可复用 k8s 的 rbac 体系,一定程度上也保证了管控链路的安全可靠,权限精细可控。

具体可参考 OpenShift 的这篇最佳实践:

https://blog.openshift.com/kubernetes-operators-best-practices/

对 Istio 的抽象设计

Istio 的 CRD 体系较为复杂,因此我们需要实现一层简单的控制平面,对 Istio 做一层抽象,用简单易懂的 API 做管控交互。

达到四两拨千斤的效果。例如:

基于 Istio 原生的控制配置,需要大约 100 行, 3 个 CRD 协作完成的控制,抽象的一层管控逻辑只需不到 10 行, 1 个 CRD :

复制代码
spec:
service: myservice1
rules:
- version: "1.1"
weight: 70
- version: "1.2"
weight: 30
- version: "2.0"
weight: 100

服务路由(Route)

微服务迭代迅速,开发敏捷。因此,金丝雀版本流量的精细化控制是集群建设的首要重点。

这也是我们常说的「版本灰度」,那么灰度能力的支持主要分为两种:

1、流量权重灰度

2、规则灰度

权重灰度

按比例调整到达服务特定版本的流量。

在这里,我们设计了大小版本,约定了开发流程中,每个大版本升级需要访问不同的域名 /ContextPath 。每个大版本下的小版本流量比例合为 100 。

示例:

复制代码
spec:
service: httpbin
rules:
- version: "1.0"
weight: 80
- version: "1.1"
weight: 20
- version: "2.0"
weight: 100

调整后,对服务流量监控进行可视化的效果:

DataWorks 微服务集群的 Service Mesh 落地实践

规则灰度

按照特定的匹配规则,将服务流量定向到特定的版本。

复制代码
spec:
service: myservice1
rules:
- version: "2.0"
matches:
- headers:
gray:
exact: "1"
- queryParams:
debug:
exact: "true"

描述了当 header 中包含 gray=1 或者 query 参数中包含 debug=true 时,流量访问到版本 1.1 。

我们通过埋在 Response 中的 header ,就可以知道灰度的效果:

DataWorks 微服务集群的 Service Mesh 落地实践

服务安全

服务安全针对流量方向分为 Mesh 出入口的南北流量管控和 Mesh 内部的东西流量管控:

1、南北流量主要利用 Ingress Gateway 的 VS 能力管控入口流量,基于 Sidecar + Egress Gateway 管控出口流量

2、东西流量需要通过 mTLS + AuthorizationPolicy 进行控制

通过这些手段来增强集群(尤其是公有云集群)中微服务的安全性。

Ingress 入流量

入口流量的一部分管控需求,在前文「服务路由」中包含。在服务安全方面,包括了全局上的能力,例如:

  • CORS 跨域配置
  • CSRF 保护
  • 流量登录认证

CORS 和 CSRF 基于 Sidecar Filter 即可覆盖统一的通用规则,做进一步的细化和动态配置的需求不强。

流量登录认证,主要用于认证前端访问流量的身份是否合法(没有涉及权限体系),会对接各个常用的登录体系,目前支持的主要是 DataWorks 自有的登录体系。

我们设计了一套灵活的认证框架,基于 Filter + 符合规范的认证服务的方式,达到登录认证的需求。

Egress 出流量

Egress 出流量是指访问 Mesh 网格之外的流量,例如,微服务访问阿里云 OSS 服务等操作。

为了防止服务被攻击后,访问未知的恶意网站,特别在高安全级别的集群环境,需要在默认情况下 0 信任任目标地址,再基于白名单的机制来打通特定的信任地址。

目前 Flannel 网络实现没有支持 NetworkPolicy ,阿里云 ACK 提供的集群默认是 flannel 网络(可选 terway 方式避免),所以基于 Pod 的 NetworkPolicy 不会生效,所以在 Istio 管控之外的 Pod 仍然需要防护,被 istio 管控的 pod 也暂时只有一层 istio 的安全机制保障

默认拒绝访问

配置 sidecar( mesh ) 访问所有 Service( Mesh 外部)的 outbound 流量都需要基于 ServiceEntry 注册才能够访问(即,默认拒绝所有连接)。

复制代码
kind: IstioControlPlane
spec:
gateways:
components:
egressGateway:
enabled: true
values:
global:
outboundTrafficPolicy:
mode: REGISTRY_ONLY

配置生效之后,任何 pod 之间经过 SideCar 进行互相访问的流量都会检查是否注册过 ServiceEntry 。

未注册的服务效果如下:

复制代码
$ kubectl exec -it sleep-788f7c9bcb-m67rh -c sleep -- curl -I www.aliyun.com
HTTP/1.1 502 Bad Gateway

502 的意思就是 DNS 和 IP 都通,但是访问会被 sidecar 拦截掉

观察流量可以看到,所有流量都到了 BlackHoleCluster ,一个专门用来接收被 block 的请求的内置 Cluster 。

PassthroughCluster 同理‍‍

DataWorks 微服务集群的 Service Mesh 落地实践

白名单机制

然后,基于默认拒绝的策略,我们在这个基础之上增加白名单。

全局白名单

首先,ServiceEntry 这套 API 并没有 selector 支持对单独某些 workload 生效,一旦配置存在,就是全局有效的。它只支持 namespace 级别的隔离(基于 ExportTo 参数)。

我们将其抽象出一层动态配置,便于未来平滑支持更多的配置规则:

复制代码
spec:
service: sleep
hosts:
- "www.aliyun.com"

观察流量,可以看到所有流量都走了 Entry 定义的端点,访问得以放行:

DataWorks 微服务集群的 Service Mesh 落地实践

服务访问控制

服务访问控制是指微服务之间的访问授权机制。在 0 信任网络中,默认是拒绝所有服务的访问。

在网格中, mTLS 机制用于服务之间身份校验,每个服务都有自己的基于 K8s 的 ServiceAccount ,根据 istio 提供的 mTLS 机制对证书进行身份校验。

因此,服务之间互相访问就有了身份的区别,那么就可以通过 AuthorizationPolicy 直接进行流量的权限控制。

配置默认拒绝:

复制代码
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: deny-all
spec:
{}

生效后:403 RBAC: access denied 。

复制代码
$ kubectl exec -it sleep-788f7c9bcb-m67rh -c sleep -- curl -i httpbin:8000/get
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Mon, 13 Jan 2020 16:09:16 GMT
server: envoy
x-envoy-upstream-service-time: 0
RBAC: access denied

未来

我们借助 Service Mesh 技术,构建了一套 DataWorks 定制化开放 API 的微服务 DevOps 体系。

希望通过我们的努力,能够极大地降低开发门槛,让业务接入更敏捷,让开发迭代更迅速。

未来, DataWorks 团队将提供更多面向微服务生态的管控和治理能力。

作者介绍

袁赓拓,花名三辰,阿里云智能 - 计算平台事业部技术专家,负责数加平台 &DataWorks 的微服务生态建设,目前主要关注微服务、Service Mesh 等相关技术方向。

本文转载自公众号阿里巴巴中间件(ID:Aliware_2018)。

原文链接

https://mp.weixin.qq.com/s/cD9kNstaUAbcRmySGVhL0w

评论

发布