关键词：
大家对使用Kubernetes管理应用已经比较熟悉，但是边缘场景下的应用部署和管理是否存在不同的需求呢？本文将和大家一起探讨边缘场景下常见的容器应用管理方案。
1边缘简单服务场景
在笔者接触过的边缘需求中部分用户业务场景比较简单，如：拨测服务。这种场景的特点是用户希望在每个节点部署相同的服务，并且每个节点起一个 pod 即可，这种场景一般推荐用户直接使用 daemonset 部署。关于 daemonset 的特点和使用方式读者可以阅读 kubernetes 官方文档。
2边缘单站点部署微服务场景
第二种场景是部署边缘 SAAS 服务，由于涉及客户商业机密，此处暂不举例。用户会在一个边缘机房内部署一整套微服务，包括账号服务、接入服务、业务服务、存储及消息队列，服务之间借助kubernetes的dns做服务注册和发现。这种情况下客户可以直接使用 deployment和service，其中最主要的困难不在于服务管理而是边缘自治能力。
关于deployment和service的使用方式读者可以阅读kubernetes 官方文档，关于TKE@edge 边缘自治能力我们将会在后续推出相关文章介绍。
3边缘多站点部署微服务场景
场景特点：
•边缘计算场景中，往往会在同一个集群中管理多个边缘站点，每个边缘站点内有一个或多个计算节点。
•希望在每个站点中都运行一组有业务逻辑联系的服务，每个站点内的服务是一套完整的微服务，可以为用户提供服务
•由于受到网络限制，有业务联系的服务之间不希望或者不能跨站点访问
常规方案：
1.将服务限制在一个节点内
该方案特点：
•服务以daemonset方式部署，以便每个边缘节点上均有所有服务的 pod。如上图所示，集群内有A、B两个服务，以daemonset部署后每个边缘节点上均有一个 Pod-A和Pod-B。
•服务通过localhost访问，以便将调用链锁定在同一个节点内。如上图所示，Pod-A和Pod-B之间以localhost访问。
该方案缺点：
•每个服务在同一个节点内只能有一个 Pod，这是由于daemonset工作机制所限，对于需要在同一节点上运行多个 Pod的服务来说这个限制极为不便。
•Pod需要使用 hostnetWork模式，以便Pod之间可以通过localhost+port访问。这意味着需要用户很好地管理服务对资源使用，避免出现资源竞争，如端口竞争。
2.服务在不同站点叫不同的名字
该方案特点：
•相同服务在不同站点叫不同的名字，以便将服务间的访问锁定在同一个站点内。如上图所示，集群内有A、B两个服务，在site-1中分别命名为 svr-A-1、Svc-B-1，在site-2中分别命名为 svr-A-2、Svc-B-2。
该方案缺点：
•服务在不同站点名字不同，因而服务之间不能简单地通过服务名A和B来调用，而是在 site-1中用 Svc-A-1、Svc-B-1，在site-2中用 Svc-A-2、Svc-B-2。对于借助 k8s dns 实现微服务的业务极为不友好。
场景痛点：
1.k8s本身并不直接针对下述场景提供方案。
•首先是众多地域部署问题：通常，一个边缘集群会管理许多个边缘站点（每个边缘站点内有一个或多个计算资源），中心云场景往往是一些大地域的中心机房，边缘地域相对中心云场景地域更多，也许一个小城市就有一个边缘机房，地域数量可能会非常多；在原生k8s中，pod的创建很难指定，除非使用节点亲和性针对每个地域进行部署，但是如果地域数量有十几个甚至几十个，以需要每个地域部署多个服务的deployment为例，需要各个deployment的名称和selector各不相同，几十个地域，意味着需要上百个对应的不同name，selector，pod labels以及亲和性的部署yaml，单单是编写这些yaml工作量就非常巨大；
•services服务需要与地域关联，比如音视频服务中的转码和合成服务，要在所属地域内完成接入的音视频服务，用户希望服务之间的相互调用能限制在本地域内，而不是跨地域访问。这同样需要用户同样准备上百个不同selector和name的本地域deployment专属的service的部署yaml；
•一个更复杂的问题是，如果用户程序中服务之间的相互访问使用了service名，那么当前环境下，由于service的名称各个地域都不相同，对于用户而言，原来的应用甚至都无法工作，需要针对每个地域单独适配，复杂度太高。
2.另外，使用方为了让容器化的业务在调度方案上与之前运行在 vm或者物理机上的业务保持一致，他们很自然就想到为每个 pod 分配一个公网IP，然而公网IP数量明显是不够用的。
综上所述，原生k8s虽然可以变相满足需求1），但是实际方案非常复杂，对于需求2）则没有好的解决案。
为解决上述痛点，TKE@edge 开创性地提出和实现了 serviceGroup 特性，两个yaml文件即可轻松实现即使上百地域的服务部署，且无需应用适配或改造。
SeviceGroup功能介绍
ServiceGroup可以便捷地在共属同一个集群的不同机房或区域中各自部署一组服务，并且使得各个服务间的请求在本机房或本地域内部即可完成，避免服务跨地域访问。
原生 k8s 无法控制deployment的pod创建的具体节点位置，需要通过统筹规划节点的亲和性来间接完成，当边缘站点数量以及需要部署的服务数量过多时，管理和部署方面的极为复杂，乃至仅存在理论上的可能性；与此同时，为了将服务间的相互调用限制在一定范围，业务方需要为各个deployment分别创建专属的service，管理方面的工作量巨大且极容易出错并引起线上业务异常。
ServiceGroup就是为这种场景设计的，客户只需要使用ServiceGroup提供的DeploymentGrid和ServiceGrid两种tkeedge自研的kubernetes 资源，即可方便地将服务分别部署到这些节点组中，并进行服务流量管控，另外，还能保证各区域服务数量及容灾。
ServiceGroup关键概念
1.整体架构
NodeUnit
•NodeUnit通常是位于同一边缘站点内的一个或多个计算资源实例，需要保证同一NodeUnit中的节点内网是通的
•ServiceGroup组中的服务运行在一个NodeUnit之内
•tkeedge 允许用户设置服务在一个 NodeUnit中运行的pod数量
•tkeedge 能够把服务之间的调用限制在本 NodeUnit 内
NodeGroup
•NodeGroup 包含一个或者多个 NodeUnit
•保证在集合中每个 NodeUnit上均部署ServiceGroup中的服务
•集群中增加 NodeUnit 时自动将 ServiceGroup 中的服务部署到新增 NodeUnit
ServiceGroup
•ServiceGroup 包含一个或者多个业务服务
•适用场景：1）业务需要打包部署；2）或者，需要在每一个 NodeUnit 中均运行起来并且保证pod数量；3）或者，需要将服务之间的调用控制在同一个 NodeUnit 中，不能将流量转发到其他 NodeUnit。
•注意：ServiceGroup是一种抽象资源，一个集群中可以创建多个ServiceGroup
2.涉及的资源类型
DepolymentGrid
DeploymentGrid的格式与Deployment类似，<deployment-template>字段就是原先deployment的template字段，比较特殊的是gridUniqKey字段，该字段指明了节点分组的label的key值；
apiVersion: tkeedge.io/v1 kind: DeploymentGrid metadata: name: namespace: spec: gridUniqKey: <NodeLabel Key> <deployment-template>
ServiceGrid
ServiceGrid的格式与Service类似，<service-template>字段就是原先service的template字段，比较特殊的是gridUniqKey字段，该字段指明了节点分组的label的key值；
apiVersion: tkeedge.io/v1 kind: ServiceGrid metadata: name: namespace: spec: gridUniqKey: <NodeLabel Key> <service-template>
3.使用示例
以在边缘部署nginx为例，我们希望在多个节点组内分别部署nginx服务，需要做如下事情：
1）确定ServiceGroup唯一标识
这一步是逻辑规划，不需要做任何实际操作。我们将目前要创建的serviceGroup逻辑标记使用的 UniqKey为：zone。
2）将边缘节点分组
这一步需要使用TKE@edge控制台或者kubectl 对边缘节点打 label，tke@edge控制台操作入口如下图：
3）界面在集群的节点列表页，点击 ”编辑标签“即可对节点打 label
•借鉴 ”整体架构“ 章节中的图，我们选定 Node12、Node14，打上label，zone=NodeUnit1；Node21、Node23 打上label，zone=NodeUnit2。
•注意：上一步中 label的key与ServiceGroup 的UniqKey一致，value是NodeUnit的唯一key，value相同的节点表示属于同一个NodeUnit。同一个 node 可以打多个 label 从而达到从多个维度划分 NodeUnit的目的，如给 Node12 再打上label，test=a1
•如果同一个集群中有多个ServiceGroup请为每一个ServiceGroup分配不同的Uniqkey
4）部署deploymentGrid
apiVersion: tkeedge.io/v1 kind: DeploymentGrid metadata: name: deploymentgrid-demo namespace: default spec: gridUniqKey: zone template: selector: matchLabels: appGrid: nginx replicas: 2 template: metadata: labels: appGrid: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
apiVersion: tkeedge.io/v1 kind: ServiceGrid metadata: name: servicegrid-demo namespace: default spec: gridUniqKey: zone template: selector: appGrid: nginx ports: - protocol: TCP port: 80 targetPort: 80 sessionAffinity: ClientIP
5）部署serviceGrid
可以看到gridUniqKey字段设置为了zone，所以我们在将节点分组时采用的label的key为zone，如果有三组节点，分别为他们添加zone: zone-0, zone: zone-1 ,zone: zone-2的label即可；这时，每组节点内都有了nginx的deployment和对应的pod，在节点内访问统一的service-name也只会将请求发向本组的节点。
另外，对于部署了DeploymentGrid和ServiceGrid后才添加进集群的节点组，该功能会在新的节点组内自动创建指定的deployment和service。
kubernetes从中心走向边缘
参考技术A1.Kubernetes从中心走向边缘Kubernetes是以应用为中心的技术架构与思想理念，以一套技术体系支持任意负载，运行于任意基础设施之上；向下屏蔽基础设施差异，实现底层基础资源统一调度及编排；向上通过容器镜像标准... 查看详情
面向视频领域的边缘计算白皮书
面向视频领域的边缘计算白皮书SDN/NFV/AI标准与产业推进委员会2020年12月1面向视频领域的边缘计算总体架构1.1总体架构本白皮书从边缘视频应用需求出发，结合业界通用边缘计算标准架构，提出面向视频领域的边缘计算总... 查看详情
kubeedge详解
...一个开源的系统，可将本机容器化应用编排和管理扩展到边缘端设备。它构建在Kubernetes之上，为网络和应用程序提供核心基础架构支持，并在云端和边缘端部署应用，同步元数据。100%兼容K8SAPI，可以使用K8SAPI原语管理边缘节点... 查看详情
基于ls1046a的边缘计算之人脸识别方案
...越多的智能设备出现，从数据的获取到数据的处理到深度学习，必须要在信息当中进行挖掘。信息爆炸，设备不堪重负，边缘计算应运而生。而未来数据的产生速度会逐步超过存储能力。在未来的5-10年，边缘计算比数据中心的... 查看详情
2021丨边缘计算领域值得关注的新书
2021年只剩下几天了。一起来回顾一下，今年边缘计算领域出了几本什么样的书？边缘计算社区向您介绍我们从中国版本图书馆发现整理的2021年边缘计算领域出版物。出一本书周期普遍需要2年以上，出书不易，每... 查看详情
将角色从屏幕边缘传送到边缘
】将角色从屏幕边缘传送到边缘【英文标题】：TeleportingCharacterFromEdgetoEdgeoftheScreen【发布时间】：2018-03-0502:52:33【问题描述】：我正在尝试将角色从屏幕边缘传送到我正在使用的相反边缘：varpos:Vector3=Camera.main.WorldToViewportPoint(tra... 查看详情
superedgev0.4.0发布，大幅提升使用和运维效率
关于SuperEdgeSuperEdge提供了一套基于原生Kubernetes的边缘容器管理系统，该开源项目是由腾讯云联合英特尔、VMware威睿、虎牙、寒武纪、美团、首都在线，多家公司共同发布。SuperEdge把云原生能力扩展到边缘侧，不仅很好的实现了... 查看详情
基于kubeedge的边缘节点分组管理设计与实现
摘要：KubeEdge1.11版本提供了“边缘节点分组管理”新特性，抽象出了跨地域的应用部署模型。本文分享自华为云社区《基于KubeEdge的边缘节点分组管理设计与实现》，作者：云容器大未来。KubeEdge1.11版本提供了“... 查看详情
高速网络加持下，ls1046a牵手边缘计算
...临难解的瓶颈和压力。从数据的获取到数据的处理、深度学习，云端必须要在ZT级庞大的数据中进行信息处理、数据挖掘。同时由于网络带宽的限制、高昂的传输成本和较高的响应延时的问题，设备将不堪重负。从云到边，重心... 查看详情
走向成熟的kubeedge边缘网络项目edgemesh详解
本文首发：容器魔方KubeEdge社区边缘网络方案致力于研究和解决边缘计算场景下跟网络连通、服务协同、流量治理等相关的一系列问题。其中，EdgeMesh子项目当前实现了边缘计算场景下应用的跨云边、跨边边的网络通信... 查看详情
opencv学习之路（17）边缘检测
一、概述二、canny边缘检测1#include"opencv2/opencv.hpp"2usingnamespacecv;34voidmain()5{6//Canny边缘检测7MatsrcImg=imread("E://1.png",0);//0表示以灰度图读入,彩色图和灰度图进行边缘检测时略有不同,建议使用灰度图8//medianBlur(srcImg,srcImg,5);//中值 查看详情
python从0到1丨细说图像增强及运算
摘要：本文主要讲解常见的图像锐化和边缘检测方法，即Roberts算子和Prewitt算子。本文分享自华为云社区《[Python从零到壹]五十七.图像增强及运算篇之图像锐化Roberts、Prewitt算子实现边缘检测》，作者：eastmount。一.图像... 查看详情
秒懂边缘云丨快速入门边缘云
简介：“秒懂边缘云”是阿里云开发者社区X阿里云边缘云团队面向企业及个人开发者联合打造系列直播，围绕边缘云的行业发展趋势、产品定义、应用场景，并结合阿里云边缘云深入浅出讲解，让广大技术人员从... 查看详情
addonsuperedge让原生k8s集群可管理边缘应用和节点(代码片段)
...原生领域，SuperEdge核心开发人员，现负责腾讯云边缘容器TKEEdge私有化相关工作。李腾飞，腾讯容器技术研发工 查看详情
youcans的opencv例程200篇149.图像分割之边缘模型(代码片段)
...例程200篇』系列，持续更新中欢迎关注『youcans的OpenCV学习课』系列，持续更新中【youcans的OpenCV例程200篇】149.图像分割之边缘模型2.点、线和边缘检测本节基于图像灰度的不连续性，讨论根据灰度的突变检测边界，... 查看详情
youcans的opencv例程200篇149.图像分割之边缘模型(代码片段)
...例程200篇』系列，持续更新中欢迎关注『youcans的OpenCV学习课』系列，持续更新中【youcans的OpenCV例程200篇】149.图像分割之边缘模型2.点、线和边缘检测本节基于图像灰度的不连续性，讨论根据灰度的突变检测边界，... 查看详情
5g核心网技术基础自学系列|边缘计算
书籍来源：《5G核心网赋能数字化时代》一边学习一边整理内容，并与大家分享，侵权即删，谢谢支持！附上汇总贴：5G核心网技术基础自学系列|汇总_COCOgsta的博客-CSDN博客边缘计算旨在使服务更接近要交... 查看详情
mysql之存储引擎大全-《从0到1-全面深刻理解mysql系列-第五篇》
个人主页:IT学习日记版权:本文由【IT学习日记】原创、在CSDN首发公众号:【IT学习日记】一个只搞干货的公众号如果文章对你有帮助、欢迎关注、点赞、收藏(一键三连)、有任何问题欢迎私信,看到会及时回复!文章大纲一、前言二:... 查看详情