如何利用云原生快速实现多地部署

作者张珊，腾讯云容器前端开发工程师，日常负责腾讯云边缘容器 TKE@edge 相关控制台前端开发，同时也开发前端工程化相关工具。

问题背景

在边缘计算场景中，往往会出现一个集群管理多个边缘站点（包括一个或者多个计算节点）的情况。每个站点都可以为用户提供一套完整业务功能。由于受到网络限制，有业务联系的服务之间不希望或者不能跨站点访问。为了每个边缘节点都能提供一套完成功能，一个边缘站点都会去部署一组有业务逻辑联系的服务，如果使用原生 K8s 进行管理，无法直接控制 Deployment 的 Pod 创建的具体节点位置，需要通过统筹规划节点的亲和性来间接完成;当边缘站点数量以及需要部署的服务数量过多时，管理和部署都将极为复杂，乃至仅存在理论上的可能性。

解决方案

腾讯云边缘容器服务 TKE@edge 开拓性地提出 ServiceGroup 的解决方案。ServiceGroup 可以便捷地在同集群的不同机房或区域各自部署一组服务，并且使得各个服务间的请求在本机房或本地域内部即可完成，避免服务跨地域访问。

边缘容器服务（Tencent Kubernetes Engine for Edge，简称 TKE@edge）是腾讯云容器服务推出的用于从中心云管理边缘云资源的容器系统。

要理解 ServiceGroup，可能需要先了解以下几个概念：

NodeUnit: 位于同一个边缘站点的节点集合，其中节点有相同的某个 label，比如 zone:zone1，能够把服务之间的调用限制在同一个 NodeUnit 内；
NodeGroup: 包含多个 NodeUnit，每个 NodeUnit 中的节点 label 包含某个相同的 key，可以部署 DeploymentGrid 中声明的服务；
DeploymentGrid: TKE@edge 自行实现的 CRD (CustomResourceDefinition)，指定每个 NodeUnit 中部署的服务组；
ServiceGrid: TKE@edge 自行实现的 CRD，可以限制通过 service-name 访问只会将请求发向同一个 NodeUnit 的节点。具体关联见下图：

可以看到 ServiceGroup 方案的核心点是实现 DeploymentGrid 和 ServiceGrid 两个 CRD：

首先定义了资源字段，基本字段和 Deployment 和 Service 一致，并额外添加了 gridUniqKey 字段；
其次实现相应的controller:DeploymentGrid controller和 ServiceGrid controller，不断将创建的 DeploymentGrid 和 ServiceGrid 资源调和到期望的 Deployment 和 Service，并且联合 ServiceGrid，DeploymentGrid 上的gridUniqKey字段和节点的标签，将 Deployment 部署在每个 NodeUnit 内。

那么如何保证流量限制在节点组的范围内呢？application-grid-wrapper 组件可以帮助实现。该组件代理 kube-proxy 的请求，同时监听 apiserver 的 node、service 和 endpoint 资源。根据 pod 信息中所属 Node 是否与当前节点共属相同的 NodeUnit 做不同的处理：

如果 pod 所属的 Node 与当前节点属于相同的 NodeUnit，则将该资源信息转发给下游的 kube-proxy，kube-proxy 会按照原先的流程创建对应的路由表；
如果 pod 所属的 Node 与当前节点不属于相同的 NodeUnit，则 application-grid-wrapper 会拦截该信息，同时不转发给 kube-proxy;

这样一来，虽然用户查看 endpoint 的时候能看到整个集群内该 service 所含的所有 endpoint，但是实际上节点的 service 的路由表项只含有相同 NodeUnit 内的节点的相关表项；这样就保证了 NodeUnit 内的服务的互相访问一定会限制在当前 NodeUnit 范围内，从而避免跨节点组或者跨机房跨地域访问的问题。