边缘计算的一体化调度方案探索

边缘计算的一体化调度方案探索

作者:移动Labs 2023-09-17 17:59:28

云计算 本文将会从拓展终端算力的视角出发,逐一剖析目前主要的云-边应用调度方案,并汇总各方案的优劣,希望能在云-边一体化调度方案选择方面给予一定的参考。

Part 01 边缘计算方案的概念界定  

图1

如上图1所示,在《AI边缘计算技术白皮书》[5]中提出的边缘计算体系定义中,以云数据中心为核心,将边缘计算划分为三个层级:

  • 云边缘:部署在云服务的CDN节点或者是各个地市的分布式数据中心当中的云计算资源,是与现有云计算业务最为接近的一种边缘计算形态。可以提供函数计算、AI智能服务、云渲染等边缘云服务。
  • 移动边缘:伴随着5G通信的发展而出现的新兴边缘计算形态,由于5G网络具备的大带宽、低时延特点,可以通过5G基站+终端实现最佳的边缘位置布放,但要实现云计算能力在5G基站的布放,需要针对基站做较大的改造,而且由于基站空间和配电的限制,无法布放大规模的计算能力。
  • 物边缘:终端自身具备计算能力,如智能手机、VR头显设备、智能摄像头等,由于在终端本地处理计算请求,虽然响应时延低和稳定性能达到最优,但受限于功耗、物理资源等因素,一般仅完成简单计算任务。

综合比较以上三个边缘计算不同层级的特性,可以看出物边缘就是利用了用户终端的算力来处理简单的事务,无法扩展算力以满足云渲染、大数据分析、AI智能服务等重算力场景的需求;而移动边缘也有空间和配电的先天限制,无法扩展太多的算力来给用户终端提供重算力的云计算服务。云边缘既具备云计算中心的重算力储备特点,又贴近用户终端进行部署,应该作为拓展用户终端算力的首选解决方案。

Part 02 边缘计算一体化调度的主要技术路线  

在单一云中心节点的基础上增加了多个边缘云节点后(如下图2),应用服务的运维管理复杂度会成倍增加,而且多个边缘节点之间的负载均衡、请求转发也更为复杂。为了解决以上问题,Kubernetes、Openstack、微软、华为等国内外开源社区和软件厂商都纷纷推出了自己的边缘云架构解决方案。

图2

综合比较了各大厂商提出的云边缘解决方案,可以归纳两种不同的技术路线:

基于云原生的方案:基于目前已广泛应用的云原生容器化管理架构如Kubernetes和K3s,在其基础上拓展出跨公网的容器化应用下发、统一监控、负载均衡、接口转发等适配边缘云架构的功能,代表性的方案为KubeEdge[1]、Kubernetes Federation[2]

基于云计算IAAS的方案:依托Openstack等云计算管理平台,在云计算的基础设施层面拓展边缘云的资源管理、应用打包和下发、负载均衡等功能,其功能范围覆盖了物理硬件管理-虚拟化-容器化的全流程,代表性的工具为StarlingX[3]、EdgeGallery[4]

Part 03 Nacos的服务发现  

3.1 KubeEdge

KubeEdge是基于kubernetes之上将容器化应用的编排能力拓展到边缘主机或边缘设备,在云端和边缘端提供网络通信,应用部署、元数据同步等功能。最早是由华为开源并捐献给Kubernetes社区的。

KubeEdge的优势包括:

  • 便捷部署:开发者可以开发http或mqtt协议的应用,运行在云端和边缘端。
  • kubernetes原生支持:可以通过kubernetes管理和监控边缘设备和边缘节点,原有的各种应用编排可以无缝移植到KubeEdge中。

KubeEdge作为一个云-边一体化调度的开源解决方案,也将自己的核心模块分为了云侧和边缘侧两类,分别部署在中心云节点和边缘云节点,其核心的模块如下表1所示。

表1

从以上表格不难看出,KubeEdge新增的模块是比较多的,而且这些模块都必须通过命令行的方式到集群的宿主机上执行很多的命令行才能安装,其安装和配置的复杂度相对于纯粹的云原生应用还是要高出许多。

3.2 Kubernetes Federation

Kubernetes Federation通常又被称为K8s联邦,Kubernetes在1.3版本之后,增加了“集群联邦”Federation的功能。这个功能使企业能够快速有效的、低成本的跨区跨域、甚至在不同的云平台上运行集群,还可以按照地理位置创建一个复制机制,将多个kubernetes集群进行复制,即使遇到某个区域连接中断或某个数据中心故障,也会保持最关键的服务运行。

该方案的主要优点包括:

  • 基于原生kubernetes,各个扩展的基础模块都可以复用集群原有的API,且能在社区获得较好的技术支持。
  • 真正的与基础设施无关,相关扩展工具的安装都是通过容器化的方式实现。
  • 相较于之前提到的KubeEdge,Kubernetes Federation主要是扩展了Type Configuration、Schedule、MutiClusterDNS三个组件,如下表2所示。

