学者网
看论文：《Optimized container scheduling for data-intensive serverless edge computing》
这是我目前找到的关于边缘计算的最新论文，内容和我正在看的KubeEdge有点像——都是在Kubernetes的基础上，针对边缘场景做改进。不同的是，KubeEdge主要是给Kubernetes换成端边云架构，并且支持更多通信协议；而论文是给Kubernetes换上更适合边缘场景的调度器。
Kubernetes 是一个容器调度系统，它将多台服务器（节点）连成一个集群，想让这个集群部署什么，只要给它一个配置文件，里面写一些元数据、想部署的容器镜像的名字，它就会指挥一个节点来进行自动化部署，也就是让这个节点从Docker Hub上拉取、并创建容器运行这个镜像。具体是让哪一个节点进行部署，这个决策过程就称为“调度”。
原版Kubernetes调度器不是针对边缘场景设计的，就没考虑节点间的距离、不同节点各自的带宽与硬件资源。像有的节点有GPU、有的没有，不具体考虑的话就无法充分利用资源。因此论文为Kubernetes设计了一个新的调度器，比原版提高了边缘场景下的调度的质量。
调度器的工作就是：给调度器一个部署任务，调度器返回一个最合适的节点。其实就是先筛掉明显不行的节点，再给剩下的节点打分，挑选分数最高的。
关于怎么排除明显不行的结点，需要先收集元数据： 1.部署任务的元数据（部署后必须从哪个节点下载哪些数据才能执行、需不需要GPU） 2.节点的元数据（网络带宽、可用计算资源、存了什么公共数据）。其中节点的元数据是定时自动更新的。用元数据可以排除掉计算资源明显不够的节点。
关于怎么给节点打分，就是根据预估的数据下载时间（数据量÷带宽）、资源需求与可用资源的吻合度（吻合一项加1分）等，弄了4个优先级函数，最终分数就是这4个优先级函数的带权重求和。（关于权重怎么算，是定义了4个目标函数，分别对应下载数据的总时间、上下带宽使用率、节点资源使用率、调度过程的带宽与时间开销，按最优化问题求解。）
做边缘计算平台：
找到一个KubeEdge的例程，包含边端、云端两部分，部署出来了，但是云-边两个Pods的通信有问题。排错的过程中突然想更新一下新版的KubeEdge环境，结果环境没更新成，连Edgecore与Cloudcore都连接不了了，修了两天才绕回来，一开始的Pods间的通信问题到最后也没解决，留到下周。
评论 0