完爆!用边缘容器,竟能秒级实现团队七八人一周的工做量

导语 | 云端管控、边缘计算、处于局域网内的微服务如何作Devops呢?腾讯优图业务是结合了腾讯云边缘容器TKE@edge来作服务Devops, 并对服务作了自定义定制, 以支持相应的业务场景。本篇文章接下来将详细展现实践落地细节,但愿可以给你们带来灵感。node

背景

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

笔者也思考过作一套局域网自动化部署的东西, 思路就是在局域网部署agent来和云端打通, 而后各类传数据发命令。就在这个时候忽然看到同事在写TKE@edge的东西, 看了以后感受是我想要的东西, 因而就开干了。
docker

现状

批量部署问题:为了批量部署部署, 采用了scp、fabric部署工具, 每一个局域网采用不一样配置, 要改配置的话就须要挨个登陆机器修改;
差别化配置问题:为了解决配置问题, 采用配置中心, 将全部配置集中化管理, 可是每一个局域网的配置中心仍是不同, 尽管已经收敛到一个服务了, 仍是感受很累且容易出错;
服务上下游调用:采用自研服务发现组件, 结合了consul的DNS服务功能, 上下游服务经过DNS寻址。 这个问题能够很好地解决。
网络

TKE@edge简介

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

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

1)云端运维;分布式

2)在一个集群中管理跨网络和地域的边缘节点;微服务

3)简化不一样地域差别化配置管理问题。工具

接下来,咱们来分别看下K3s、TKE@edge的工做原理以及二者之间的差别。性能

K3s 工做原理图

引用自K3S官网https://k3s.io/

TKE@edge架构图

引用自【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. 一些次要问题, 不在此列举了

成果展现

笔者在西安商场和河北商场作了部署, 而且对西安场切了部分流量。

云端部署

对于Deploymentgrid控制台还没开发好, 只能经过kubectl来建立资源

配置管理

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

成本和收益对比

过去:部署一套商场多个服务, 一个团队7八我的 一周(多则两周)的人力天, 上下游打通;

如今呢: 秒级!!!并且能够自动!!!真的是牛!!!搞完, 有预感感受本身要被裁了, 牛逼的程序员, 就是为了革普通程序员的命。

总结展望

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

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

【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯,扫码关注同名公众号,及时获取更多干货!!
相关文章
相关标签/搜索