kubeedge架构与核心设计---https://bbs.huaweicloud.com/webinar/100009

课程介绍

今天是kubeedge的第一节课，今天主要带大家回顾一下云原生和边缘计算的发展历程 然后我们会重点介绍一下kubeedge这个项目，他的设计背景和核心理念与我们整体的架构

发展历程

首先是我们来简单回归一下云原生的发展历程

  • 云原生可以借助一张经典的时间线回顾

  • 从早期的2000年，大家在部署或者当你需要去上线一个网站的时候，
    往往是需要购买一台物理的服务器的
    在物理的服务器上去安装操作系统，

  • 然后在部署你的软件和你的网站，当你的网站需要扩容的时候
    或者说你要上线新的应用的时候，你要去购买新的应用

  • 那么在2001年的时候出现了虚拟化的技术，主要是vmware引领了虚拟化的浪潮，那么给大家带来的利好就是，你不需要再去扩新的服务器，你可以在服务器上，通过虚拟化技术，去切出一些小型的虚拟机，

  • 然后在这些不同的虚拟机中，有一个干净的环境去部署新的应用，这个时间持续的比较久，

  • 一直到2006年，出现了云计算的产品，早期的产品就是我们所说的iaas，这里面的代表是aws,aws他的重大的进步是，把虚拟化的技术云化，
    然后提供给用户，这个阶段，用户虽然用上了虚拟化，

  • 但是还是要去购置一定数量的服务器作为你的资源池，
    你上了iaas，上了公有云之后，你不在需要投入成本去维护你的物理的资源池，
    可以直接通过公有云的平台去租用一个虚拟机，

  • 那么实际上你的这个基础设施，这个颗粒度从原来的物理服务器变成了这个虚拟机

  • 然后到2009年的这个时候是heroku这个私有云的团队的pass平台的出现，那他又把这个资源扩容的颗粒度，往前推了一步，

  • 他提供是基于buildpack的来做的，从云源码到应用的一个部署，也就是说你也不再需要去通过申请虚拟机，然后再来安装应用，
    已经相关的环境依赖，来部署你的新的网站了或者所其他的应用，你只需要将你的源码提交，他就会自动将你的应用拉起。

  • 然后到2010年，其实是在基础的云原生上开源的方向演进，这里出现了openstack这个项目，他主要还是从这个颗粒度来看，他的资源扩容的资源还是虚拟机。但因为开源技术的出现，云原生变得容易获得，企业如果要部署自己的云，使用openstack就可以了。

  • 或者也有厂商基于openstack来提供公有云的服务。
    那么2011年cloudfoundry，实际上是将pass这个云提供了开源的实现，那么他依然采用的是buildpack的服务，从源码到应用的线上部署，

  • 然后到2013年，docker容器技术的出现，真正将云的热度推上了一个新的高度，

  • 因为他是通过容器分层的技术，将你的应用以及你对环境的依赖大包，并且通过dockerhub,整个容器镜像分发的标准，让所有人的应用他中间的层次，

  • 比如说你这些网站的基础层，你可能说有这个数据库，中间的控制层，上面的视图层，都变得更容易分享，大家可以在现有的基础上做少量的定制开发就可以实现你自己的一个web应用，然后容器技术的出现，实际上或者说docker更多的解决的是在单机上去运行容器，

  • 他简化的是单机上部署容器的这个过程，一直到15年，k8s这个项目的出现才真正的把容器技术推上了公有云，或者说是在一个很大的资源池的情况下，可以非常轻松的去部署管理你的应用，可以配置自动的扩缩容的策略也不是基于buildpack从源码到应用的过程，这个透明度过低的情况。

  • 而造成一些调试，以及后期二次开发上的困难，容器整体上来说，在这个颗粒度上找到了很好的平衡点，

  • 从这个时间上来看，我们这里有几个核心的要素，第一个就是我们这个应用，扩容的单元，

  • 从原来的物理服务器，到虚拟机，到中间的快速到buildpacks，一直到后面又回到容器，从这个隔离单元，或者说是资源分配的颗粒度上来说，从原来非常重的服务器，

  • 一直到如今广泛的容器，资源也精确到0.1个核或者100M内存或者更小的颗粒度，整个端到端的上线来说也从原来的服务器采购上线的几个月，

  • 到如今端到端的秒极扩缩，是一个非常大的改进，实际上在使用体验上的类比是从一个宠物到牛的对比，过去你是像养一个宠物一样，既要精心照料你所有的基础设施，你的应用的配置，到如今更像是一头牛，你只要指挥他去干活进行。

  • 同时在这里的一个变化就是从原来商业上单一的供应商到开源供应商的模式，
    开源技术的流行，让厂商开源更加流行的提供这种通用性的服务，那么对于用户来说，他可以在更多的厂商之间选择合适自己的不管是从架构还是配套上，

  • 实际上2015年，只是云原生的开启之年，然后k8s从16年到19年一直都持续的火热，他也进3，4年来最火热的开源项目之一，

  • 同时，还出现了其他开源项目，但是还是没有K8s来的猛，现在的话，用户在这个使用，开源技术，用户往往会选择容器，容器已经成为了一个大趋势，另外我们也是成立了一个云原生基金会，整个基金会的版图也是不断的在扩张，整个基金会从早期的实际上只有k8s一个核心的项目，大家可以看到很多项目出现，现在提供的厂商也非常多，类别也非常多，有非常多选择的工具或者产品

