今天是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的基本概念:
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 
 

kubeedge架构与核心设计---https://bbs.huaweicloud.com/webinar/100009的更多相关文章

  1. 《大型网站技术架构:核心原理与案例分析》【PDF】下载

    <大型网站技术架构:核心原理与案例分析>[PDF]下载链接: https://u253469.pipipan.com/fs/253469-230062557 内容简介 本书通过梳理大型网站 ...

  2. 认证鉴权与API权限控制在微服务架构中的设计与实现(四)

    引言: 本文系<认证鉴权与API权限控制在微服务架构中的设计与实现>系列的完结篇,前面三篇已经将认证鉴权与API权限控制的流程和主要细节讲解完.本文比较长,对这个系列进行收尾,主要内容包括 ...

  3. 大型网站技术架构(四)--核心架构要素 开启mac上印象笔记的代码块 大型网站技术架构(三)--架构模式 JDK8 stream toMap() java.lang.IllegalStateException: Duplicate key异常解决(key重复)

    大型网站技术架构(四)--核心架构要素   作者:13GitHub:https://github.com/ZHENFENG13版权声明:本文为原创文章,未经允许不得转载.此篇已收录至<大型网站技 ...

  4. zz《分布式服务架构 原理、设计与实战》综合

    这书以分布式微服务系统为主线,讲解了微服务架构设计.分布式一致性.性能优化等内容,并介绍了与微服务系统紧密联系的日志系统.全局调用链.容器化等. 还是一样,每一章摘抄一些自己觉得有用的内容,归纳整理, ...

  5. Java生鲜电商平台-SpringCloud微服务架构中核心要点和实现原理

    Java生鲜电商平台-SpringCloud微服务架构中核心要点和实现原理 说明:Java生鲜电商平台中,我们将进一步理解微服务架构的核心要点和实现原理,为读者的实践提供微服务的设计模式,以期让微服务 ...

  6. Java生鲜电商平台-App系统架构开发与设计

    Java生鲜电商平台-App系统架构开发与设计 说明:阅读此文,你可以学习到以下的技术分享 1.Java生鲜电商平台-App架构设计经验谈:接口的设计2.Java生鲜电商平台-App架构设计经验谈:技 ...

  7. ​grafana 的主体架构是如何设计的?

    ​grafana 的主体架构是如何设计的? grafana 是非常强大的可视化项目,它最早从 kibana 生成出来,渐渐也已经形成了自己的生态了.研究完 grafana 生态之后,只有一句话:可视化 ...

  8. 理解RESTful架构——Restful API设计指南

    理解RESTful架构 Restful API设计指南 理解RESTful架构 越来越多的人开始意识到,网站即软件,而且是一种新型的软件. 这种"互联网软件"采用客户端/服务器模式 ...

  9. RocketMQ详解(四)核心设计原理

    专题目录 RocketMQ详解(一)原理概览 RocketMQ详解(二)安装使用详解 RocketMQ详解(三)启动运行原理 RocketMQ详解(四)核心设计原理 RocketMQ详解(五)总结提高 ...

  10. 深入理解Kafka核心设计及原理(三):消费者

    转载请注明出处:https://www.cnblogs.com/zjdxr-up/p/16114877.html 深入理解Kafka核心设计及原理(一):初识Kafka 深入理解Kafka核心设计及原 ...

随机推荐

  1. Linux面试题 系统启动流程

    BIOS:基本输入输出系统,帮助我们初始化硬件 硬盘分区有两类:MBR和GPT ; MBR单块硬盘不能大于2T,主分区的数量不能超过4个:MBR方案存储在第一个扇区的前446个字节(共512字节,后面 ...

  2. Gitea 与 Jenkins 的集成实践,打造你的专属 CI/CD 系统

    前言 Gitea 是一个用于代码托管的轻量级单体程序,它能与现有的经典应用集成,诸如代码分析工具 SonarQube.持续集成工具 Drone.Jenkins 以及用于工单管理的客户端插件(VSCod ...

  3. Elastic:Elasticsearch的分片管理策略

  4. 第四章:Django表单 - 3:Django表单字段汇总

    Field.clean(value)[source] 虽然表单字段的Field类主要使用在Form类中,但也可以直接实例化它们来使用,以便更好地了解它们是如何工作的.每个Field的实例都有一个cle ...

  5. MongoDB 分片集群的用户和权限一般操作步骤

    步骤总结: 按照mongos路由.配置副本集服务,分片副本集服务的先后顺序关闭所有节点服务 创建副本集认证的key文件,复制到每个服务所在目录 修改每个服务的配置文件,增加参数 启动每个服务 创建账号 ...

  6. flask+gunicorn+nginx部署

    安装nginx和gunicorn yum install nginx pip3 install gunicorn flask项目配置 #main.py from flask import Flask ...

  7. SpringBoot 项目部署 (配置文件分离)

    1. SpringBoot 配置文件加载 SpringBoot 加载配置文件的优先级如下: 当前目录下的config 子目录: 当前目录: classpath下的config文件夹: classpat ...

  8. CentOS 7.9 安装 rocketmq-4.9.2

    一.CentOS 7.9 安装 rocketmq-4.9.2 地址: https://rocketmq.apache.org https://github.com/apache/rocketmq ht ...

  9. 多线程的使用(springboot)

    预备知识 业务使用多线程的原因 目的是面对高并发的时候,提高运行速度 场景一: 一个业务逻辑有很多次的循环,每次循环之间没有影响,比如验证1万条url路径是否存在,正常情况要循环1万次,逐个去验证每一 ...

  10. 1.RabbitMQ系列之服务启动

    1. docker方式启动MQ # latest RabbitMQ 3.10 docker run -it --rm --name rabbitmq -p 5672:5672 -p 15672:156 ...