标签：位置 产品 工厂 探索 基础 节能 涵盖 以太网 资源
对于云计算大家已经耳熟能详了，边缘计算又是一种什么玩法以及存在哪些挑战呢？笔者特别拜访专家，整理了系列文章，和大家从0到1来学习边缘计算的技术。
根据边缘计算产业联盟的定义，边缘计算是在靠近物或数据源头的网络边缘侧，融合网络、计算、存储、应用核心能力的开放平台，就近提供边缘智能服务，满足行业在敏捷联接、实时业务、数据优化、应用智能、安全与隐私保护等方面的关键需求。边缘计算将计算、网络、存储、带宽等能力从云延伸到网络边缘的新型架构模式，其能效友好、带宽充足、延迟低等特性很好地补充了集中化计算模式遇到的问题。
图片：边缘计算技术作为5G网络架构中核心，智能化改造趋势分析
随着信息技术的发展，计算资源模式由单一的集中化变成了往集中化和边缘化两个方向的分化，集中化即当前如火如荼的云计算，边缘化即最近几年兴起的边缘计算。云计算给世界带来的变革大家有目共睹，但有了云计算为什么还需要边缘计算呢？这就需要一起来了解集中式的云计算中遇到的问题：
? PUE 问题。PUE（Power Usage Effectiveness）电源使用效率，是评价数据中心能源效率的指标。集中式数据中心耗电量巨大，属于高耗能产业，不符合绿色能源、节能减排理念，其规模和数量受政策限制。根据 IDC 统计，全球数据中心数量在 2015 年达到顶峰，然后开始逐年下降，预计 2021 年会比 2015 年降低 15%。
数据来源：数据中心白皮书数据及预测、光大证券研究所
? 安全隐私问题。应用和数据是企业的核心资源，随着越来越多的行业互联网化，如何保证应用和数据的可靠性、安全性是企业最关心的议题之一。
? 技术新需求问题。随着技术的发展，单靠数据中心已经很难满足需求。
典型场景包括：
1）物联网技术，大量的智能终端位于网络边缘，集中计算模式不能满足所有应用场景；
2）移动互联网技术的发展，5G 为移动互联网注入了巨大的能量，集中计算模式满足不了直播、游戏、音视频等应用在带宽、延迟等方面的需求。
目前边缘计算研究领域主要集中在：计算模型、体系结构、信息安全等方面。
? 计算模型主要有：雾计算、移动边缘计算、智能边缘计算等，涵盖物联网、无线通信网、移动互联网等领域。
? 体系结构有：ETSI 参考架构、MEC 架构、ECC 参考架构、SWoT 架构、AI-EC 架构。
目前边缘计算研究热点主要是延迟敏感、实时性要求高的场景，如：
? 云基础设施 2.0。国内外各大云厂商逐渐从 “中心云” 模式转换到 “云计算 + 边缘计算”模式，细化出多种行业云：金融云、游戏云、直播云、教育云等。
? 物联网。随着 IoT 规模的快速增长，越来越多的数据无法直接上传到云中心，在设备侧完成数据存储、分析、处理将越来越重要
? 工业互联网。工业互联网的本质和核心是把设备、生产线、工厂、供应商、产品和客户紧密地连接融合起来，从而提高效率，推动整个制造服务体系智能化。
? CDN。CDN 本质上是在靠近用户的位置分发内容，边缘计算可以让 CDN 离用户更近，提供更低时延、更大带宽的服务。
? 5G。国家标准组织 ETSI 认为移动边缘计算 MEC 是一种将基站和互联网业务深度融合的技术，可以灵活地在物理网络切分出逻辑网络以满足复杂多变的应用需求。
与强劲的市场需求矛盾的是，边缘计算目前尚没有一套成熟的技术体系，存在的问题包括：
? 缺失技术标准和规范
? 没有统一的体系结构
? 边缘设备异构严重
? 边缘设备数量庞大、分布广阔
? 服务质量保障
容器技术是最近几年发展势头很好的技术之一，相比物理机和虚拟机，容器技术非常轻量级，并且具有如下优点：部署简单、支持多环境、启动时间更短、易扩容、易迁移，比较常见的容器技术有 Docker 和 Containerd。这些特点很好地解决了 “边缘设备异构严重” 这一问题。
但是在管理主机数量规模较大的业务场景时，单机容器管理方案往往力不从心。Kubernetes 是当前最流行的容器编排和管理系统，它实现了一套高效的应用管理、应用自修复、资源管理、线上运维和排障机制，并且形成了监控告警、服务网格、日志及调用链分析、CI/CD 等方面的一系列生态。这些有助于解决 “缺失技术标准和规范”、“没有统一的体系结构”、“服务质量保障”、“管理成本高”等方面的问题。
然而，Kubernetes 原本是针对集中式资源管理场景设计，简单地应用到边缘计算场景会遇到诸多不适应，导致系统不稳定甚至在某些场景下运行不起来。
边缘容器的目的就是通过解决 Kubernetes 所有不适应边缘计算场景的点，实现使用集中式的 Kubernetes 来管理分散的边缘设备。
通常来说，为了管理上的方便集群控制中心都是集中式设计、部署在指定地区，或者为了保障高可用有选择性地部署在某几个地区。目前较常见情况是控制中心部署在云厂商云端中心机房（公有云）或者用户中心机房（私有云）；边缘设备位于边缘云机房、移动边缘站点、用户现场设备。
为了让 Kubernetes 更好地用于边缘计算场景，我们有必要整理出边缘计算场景的主要特性：
? 云边弱网络。控制中心和边缘设备之间网络较复杂，因特网、以太网、5G、WIFI 等形态均有可能，网络质量差次不齐没有保障。
? 边缘设备之间网络情况复杂。边缘设备之间有可能是局域网，也有可能位于不同的地区、相互不通。
? 边缘设备资源紧张。相对而言，边缘计算设备从边缘云、移动边缘站点、用户现场设备，单个设备的硬件资源逐渐变少。其中用户现场单设备内存有可能不到 1G。
? 边缘服务管理要求复杂。在中心云机房，应用可以根据节点资源择优部署；而在边缘场景，应用部署需要考虑网络和地域等属性。
业界目前有多种边缘容器管理的解决方案，腾讯云针对私有云和公有云分别推出 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 之上二次开发管理平台。
? 云边弱网络。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 能自动完成上述操作，大大降低管理困难。
? 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 也还在不断探索， 对边缘计算和边缘容器感兴趣或有好的想法建议，赶紧加群吧。
希望同样对边缘计算感兴趣的你与我们一起在边缘计算的浪潮中成长，不是后浪，也不是前浪，就做弄潮儿。
标签：位置 产品 工厂 探索 基础 节能 涵盖 以太网 资源
原文地址：https://blog.51cto.com/14120339/2541890