边缘计算

  • 接下来我们看一下什么是边缘计算，首先我们来看一下章鱼，章鱼有一个特点，他的40%的神经元是在头部，其他60%的神经元是在触角上，那么这个分布有一个特别的好处就是，他处理问题，是直接在末端就进行思考处理了也就是他的腿来完成，从生物上角度来说，他最大的好处来说，就是减轻了他大脑的功耗，大家知道，生物的算力还是很强的，但是大脑可以维持在一个低功耗的水平，

  • 就是因为有大量的神经元树突分布在末端处理，那么边缘计算的兴起，主要是因为万物互链的到来，边缘上的设备是爆发式的增长，

  • 但是我们基础上的能力的发展跟不上这样的速度，比如说我们这个网络接入或者我们网络的数据中心，他的时延和带宽是跟不上边缘爆发式的增长的，所有这就会出现一个问题，

  • 这个时延就是一个很大的问题，如果你全部接入数据中心处理，那么你的带宽或者能耗都是非常有限的，另外一个还是就是数据隐私上需要必要不必要的数据产出来保护我们用户的隐私，这里我们借助业界的一个典型的分类图

  • 首先是中心云，分布在数据中心，通常说，一般到数据中心响应的时间在100ms左右，

  • 随着我们业务的发展，我们对时延有更高的要求，现在一般都是用cdn，处于运营商端，
    我们称为近场计算，通常的时延在5-20ms,通常数量也是呈级数递增，然后靠近终端用户，

  • 比如我们的智能家居，具有一定的算力，其实我们可以将家庭生活逻辑的处理都放在智能设备商去，对应的还有一些超市和一些企业，已经办公楼，园区等，这些都是近场计算，他非常靠近反馈源，一般我们把近场的时延定义在5ms以内，这个数量一般是百万级以上，

  • 归纳上，边缘计算有几大方面的价值，一个是链接的广泛性，因为他高度分散，能够覆盖到各个靠近终端，数据带宽的优化，因为他直接靠近用户，比如CDN,我们现在的数据流都是先拉到cdn,然后再从cdn到节点，然后是本地网络有一定的自治能力，提高了一定的实时性，时延<10ms，数据的安全性，一般隐私数据都在本地处理，只有少量数据才会经过计算后上传到云端。

  • 简单回顾一下，这个发展历程：边缘计算这个概念，是在美国太平洋西北国家实验室于2013年提出，2015年由欧洲ETSI发布关于移动边缘计算的白皮书，2016年有美国州立大学有一个正式的定义，直到2018年，相继发布各种边缘产品，

  • 直到2019年Kubeedge正式加入CNCF的官方项目，同时linux基金会也针对边缘计算的场景去成立了边缘计算伞型社区。

  • 总结一下边缘计算，主要推动快速发展的主要几点：

  1. 低时延
  2. 海量数据
  3. 隐私安全
  4. 本地自治（云端离线是可以离线处理，并且可以检测网络状态自行恢复）

