**导语** | 云端管控、边缘计算、处于局域网内的微服务如何做Devops呢？腾讯优图业务是结合了腾讯云边缘容器TKE@edge来做服务Devops， 并对服务做了自定义定制， 以支持相应的业务场景。本篇文章接下来将详细展示实践落地细节，希望能够给大家带来灵感。

## 背景

所谓私有云， 其实就是在多个局域网玩服务，基本等同于开发运维全包。每个局域网都要需要一个跳板机、局域网环境（每个局域网环境不一）以及硬件、软件等，然后还需要大量人肉运维部署升级服务（传统做法譬如ansible， fabric， scp， 诸如拷贝、配置更新、版本维护都很麻烦， 所以弃用）， 而且不同局域网服务需要差异化配置， 配置管理也是问题。

笔者也思考过做一套局域网自动化部署的东西， 思路就是在局域网部署agent来和云端打通， 然后各种传数据发命令。就在这个时候突然看到同事在写TKE@edge的东西， 看了之后感觉是我想要的东西， 于是就开干了。
![](https://main.qcloudimg.com/raw/21fe1130a8d20236f618655a447e827e.png)

## 现状

**批量部署问题**：为了批量部署部署， 采用了scp、fabric部署工具， 每个局域网采用不同配置， 要改配置的话就需要挨个登录机器修改；
**差异化配置问题**：为了解决配置问题， 采用配置中心， 将所有配置集中化管理， 但是每个局域网的配置中心还是不一样， 尽管已经收敛到一个服务了， 还是感觉很累且容易出错；
**服务上下游调用**：采用自研服务发现组件， 结合了consul的DNS服务功能， 上下游服务通过DNS寻址。 这个问题可以很好地解决。
![](https://main.qcloudimg.com/raw/82c47ab4f946be80f948d3ee80a05b55.png)

## TKE@edge简介

有没有一种能在云上控制服务部署升级的产品呢？据了解，TKE@edge就是其中一种，它可以比较好地解决这个问题。

另外，业界还有一个开源解决方案K3s，这个方案虽然通过裁剪让资源有限的设备也能运行 K8s，然而依然不能解决我最关心的几个问题，如：

1）云端运维；

2）在一个集群中管理跨网络和地域的边缘节点；

3）简化不同地域差异化配置管理问题。

接下来，我们来分别看下K3s、TKE@edge的工作原理以及两者之间的差异。

##### K3s 工作原理图

![引用自K3S官网https://k3s.io/](https://main.qcloudimg.com/raw/9cf933e37678ba48daeaea0959611a28.png)

##### TKE@edge架构图

![](https://main.qcloudimg.com/raw/316d37aab9884f2aba5196046f9e57f1.png)

> 引用自【TKE 边缘容器系列】边缘计算与边缘容器简介。

从上方架构图可以看出，TKE@edge增加tunnel来打通外网， 传输数据和命令， 就是我之前提到的需要设计的agent， 另外增加了边缘节点自治组件hub-edge， 这个跟云端管控一一对应的。

**TKE@edge做了几个亮点：**

**1. ServiceGroup**：跨局域网服务的隔离， 局域网内服务互通， 但是不能跨局域网访问， **另外可以自动复制业务系统， 注意是一套业务系统，不是单个Pod， 比如增加一个局域网Zone， 可以在不干预的情况下，自动复制到新的局域网， 意外亮点**；

**2. 分布式健康检测**： 为了避免弱网环境 和云端管控存在网络问题， 可以采用自治的决定哪些Pod真正被驱逐。

**3. 支持异构节点。**

## 我的核心问题（Q）和解决方案(A)

**1.  服务能在云端控制部署升级**

tke@edge提供了类腾讯云容器服务TKE控制台， 可以批量操作。

**2.  服务不能跨局域网访问**

ServiceGroup， 通过对节点打上Zone的标签， 同一个Zone的服务互通， 不同Zone的服务进行隔离， TKE@edge通过Deploymentgrid的资源来创建Deployment。

**3. 服务在K8s要做一致性hash这种复杂化LB策略**

先用K8s的downward API讲Pod的NodeName导入到POD环境变量， 通过node的zone信息， 结合client-go的API进行Label过滤， 这个需要上层服务发现组件支持， 为啥不用K8s Ingress和Service方案， 不好意思， 不支持。

**4. 服务流量的注入**

通过nodePort暴露服务， 为了避免网卡爆掉需要利用多个宿主机nodePort承接流量， 采用consul来注册服务， 类似腾讯云CLB方案

**5. 服务流量的导出**

小问题

**6. 服务分区域差异化配置，一套代码， 云端定制配置， 通过zone来关联**
将服务配置采用Configmap管理， 并且通过Volume机制将Configmap挂载到Pod的容器目录， 那怎么决定哪个区域采用哪个配置呢， 通过传入NodeName的来进行选择。这个问题解决好了之后， 新增商场(局域网)， 只需要在云端配置好对应的配置， 就可以自动扩容了， 碉堡了简直。

**7. 一些次要问题， 不在此列举了**

## 成果展示

笔者在西安商场和河北商场做了部署， 并且对西安场切了部分流量。

### 云端部署

![](https://main.qcloudimg.com/raw/f3135cce41d2e7ecf7d47c2898f6ee53.png)

> 对于Deploymentgrid控制台还没开发好， 只能通过kubectl来创建资源

### 配置管理

![](https://main.qcloudimg.com/raw/b58710d73f8380f828ae0ce6b791ad9c.png)

这两个棘手问题解决了， 就大功告成了。

### 成本和收益对比

**过去：**部署一套商场多个服务， 一个团队7八个人 一周（多则两周）的人力天， 上下游打通；

**现在呢：** 秒级！！！而且可以自动！！！真的是牛！！！搞完， 有预感感觉自己要被裁了， 牛逼的程序员， 就是为了革普通程序员的命。

## 总结展望

目前我觉得存在的问题是， tke@edge应该是基于k8s定制的， 资源占用比较多，对于ai设备有些要求，比如要能跑docker， 还有硬件平台和操作系统等一些要求；另外节点添加过程， 没有为节点批量打标签的功能， 对于node标签修改， 调度规则有待明确；对tke@edge单集群能管理的节点极限、大规模Pod调度性能方面尚未深入研究。

随着5G的到来， 越来越多设备边缘化， 计算也边缘化， 边缘容器和调度会是一个大有前景的方向。

ITPub博客

完爆！用边缘容器，竟能秒级实现团队七八人一周的工作量

最新文章