转载

云原生实践-kubernetes核心架构基本介绍

IT软件领域有非常多的事实上的标准的实践的产品或者开源的系统，曾经我们在应用系统分布式化实践中也试图总结出分布式系统的最佳实践来帮助企业应用便捷的构建分布式应用。

云原生领域的kubernetes就是这样一个命题的实践成果，符合轻松快速构建一个分布式应用的要求，目前也成为了企业应用云原生化的事实标准。

kubernetes是一个开源的系统，用于自动化部署、扩展和管理容器化的应用。（这里只先说明kubernetes的主体核心架构，包括一些辅助工具，pod、service等概念暂时先忽略。）

kubernetes核心架构

一个可整体运行的kubernetes的架构如下：（该项目会不断的扩展模块，这里只列举可独立运行的模块）

云原生实践-kubernetes核心架构基本介绍

kubernetes整体的架构也是一个Master/Slave的集群结构，分为控制集群节点和计算节点两大部分，同时还有一个负责存储配置等相关信息的kv存储集群etcd。

一套正常可运行的kubernetes的集群主要包括如下可独立运行的模块：

1.Master

Master主要由三个核心模块组成：

1）kube-apiserver，是整个集群对外提供控制、配置等唯一入口，该服务主要提供rest风格的API服务能力。如果在kubernetes基础上构建自有的paas平台的话，通常在应用的配置管理、应用的发布调度等上面需要与该模块交互完成控制。

2）kube-scheduler，负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上。

3）kube-controller-manager，负责维护集群的状态，包括故障检测、自动扩展、滚动更新等。

2.Slave

Slave集群的节点主要由两个核心模块组成：

1）kubelet，负责维护计算节点的生命周期的模块，总得来讲主要是维护容器资源的生命周期，包括容器、网络、存储的管理。

2）kube-proxy，负责为Service提供cluster内部的服务发现和负载均衡，这个可以理解为计算节点上的负载均衡服务，因为一个计算节点可以运行多个容器，kube-proxy将为这些容器实例提供负载能力。

3.etcd

kubernetes架构设计优秀的地方在于协调这个分布式信息使用的kv存储库，还有就是分布式模块交互都是通过API Server+etcd中存储模型来进行交互，这种模式非常好的解耦了整个编排系统之间的耦合性，提升了扩展能力。

etcd是一套提供分布式协调能力的kv存储库，相比zookeeper在存储读写数据的稳定性和性能会比较好些。后续再详细说明，此处只简单介绍下。

kubernetes概要交互流程

云原生实践-kubernetes核心架构基本介绍

在kubernetes整体的Master/Slave结构中，控制集群中的API Server是所有交互的核心和关键模块，主要提供如下作用：

1）面向外部，kube-apiserver作为提供API服务的模块，面向外部可能的UI界面操作请求和CLI命令操作请求提供统一的API调用服务。

2）面向内部，外部的控制请求通过kube-apiserver存储在kv数据库etcd，包括各类创建容器等实例的规格配置等。内部的kube-scheduler和kube-controller-manager都会围绕kube-apiserver提供的核心API来运作。

kubernetes概要的运作流程如下：

1）kube-apiserver接受到外部配置调度容器实例的规格请求，将该配置请求数据存放在etcd。

2）kube-scheduler负责具体计算节点上容器的调度，该调度主要也通过kube-apiserver来访问etcd获取相应的需要调度的容器规格配置信息，根据配置的调度策略来实现实例在计算节点上的调度，最近将选择启动的实例信息绑定具体的node信息。

3）kubelet启动后通过与kube-apiserver交互完成自身节点的注册和状态报告，同时kubelet也通过其提供的接口监听容器实例的分配绑定节点信息，调度本地实例启动。

4）kube-controller-manager主要负责维护集群状态，通过kube-apiserver访问相应的etcd的信息，确保其启动的相应的实例状态的故障检测、故障恢复，或者相应的版本滚动更新或者自动扩展等。

kubernetes核心代码构成

kubernetes是一个由多个独立模块以及pkg组件库和第三方依赖的组件库组成的容器编排系统，源码的目录有很多，这里列举核心的源码构成如下（我们主要从独立可运行的模块代码入手）：

云原生实践-kubernetes核心架构基本介绍

kubernetes按照前面介绍的架构，分为控制集群和计算集群两部分，不同集群内部有不同对应功能的独立运行模块。

其余的pkg是该平台系统的内部依赖组件，vendor是第三方的依赖组件，这里有些小差异就是staging目录存放的组件，实际上大多数也是kubernetes自有的，只不过在归类的时候，在第三方和自有方面有一些不确定性，所以在代码的结构管理上，都下载存放在了这里，后面源码编译实践可以看到，这部分的go mod管理下载的组件需要拷贝到vendor对应的目录。

一个完整的可运行的kubernetes只需要关注如上的代码目录结构即可，基本上包括了kubernetes运行主体服务实现。

原文 https://blog.csdn.net/wangfengwf/article/details/104749011

正文到此结束