k8s

  • 成为事实标准的k8s
  • k8s的基本概念：

Pod

  • 应用实例,一组功能相关的container的封装
  • 共享存储和Network Namespace
  • K8s调度和作业运行的基本单元（scheduler调度和kublet运行）

Workloads

  • 应用部署模型，一组功能相关的pod的封装

Service,Ingress

  • 应用的访问方式，Pod"防失联"
  • 给一组pod设置反向代理，做负载均衡，保障业务可靠性

Persistent Volume

  • 主要是应用，存储分离，独立于pod生命周期的存储卷

ConfigMap,Secret

  • 部署配置分离（不用每次换环境都需搞配置）

设计理念：

  1. 只有API Sever才可以访问etcd
  2. 组件通过API Server访问集群状态
  3. API采用声明式设计

Advantages

  1. 容器化封装 build once,run anywhere
  2. 通用的应用抽象定义
  3. 松耦合的架构

Chanlleges:

  1. 资源有限
  2. 网络受限
  3. 边缘如何离线自治
  4. 设备接入和管理

k3s（集群在边缘，边缘集群） vs kubeedge（只有节点运行在边缘，边缘节点）

KubeEdge项目：

  1. 首个边缘容器平台项目
  2. Apaceh2.0
  3. 2019年，加入CNCF
  4. K8s Iot Edge WG参考架构
  5. 100%兼容k8s api

核心理念：

  1. 云边协同
  2. 边缘离线
  3. 极轻量

KebeEdge架构：

  1. 云上CloudCore(kubctl管理并不知道是管理的云上还是边缘的node，统一交给k8s处理)，边缘EdgeCore
  2. Edge持久化云数据存储，实现自治
  3. 所有节点驱动通过CSI接入
  4. 边缘使用edgeMesh来服务发现
  5. 设备端支持MQTT,Mappers转mqtt

KubeEdge云端组件：

  1. EdgeController pod 管理
  2. 设备抽象API/DeviceController
  3. CSI Driver 同步存储数据到边缘
  4. Admission WebHook 校验进入KubeEdge数据

KubeEdge边缘组件

  1. EdgeHub 提供可靠的云边同步消息
  2. MetaManager 元数据本地持久化
  3. Edged-kubelet-lite 轻量化实现pod生命周期
  4. DeviceTwin -同步设备信息到云端
  5. EventBus - mqtt client
  6. ServiceBus - http client

KubeEdge关键能力：

  1. 支持CRI接口，可集成Containerd,CRI-O
  2. 支持CSI接口在边缘集成容器存储
  3. 边缘设备管理
  4. EdgeMesh:ServiceMesh at edge

1.KubeEdge的架构特点与优势

持久化

  • 云端组件，EdgeController,设备抽象API,CSI Driver,Admission WebHook
  • 边缘组件，EdgeHub,MetaManager,Edge,DeviceTwin,EventBus,ServiceBus

与k3s对比

2.KubeEdge源码分析

3.运行一个KubeEdge集群

4.使用KubeEdge管理边缘应用于设备

  • 交通灯
  • 空气净化器

5.KubeEdge社区开发快速上手

posted @ 2022-02-19 19:51  易先讯  阅读(206)  评论(0)  编辑  收藏  举报