对于云计算大家曾经耳熟能详了，边缘计算又是一种什么玩法以及存在哪些挑战呢？
笔者特地访问专家，整顿了系列文章，和 大家从 0 到 1 来学习边缘计算的技术。
30 秒理解什么是边缘计算？边缘计算为什么重要？
依据边缘计算产业联盟的定义，边缘计算是在凑近物或数据源头的网络边缘侧，交融网络、计算、存储、利用外围能力的开放平台，就近提供边缘智能服务，满足行业在麻利联接、实时业务、数据优化、利用智能、平安与隐衷爱护等方面的要害需要。边缘计算将计算、网络、存储、带宽等能力从云延长到网络边缘的新型架构模式，其能效敌对、带宽短缺、提早低等个性很好地补充了集中化计算模式遇到的问题。
图片：边缘计算技术作为 5G 网络架构中外围，智能化革新趋势剖析
30 秒看完边缘计算集中式的 3 大难题
随着信息技术的倒退，计算资源模式由繁多的集中化变成了往集中化和边缘化两个方向的分化，集中化即以后热火朝天的云计算，边缘化即最近几年衰亡的边缘计算。云计算给世界带来的改革大家引人注目，但有了云计算为什么还须要边缘计算呢？这就须要一起来理解集中式的云计算中遇到的问题：
• PUE 问题。PUE（Power Usage Effectiveness）电源应用效率，是评估数据中心能源效率的指标。集中式数据中心耗电量微小，属于高耗能产业，不合乎绿色能源、节能减排理念，其规模和数量受政策限度。依据 IDC 统计，寰球数据中心数量在 2015 年达到高峰，而后开始逐年降落，预计 2021 年会比 2015 年升高 15%。
数据起源：数据中心白皮书数据及预测、光大证券研究所
• 平安隐衷问题。利用和数据是企业的外围资源，随着越来越多的行业互联网化，如何保障利用和数据的可靠性、安全性是企业最关怀的议题之一。
• 技术新需要问题。随着技术的倒退，单靠数据中心曾经很难满足需要。
典型场景包含：
1）物联网技术，大量的智能终端位于网络边缘，集中计算模式不能满足所有利用场景；
2）挪动互联网技术的倒退，5G 为挪动互联网注入了微小的能量，集中计算模式满足不了直播、游戏、音视频等利用在带宽、提早等方面的需要。
30 秒理解边缘计算倒退现状
目前 边缘计算钻研畛域次要集中在：计算模型、体系结构、信息安全等方面。
• 计算模型次要有：雾计算、挪动边缘计算、智能边缘计算等，涵盖物联网、无线通信网、挪动互联网等畛域。
• 体系结构有：ETSI 参考架构、MEC 架构、ECC 参考架构、SWoT 架构、AI-EC 架构。
目前 边缘计算钻研热点次要是提早敏感、实时性要求高 的场景，如：
• 云基础设施 2.0。国内外各大云厂商逐步从“核心云”模式转换到“云计算 + 边缘计算”模式，细化出多种行业云：金融云、游戏云、直播云、教育云等。
• 物联网。随着 IoT 规模的快速增长，越来越多的数据无奈间接上传到云核心，在设施侧实现数据存储、剖析、解决将越来越重要
• 工业互联网。工业互联网的实质和外围是把设施、生产线、工厂、供应商、产品和客户严密地连贯交融起来，从而提高效率，推动整个制作服务体系智能化。
• CDN。CDN 实质上是在凑近用户的地位散发内容，边缘计算能够让 CDN 离用户更近，提供更低时延、更大带宽的服务。
• 5G。国家标准组织 ETSI 认为挪动边缘计算 MEC 是一种将基站和互联网业务深度交融的技术，能够灵便地在物理网络切分出逻辑网络以满足复杂多变的利用需要。
15 秒扫完边缘计算带来的挑战
与强劲的市场需求矛盾的是，边缘计算目前尚没有一套成熟的技术体系，存在的问题包含：
• 缺失技术标准和标准
• 没有对立的体系结构
• 边缘设施异构重大
• 边缘设施数量宏大、散布广大
• 服务质量保障
边缘容器诞生带来的心愿之光
容器技术是最近几年发展势头很好的技术之一，相比物理机和虚拟机，容器技术十分轻量级，并且具备如下长处：部署简略、反对多环境、启动工夫更短、易扩容、易迁徙，比拟常见的容器技术有 Docker 和 Containerd。这些特点很好地解决了“边缘设施异构重大”这一问题。
然而在治理主机数量规模较大的业务场景时，单机容器治理计划往往力不从心。Kubernetes 是以后最风行的容器编排和管理系统，它实现了一套高效的利用治理、利用自修复、资源管理、线上运维和排障机制，并且造成了监控告警、服务网格、日志及调用链分析、CI/CD 等方面的一系列生态。这些有助于解决“缺失技术标准和标准”、“没有对立的体系结构”、“服务质量保障”、“治理老本高”等方面的问题。
然而，Kubernetes 本来是针对集中式资源管理场景设计，简略地利用到边缘计算场景会遇到诸多不适应，导致系统不稳固甚至在某些场景下运行不起来。
边缘容器的目标就是通过解决 Kubernetes 所有不适应边缘计算场景的点，实现应用集中式的 Kubernetes 来治理扩散的边缘设施。
边缘容器也遇到了挑战
通常来说，为了治理上的不便集群控制中心都是集中式设计、部署在指定地区，或者为了保障高可用有选择性地部署在某几个地区。目前较常见状况是控制中心部署在云厂商云端核心机房（私有云）或者用户核心机房（公有云）；边缘设施位于边缘云机房、挪动边缘站点、用户现场设施。
为了 让 Kubernetes 更好地用于边缘计算场景，咱们有必要整顿出边缘计算场景的次要个性：
• 云边弱网络。控制中心和边缘设施之间网络较简单，因特网、以太网、5G、WIFI 等状态均有可能，网络品质差次不齐没有保障。
• 边缘设施之间网络状况简单。边缘设施之间有可能是局域网，也有可能位于不同的地区、互相不通。
• 边缘设施资源缓和。相对而言，边缘计算设施从边缘云、挪动边缘站点、用户现场设施，单个设施的硬件资源逐步变少。其中用户现场单设施内存有可能不到 1G。
• 边缘服务治理要求简单。在核心云机房，利用能够依据节点资源择优部署；而在边缘场景，利用部署须要思考网络和地区等属性。
1 分钟讲述治理边缘容器的计划
业界目前有多种边缘容器治理的解决方案，腾讯云针对公有云和私有云别离推出 tinykube 和 TKE@edge。这里次要介绍 私有云 TKE@edge 整套计划致力于放弃对原生 Kubernetes 性能及其生态齐全兼容、以尽量少的改变达到让原生 Kubernetes 反对边缘计算场景的指标。
整体架构如下：
TKE@edge 整体是云端管控架构，Master 位于核心，边缘节点全副是 worker 节点。云边引入 tunnel 和 hub 两个通信组件，反对身份认证和数据加密；云端引入两个自研的 Controller：serviceGroup-Controller、observer-Controller；边端引入 store 和 observer；用户集群 master 组件运行在云端 metacluster 根底集群，用户集群数据对立保留在云端 Etcd 集群；使用者可通过 TKE@edge 控制台或者在本地应用 kubectl 工具间接治理本人的集群，也能够基于 TKE@edge 之上二次开发治理平台。
TKE@egde 解决了边缘容器什么问题
• 云边弱网络。hub 组件的核心作用是解决边到云弱网络问题，该组件代理了边缘节点上所有外围组件向 apiserver 发动的申请，并且将要害数据长久化保留在本地。当云边网络异样时，节点侧仍然能够应用这些数据，防止因云边弱网络起因引起业务异样。另外，边缘弱网络很容易触发 Kubernetes 驱赶机制，引起不合乎预期的 Pod 驱赶动作，TKE@edge 独创分布式衰弱检测机制能够智能地辨认驱赶机会，保障系统在弱网络下失常运行。
• 边缘设施之间网络状况简单。复杂性体现在一个集群内的节点极可能散布在多个边缘局域网内（通常称为节点或者站点，site，为防止与 Kubernetes 集群中的节点一词混同，前面均称站点），意味着同一站点内的节点之间可达，站点之间的节点之间通常不可达，这会影响集群内服务之间的调用。TKE@edge 独创 serviceGroup 资源，该资源反对用户指定服务之间流量拓扑策略，实现按策略拜访。
• 边缘设施资源缓和。原生 Kubernetes 中次要是 Master 组件资源耗费较大，节点侧资源耗费并不多。TKE@edge 采纳云端管控架构，让 Master 组件部署在资源丰盛的核心侧，边缘侧只运行 kubelet、kube-proxy 等资源耗费少的组件，边缘侧只须要较少资源即可满足条件。
• 边缘服务治理要求简单。集群内蕴含多个站点时，通常心愿在每个站点部署一整套微服务，实践上咱们能够通过给每一个服务在每一个站点调配不同的名字来实现目标，实际上这么操作会带来两方面的问题：1）服务名太多难以治理；2）同一服务在不同站点名字不同，难以通过服务名拜访；3）当减少或者撤销站点时须要人工增加和删除对应的 yaml，这无疑会带来治理劫难。TKE@edge 独创 serviceGroup 能主动实现上述操作，大大降低治理艰难。
TKE@edge 闪闪发光的亮点
• serviceGroup。能解决边缘设施之间网络简单及边缘服务治理艰难问题。客户只须要应用 ServiceGroup 提供的 DeploymentGrid 和 ServiceGrid 两种 TKE@edge 自研的 Kubernetes 资源，即可一键将服务部署到所有边缘站点中，同时还能保障服务在各站点的实例数量、进步利用在每个站点的高可用。
• hub。实现要害数据本地长久化，保障系统在弱网络下失常运行。即便节点与 Master 断网的状况下利用也不受影响，并且能够做到节点重启后利用主动复原。
• observer。分布式衰弱检测机制，能够辨认边缘节点衰弱状况，智能辨认利用驱赶的机会。
• tunnel。云边隧道机制，容许从云端登录容器、查看日志、往容器上传下载文件。对于无公网地址的设施，该性能能够显著晋升运维效率。
• 定制网络组件。站点整体与云端失联状况下服务失常运行，并且容许边缘节点产生重启。
高可用
• Master 组件。托管于腾讯云有 SLA 保障、并且有腾讯云 TKE 团队运维；Master 组件反对主动扩缩容，可依据集群压力主动调整实例数量，以满足业务需要。
• 边缘节点和站点。目前能够做到边缘端运行微服务时，边缘站点整体与管控端掉线的状况下业务不受影响，掉线期间容许计算资源产生重启。
• 业务利用。保障站点内业务 Pod 可用数量，反对一个服务在同一节点上运行多个 Pod。
易用性
• 监控告警。反对集群和 Pod 级监控告警，维度包含 CPU、内存、网络，告警形式有电话、短信、微信、邮件
• 边缘资源管理。一键增加、删除边缘节点（限腾讯云边缘计算资源）
• 利用治理。一键部署、更新、删除利用，Helm 利用打包治理（布局中）
• 界面化操作。目前集群治理、节点治理、Workload 和罕用 Kubernetes 资源管理、日志和事件查问等均能够通过 Web 界面实现，大大降低应用门槛。（产品目前是白名单凋谢，应用前请在腾讯云官网上申请加白名单）
• CICD。反对应用蓝盾，反对 Coding 零碎（布局中）
帮扶运维
• 云端登录边缘利用容器外部，云端往 / 从容器外部传输文件
• 云端查看业务日志、事件
• 利用日志采集（布局中）
结束语
边缘容器是一个十分新的方向，充斥了艰难和机会，TKE@edge 也还在一直摸索，对边缘计算和边缘容器感兴趣或有好的想法倡议，连忙加群吧。
心愿同样对边缘计算感兴趣的你与咱们一起在边缘计算的浪潮中成长，不是后浪，也不是前浪，就做弄潮儿。
【腾讯云原生】云说新品、云研新术、云游新活、云赏资讯，扫码关注同名公众号，及时获取更多干货！！