下面我们来一起学习一下KubeEdge与Kubernetes的区别和联系。
通过前面的学习，相信你已经对KubeEdge的架构有了比较深刻的了解。回忆一下，但是我们在讲解 KubeEdge 云端架构设计的时候，有提到就是KubeEdge与Kubernetes的交互，是通过CloudCore监听Kubernetes的API Server 完成的。
由于当时我们的重点在于了解清楚KubeEdge的架构设计，具体KubeEdge与Kubernetes是如何协同工作的，并没有展开讲解。所以现在我们将它们二者的区别和联系来系统梳理一下。
我们就先来了解一下Kubernetes的架构设计，
从架构设计图可以看出Kubernetes架构分为了Master的节点和Node的节点两个部分，对于Kubernetes来说，它是没有云和边的概念的，它所有的节点都在同一个网络层面上，所以它只有Master的节点和Node的节点这样的区别，并没有云边这样一个概念。
然后下面我们就来看一下Kubernetes的Master的节点和Node的节点，它们各自的架构设计。
我们以用户创建一个deployment资源为例，来看一下在整个Kubernetes架构设计当中各个模块所承担的任务。
完事之后我们基本上就对整个Kubernetes的架构设计有一个比较清晰的认识了。
首先第一步就是用户创建deployment 的本质就是调用deployment的 API Server 所提供的类似的Restful API， API Server它是 Kubernetes 资源操作的唯一的入口，并且提供了认证授权访问控制的各种功能。
后面我们在开发边缘计算管理平台的时候，我们会详细的分析有关Kubernetes的认证和授权相关的内容，然后用户创建了deployment的资源定义的信息，会通过 etcd 进行存储。etcd 它是一个高可用的键值对的数据库，云原生领域数据实际化的首选方案，并且保存了整个集群的一个状态。
然后这边用户定义的development资源被存下来之后，然后下一步就轮到 Controller 登场了，Controller 就是使用户定义的development资源变成Kubernetes当中真正运行的资源， Controller有非常多的类型，例如我这里指定的是deployment，那么对应的就是development的Controller，
那么此时就相当于Controller根据我们对应的资源去创建了对应的pod，那么pod还没有分配具体运行到哪个节点上面，此时Scheduler的就登场了，Scheduler 它的工作就是负责将pod的调度到某个节点上，它有非常多的调度算法，会根据我们实际运行pod所需的资源以及节点的资源等综合判断，决定调度到哪个Node上面。
当然如果我们定义了development的时候，就指定的运行在某个节点上面，那么就不会用到它的一些调度算法。
然后 Scheduler 创建之后，就是我们的pod 和 node 进行了绑定，但是这个 pod 还是没有真正的运行在我们 node 的上面，
所以说下一步就是 Kubelet 登场了，Kubelet 默认是每隔20秒向API Server 通过自己的node_name获取自身node上所需的 pod 的清单，
通过与自己的内部缓存做比较，然后新增pod，
然后Kubelet就会调用对应的 node节点上的容器运行时去创建对应的pod。
这就是我们从Kubernetes的各个组件的功能出发，来了解了一下Kubernetes的架构设计。
关注我，为思考点赞！