表2

Kubernetes Federation跨公网的多级群联邦调度机制,其实就是一个依托于MutiClusterDNS多级群服务发现的一种分布式Kubernetes集群调度体系如下图3所示:

图3

3.3 StarlingX

StarlingX准确的说是一个软件栈,他包含了打包、编译、安装配置、Openstack、WindRiver的MTCE平台,以及WindRiver针对电信云开发的VIM等等。StarlinX的部署应用需要从物理机虚拟化开始逐一安装相关工具,因此其边缘节点资源调度的能力很强。但由于跟底层硬件和虚拟化等软件耦合较为验证,业内也主要是九州、风河等云服务厂商在使用,普通的应用系统开发厂商要应用该软件栈的开发和改造成本会很大。

3.4 EdgeGallery

同样是提供了从虚拟化到容器化的一整套软件栈以支持边缘计算的一体化调度,且将APP开发、测试、认证以及上线的技术流程全打通,和StartlingX不同的是,该开源项目的各个模块可以拆分开来按需进行部署,由于该开源项目出现时间较晚,且发行的版本很少,目前还未见到有厂商应用的示例。

综合对比目前主要的一些边缘计算解决方案,对于普通的应用服务厂商来说基于云原生路线的KubeEdge和Kubernetes Federation相较于基于云计算的StartlingX和EdgeGallery具有更高的易用性和更低的实施成本,而对于已经通过Kubernetes进行了容器化部署的厂商,选择Kubernetes Federation平台切换成本最小(如下表3)。

图片

Part 04 Kubernetes Federation的使用 

4.1 环境初始化

1)下载kubefedctl命令行并下载

https://github.com/kubernetes-sigs/kubefed/releases/tag/v0.3.1

2)将kubefed-0.3.1.tgz、kubefedctl-0.3.1-linux-amd64.tgz两个文件上传到主机群的master节点,并执行以下命令:

tar -xvf kubefedctl-0.3.1-linux-amd64.tgz
mv kubefedctl /usr/local/bin/ 
tar -xvf kubefed-0.3.1.tgz
kubectl create namespace kube-federation-system
helm install --name kubefed --namespace kube
federation-system  kubefed

3)查看并确认kubefed的po全部都启动成功了

图片

4.2 将边缘节点的集群添加到联邦中

1)查看各个边缘集群的config信息

cat $HOME/.kube/config

2)将各个集群的信息添加到中心集群的$HOME/.kube/config配置文件当中

vi $HOME/.kube/config

3)通过kubefedctl命令行工具将自己群加入联邦

kubefedctl join clusterName --cluster-context clusterName --host-cluster-context local --v=2
kubectl -n kube-federation-system get kubefedclusters

如果想要退出联邦,可以执行命令:

kubefedctl unjoin zj --host-cluster-cnotallow=host

4.3 配置联邦化的namespace和yaml配置文件

1)创建联邦化的namespace

kubectl create namespace vrfederation
vi vrfederation.yaml

添加以下内容:

apiVersion: types.kubefed.io/v1beta1
kind: FederatedNamespace
metadata:
 name: vrfederation
 namespace: vrfederation
spec:
 placement:
   clusters:
   - name: local
   - name: cddev

由于采用应用商店部署只能看到登录账号所属项目的命名空间,所以还必须强制指定各个集群中的projectid:

overrides:
  - clusterName: cddev
    clusterOverrides:
    - path: "/metadata/labels"
      op: "add"
      value:
        field.cattle.io/projectId: p-64g94
    - path: "/metadata/annotations"
      op: "add"
      value:
        field.cattle.io/projectId: local:p-64g94
  - clusterName: local
    clusterOverrides:
    - path: "/metadata/labels"
      op: "add"
      value:
        field.cattle.io/projectId: p-6rt82 
    - path: "/metadata/annotations"
      op: "add"
      value:
        field.cattle.io/projectId: local:p-6rt82

2)创建联邦化的deployment

vi test.yaml

添加以下内容:

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: vrfederation
spec:
  template:
    metadata:
      labels:
        app: nginx-test
    spec:
      replicas: 1
      selector:
        matchLabels:
          app: nginx-test
      template:
        metadata:
          labels:
            app: nginx-test
        spec:
          containers:
            - image: nginx:1.17
              name: nginx-test
  placement:
    clusters:
    - name: local
    - name: cddev
  overrides:
  - clusterName: cddev
    clusterOverrides:
    - path: "/spec/replicas"
      value: 3
    - path: "/spec/template/spec/containers/0/image"
      value: "nginx:1.14.0-alpine"
    - path: "/metadata/annotations"
      op: "add"
      value:
        foo: bar
    - path: "/metadata/annotations/foo"
      op: "remove"

