标签：程序员 人力 访问 定义 注意 简介 运维 思考 出错
导语 | 云端管控、边缘计算、处于局域网内的微服务如何做Devops呢？腾讯优图业务是结合了腾讯云边缘容器TKE@edge来做服务Devops， 并对服务做了自定义定制， 以支持相应的业务场景。本篇文章接下来将详细展示实践落地细节，希望能够给大家带来灵感。
所谓私有云， 其实就是在多个局域网玩服务，基本等同于开发运维全包。每个局域网都要需要一个跳板机、局域网环境（每个局域网环境不一）以及硬件、软件等，然后还需要大量人肉运维部署升级服务（传统做法譬如ansible， fabric， scp， 诸如拷贝、配置更新、版本维护都很麻烦， 所以弃用）， 而且不同局域网服务需要差异化配置， 配置管理也是问题。
笔者也思考过做一套局域网自动化部署的东西， 思路就是在局域网部署agent来和云端打通， 然后各种传数据发命令。就在这个时候突然看到同事在写TKE@edge的东西， 看了之后感觉是我想要的东西， 于是就开干了。
批量部署问题：为了批量部署部署， 采用了scp、fabric部署工具， 每个局域网采用不同配置， 要改配置的话就需要挨个登录机器修改；
差异化配置问题：为了解决配置问题， 采用配置中心， 将所有配置集中化管理， 但是每个局域网的配置中心还是不一样， 尽管已经收敛到一个服务了， 还是感觉很累且容易出错；
服务上下游调用：采用自研服务发现组件， 结合了consul的DNS服务功能， 上下游服务通过DNS寻址。 这个问题可以很好地解决。
有没有一种能在云上控制服务部署升级的产品呢？据了解，TKE@edge就是其中一种，它可以比较好地解决这个问题。
另外，业界还有一个开源解决方案K3s，这个方案虽然通过裁剪让资源有限的设备也能运行 K8s，然而依然不能解决我最关心的几个问题，如：
1）云端运维；
2）在一个集群中管理跨网络和地域的边缘节点；
3）简化不同地域差异化配置管理问题。
接下来，我们来分别看下K3s、TKE@edge的工作原理以及两者之间的差异。
引用自【TKE 边缘容器系列】边缘计算与边缘容器简介。
从上方架构图可以看出，TKE@edge增加tunnel来打通外网， 传输数据和命令， 就是我之前提到的需要设计的agent， 另外增加了边缘节点自治组件hub-edge， 这个跟云端管控一一对应的。
TKE@edge做了几个亮点：
1. ServiceGroup：跨局域网服务的隔离， 局域网内服务互通， 但是不能跨局域网访问， 另外可以自动复制业务系统， 注意是一套业务系统，不是单个Pod， 比如增加一个局域网Zone， 可以在不干预的情况下，自动复制到新的局域网， 意外亮点；
2. 分布式健康检测： 为了避免弱网环境 和云端管控存在网络问题， 可以采用自治的决定哪些Pod真正被驱逐。
3. 支持异构节点。
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. 一些次要问题， 不在此列举了
笔者在西安商场和河北商场做了部署， 并且对西安场切了部分流量。
对于Deploymentgrid控制台还没开发好， 只能通过kubectl来创建资源
这两个棘手问题解决了， 就大功告成了。
过去：部署一套商场多个服务， 一个团队7八个人 一周（多则两周）的人力天， 上下游打通；
现在呢： 秒级！！！而且可以自动！！！真的是牛！！！搞完， 有预感感觉自己要被裁了， 牛逼的程序员， 就是为了革普通程序员的命。
目前我觉得存在的问题是， tke@edge应该是基于k8s定制的， 资源占用比较多，对于ai设备有些要求，比如要能跑docker， 还有硬件平台和操作系统等一些要求；另外节点添加过程， 没有为节点批量打标签的功能， 对于node标签修改， 调度规则有待明确；对tke@edge单集群能管理的节点极限、大规模Pod调度性能方面尚未深入研究。
随着5G的到来， 越来越多设备边缘化， 计算也边缘化， 边缘容器和调度会是一个大有前景的方向。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！
标签：程序员 人力 访问 定义 注意 简介 运维 思考 出错
原文地址：https://www.cnblogs.com/tencent-cloud-native/p/13895950.html
