做者张珊,腾讯云容器前端开发工程师,平常负责腾讯云边缘容器 TKE@edge 相关控制台前端开发,同时也开发前端工程化相关工具。前端
在边缘计算场景中,每每会出现一个集群管理多个边缘站点(包括一个或者多个计算节点)的状况。每一个站点均可觉得用户提供一套完整业务功能。因为受到网络限制,有业务联系的服务之间不但愿或者不能跨站点访问。为了每一个边缘节点都能提供一套完成功能,一个边缘站点都会去部署一组有业务逻辑联系的服务,若是使用原生 K8s 进行管理, 没法直接控制 Deployment 的 Pod 建立的具体节点位置,须要经过统筹规划节点的亲和性来间接完成;当边缘站点数量以及须要部署的服务数量过多时,管理和部署都将极为复杂,乃至仅存在理论上的可能性。node
腾讯云边缘容器服务 (Tencent Kubernetes Engine for Edge,简称 TKE@edge)是腾讯云容器服务推出的用于从中心云管理边缘云资源的容器系统,它开拓性地提出 ServiceGroup 的解决方案。ServiceGroup 能够便捷地在同集群的不一样机房或区域各自部署一组服务,而且使得各个服务间的请求在本机房或本地域内部便可完成,避免服务跨地域访问。前端工程化
要理解 ServiceGroup,可能须要先了解如下几个概念:api
能够看到 ServiceGroup 方案的核心点是实现 DeploymentGrid 和 ServiceGrid 两个 CRD:网络
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 作不一样的处理:app
若是 pod 所属的 Node 与当前节点属于相同的 NodeUnit,则将该资源信息转发给下游的 kube-proxy,kube-proxy 会按照原先的流程建立对应的路由表;ide
这样一来,虽然用户查看 endpoint 的时候能看到整个集群内该 service 所含的全部 endpoint,可是实际上节点的 service 的路由表项只含有相同 NodeUnit 内的节点的相关表项;这样就保证了 NodeUnit 内的服务的互相访问必定会限制在当前 NodeUnit 范围内,从而避免跨节点组或者跨机房跨地域访问的问题。wordpress
TKE@edge 团队已经实现 ServiceGroup 功能而且将其产品化,具体操做以下:工具
假设已在腾讯云控制台建立边缘集群,而且该集群下已有节点;若是不清楚如何建立,能够参考 边缘集群文档。学习
经过上述操做,咱们就划分了两个 NodeUnit,而且每一个 NodeUnit 都部署 wordpress 服务;在节点内经过 service-name 访问也只会将请求发向本组的节点。
本文从问题产生、方案设计和实际演示介绍 ServiceGroup 相关原理, 以及如何使用 ServiceGroup 简单快捷实现多地部署。