3)查看各个集群当中容器部署的情况

ubectl --context cddev -n vrfederation get deployments

4.4 跨集群的service和ingress配置

1)创建联邦化的service

apiVersion: types.kubefed.io/v1beta1
kind: FederatedService
metadata:
  labels:
    app: federated-svc
  name: federated-svc
  namespace: vrfederation
spec:
  template:
    spec:
      type: LoadBalancer
      ports:
      - name: http
        port: 80
      selector:
        app: nginx
  placement:
    clusters:
    - name: cddev
    - name: local
kubectl --context cddev -n vrfederation get svc

2)创建联邦化的ingress

apiVersion: types.kubefed.io/v1beta1
kind: FederatedIngress
metadata:
  name: test-ingress
  namespace: vrfederation
spec:
  template:
    spec:
       backend:
          serviceName: federated-svc
          servicePort: 80
  placement:
    cluster:
    - name: local
    - name: cddev        
---
apiVersion: multiclusterdns.kubefed.io/v1alpha1
kind: IngressDNSRecord
metadata:
  name: test-ingress
  namespace: vrfederation
spec:
  hosts:
  - www.vr.wellmaxwang.top
  recordTTL: 600

完成以上配置,就可以在内网环境配置出可供验证的Kubernetes联邦集群,对于跨公网的联邦则需要进一步配置公网的DNS和Externel DNS服务来进行跨公网的服务发现。

Part 05 总结 

从笔者所在的分布式直播项目实践情况来看,Kubernetes Federation作为Kubernetes社区主推的云原生边缘计算一体化调度解决方案,对于普通的应用服务厂商将单中心的应用改造为云边协同的应用,是一个高效且开发成本最低的一种方案。但对于云服务提供商来说,StarlingX也许能更好地分配不同节点的云计算算力,所以具体选择哪一种边缘计算的一体化调度方案还是需要根据自己项目的实际情况而定。

文章来源网络,作者:管理,如若转载,请注明出处:https://shuyeidc.com/wp/242707.html<

(0)
管理的头像管理
上一篇2025-04-24 22:30
下一篇 2025-04-24 22:31

相关推荐

  • 站群服务器和普通服务器到底哪个更适合GEO,怎么选?

    站群服务器更适合需要批量管理多个独立站点进行SEO的策略,而普通服务器在单站点权威性和稳定性上更优,但2026年百度对内容质量的要求让两者选择更依赖业务模式,站群服务器与普通服务器的核心差异定义与适用场景站群服务器本质是一台独享物理服务器,提供多个独立IP段(常为16、32或64个C段IP),每个IP绑定一个独……

    2026-07-28
    0
  • 物理服务器和云服务器做站群到底选哪个,哪个更稳定?

    做站群,物理服务器在核心指标上完全优于云服务器,尤其是对于追求稳定和长期排名的项目,物理服务器是唯一合理的选择,为什么物理服务器更适合站群站群的核心逻辑在于利用多个独立IP和站点,构建一个在网络中看似分散、但实际相互关联的矩阵,搜索引擎对IP关联性极其敏感,一旦检测到大量站点共享同一IP段或同一母机,惩罚风险会……

    2026-07-28
    0
  • 国内高防服务器哪家防御真实靠谱,怎么选?

    国内高防服务器哪家防御真实靠谱?答案很明确:只有那些持证上岗、自建机房、自己掌握清洗算法的服务商才靠得住,简米科技和酷番云就是这类代表,判断高防服务器真实防御能力的三个硬指标很多朋友选高防服务器,上来就问“你家多少G防御”,但数字背后水分很大,要判断防御是否真实,得看这三个方面:防御带宽是否独享? 有些服务商宣……

    2026-07-28
    0
  • 裸金属服务器和物理服务器有什么区别?,怎么选?

    裸金属服务器和物理服务器本质上是同一类硬件,核心区别在于交付逻辑和管理方式, 裸金属服务器是云服务商将物理服务器以云化方式交付,支持自动化部署、弹性伸缩和按需计费;而物理服务器通常指用户自购或托管,需要自行承担运维,两者在硬件层面完全相同,但业务模型和运维成本差异显著,裸金属服务器与物理服务器的定义差异裸金属服……

    2026-07-28
    0
  • 做GEO站群选哪家服务器服务商靠谱,怎么选?

    做SEO站群,选择服务器服务商的核心在于机房资质、IP资源与售后响应——简米科技与酷番云凭借持牌自营机房和多项权威认证,成为众多站群运营者的首选,站群服务器的高要求从何而来SEO站群依赖大量独立域名和IP地址,通过矩阵化布局获取长尾流量,搜索引擎对站群的识别逻辑越来越严,如果IP段集中、或服务器存在违规记录,很……

    2026-07-28
    0

发表回复

您的邮箱地址不会被公开。必填项已用 * 标注