Kubernetes源码分析(一)

### Kubernetes1.14.0 和 First commit###
### 拉取历史版本的方法：先从master上随便拉取一个版本(拉取的版本不能低于想要拉取的版本)： 
			git pull https://github.com/kubernetes/kubernetes/tree/v1.14.0
		再按照commit信息获取commit ID:
			git log --grep "First commit"
		最后回滚到历史版本：
			git checkout 2c4b3a562ce34cddc3f8218a2c4d11c7310e6d56

一、简介
    · 认识Kubernetes
      1. 前面提到了Google Borg的本质是一个分布式的资源管理系统，随着容器技术的发展，Kubernetes作为Borg的根据时代发展衍生的升级，其本质上也可以认为是一个分布式资源管理系统；
			2. Kubernetes是Google公司开源的容器(Container) 编排与调度管理框架，也就是面向容器的集群管理系统；
				作为一个容器编排引擎，Kubernetes提供了一个抽象层，使其可以在物理或虚拟环境中部署容器应用程序，提供以容器为中心的基础架构；
		
		· Kubernetes系统具有的特点：
			1. 可移植性：支持公有云、私有云、混合云、多重云；
			2. 可扩展性：模块化、插件化、可挂载、可组合；
			3. 自动化：自动部署、自动重启、自动复制、自动伸缩/扩展；

		· 基本概念
			1. 组成：	Kubernetes集群由代表controller的组件和一组称为节点的机器组成；
			2. 对象：	对象是Kubernetes系统中持久化的实体，Kubernetes使用这些实体来表示集群的状态；
								学习使用Kubernetes就是了解Kubernetes的对象模型以及如何使用这些对象的；
			3. API：	可以通过Kubernetes API来查询和操纵Kubernetes中的对象的状态；
								Kubernetes的controller的和兴就是API Server和它暴露的HTTP API；
								用户、集群的不同部分以及外部组件都通过API Server相互通信；
		
二、基本架构	
		· Kubernetes系统用于管理分布式节点集群中的微服务和容器化应用程序，
			· 并且其提供了零停机时间部署、自动回滚、缩放功能和容器的自愈(其中包括自动配置、自动重启、自动复制的高弹性基础设置，以及容器的自动缩放) 等功能；
			  如果说Borg是为了减轻SREs的工作负载，使SREs能够管理成千上万台机器，Kubernetes作为Borg的升级，算是完成了运维工作的革新，运维几乎彻底的变成了运维K8S集群；
		
		· Kubernetes系统本身作为分布式系统，它能支持横向扩展，即调整应用程序的副本数以提高可用性；
		  · 设计一套大型系统，并保证其运行时健壮、可扩展、可移植，尤其是再系统复杂度增加时，
				系统的体系结构会直接影响其运行方式、对环境的依赖程度及相关组件的耦合程度；
		
		· 微服务是一种软件设计模式，适用于集群上可扩展的部署；
		  · 开发人员使用这种模式可以构建小型、可组合的应用程序，通过定义好的HTTP REST API接口进行通信；
			· Kubernetes也是遵循微服务架构模式的程序，具有弹性、可观察性和管理功能，可以适应云平台的需求；

		· Kubernetes的系统架构设计与Borg的系统框架理念非常相似，如Scheduler调度器、资源对象管理...
		  所以预先了解过Borg有助于Kubernetes的学习；

		· Kubernetes系统架构一样是M/S(master/salve) 架构，采用的是C/S(client/server) ；
		  Master作为服务端，Node作为客户端；
			
		· Master
			· 和Borg一样，Kubernetes拥有多个Master服务端来保证高可用，默认情况下会通过一个Master来完成所有工作；
					(后续提及Master都是逻辑上的Master，单独的Master节点用KubeMaster来代替)
			· Master服务端也被称为主控节点，主要负责：
					1. 集群的"大脑"，负责管理所有Node；
					2. 负责调度Pod在哪些节点上运行；
					3. 负责控制集群运行中的所有状态；
		
		· Node
			· Node被称为工作节点，它在集群中主要负责：
					1. 负责管理所有的容器(Container) ；
					2. 负责监控&上报所有Pod的运行状态；
			
		· Master作为主要负责管理和控制整个Kubernetes集群，对集群做出全局性的决策，相当于整个集群的"大脑"；
			集群中所有需要执行的控制命令都由Master接收并处理，所以Master中自然需要很多组件来实现这些功能：
				1. API Server：
						是集群的HTTP REST API接口，也是集群控制的入口，所有的控制指令的起始点是这里；
				2. Controller manager：
						是集群中所有资源对象的自动化控制中心；	(后面讲资源的概念)
				3. Scheduler：
						是集群中Pod资源对象的调度中心；
			
		· Node作为集群的实际工作节点，Node上的工作由Master分配下发，
			比如 当某个Node宕机，Master能感应到并将该Node上的工作转移到其他的Node上；
			为了实现这种自动化的能力也离不开组件的支持：
				1. kubelet：
						负责直接管理节点上Container的创建、删除、启停等任务，与master节点进行通信；
				2. kube-proxy：
						负责Kubernetes服务的通信和负载均衡；
				3. Container组件：
						负责容器的基础管理服务，接收kubelet的指令；

		· 综上，Kubernetes中的主要组件由kubectl、apiserver、controller-manager、scheduler、kubelet、kube-proxy、container等；
			除此之外，还需要了解client-go库
			不同的组件之间是松耦架构，各组件各司其职，保证整个集群的稳定运行；


三、组件
		· Kubectl：
				kubectl作为Kubernetes官方提供的命令行工具，用户可以通过kubectl以命令行交互的形式对Kubernetes API Server进行操作，之间通信协议使用的是HTTP/JSON；
				kubectl发送HTTP请求，请求由API Server接收、处理并将结构反馈给kubectl；
				kubectl接收到响应并展示结果，至此kubectl和API Server之间一次请求周期结束；

		· client-go：
				kubectl通过命令行的方式和API Server加护，除此之外还支持通过编程语言的方式与API Server进行通信；
				client-go是从Kubernetes的代码中抽离出来的包，并作为官方提供的GO语言的客户端发挥作用；
				Kubernetes其他组件与API Server通信的方式也基于client-go来实现；

		· API Server：
				· 负责将Kubernetes"资源组/资源版本/资源"以RESTful风格的形式对外暴露并提供服务；
					kubernetes集群中所有的组件都通过API Server操作资源对象；
					API Server也是集群中唯一直接与ETCD集群交互的核心组件；
					例如 用户通过API Server的HTTP接口将Pod资源对象存储到Etcd集群中；
				
				· Etcd集群是分布式K-V键值存储集群，其提供了可靠的强一致性服务发现；
					Etcd集群存储Kubernetes系统集群的状态和元数据，其中包括所有Kubernetes资源对象信息、集群节点信息等；
					Kubernetes将所有数据存储至Etcd集群中前缀为/registry目录下；

				· API Server属于核心组件，对于整个集群的正常运行至关重要，它具有以下特征：
						1. 将Kubernetes系统中所有的资源对象都封装成RESTful风格的API接口进行管理；
						2. 可进行集群状态管理和数据管理，是唯一与Etcd交互的组件；
						3. 拥有丰富的集群安全访问机制，以及认证、授权、准入控制器；
						4. 提供了集群各组件的通信和交互功能；
					可以说API Server是Master的Master
		
		· Controller Manager：
				· Controller Manager 管理控制器，负责管理Kubernetes集群中Node、Namespace(命名空间)、服务账户(ServiceAccount)、资源定额(ResourceQuota)等；
					例如 当某个节点以外宕机时，Controller Manager会即使发现并执行自动化修复流程，以确保集群尽量始终处于预期的工作状态；

				· Controller Manager负责确保Kubernetes系统的实际状态收敛到所需状态，其默认提供了一系列控制器(Controller)；
					例如 DeploymentControllers控制器、StatefulSet控制器、Namespace控制器以及PersistentVolume控制器等，
					控制器通过API Server组件提供的接口实时监控整个集群的对应类型的每个资源对象的当前状态，当因为故障导致系统状态出现变化，会尝试将系统状态修复到期望状态；

				· Controller Manager作为核心组件，也具有高可用性(即 多实例同时运行)，即基于Etcd集群上的分布式锁实现leader选举机制，
					多实例同时运行，通过API Server提供的资源锁进行选举竞争，抢先获取锁的节点作为Leader节点，并运行Controller Manager组件的主逻辑；
					其他Candidate(候选节点)，运行时处于阻塞状态，在Leader节点因为某些原因退出后，Candidtae会重新选举出新的Leader接替Controller Manager的工作；
			
		· Scheduler：	
				· Scheduler是Kubernetes集群的默认调度器，它负责在集群中为Pod资源对象寻找一个合适的节点并在该节点上运行；
					Scheduler每次只调度一个Pod资源对象，为每个Pod寻找合适的节点称为调度周期；
				
				· cheduler监控整个集群的Pod和Node，当监控到新的Pod时，会通过调度算法为其选择最优的节点；
					调度算法分为两种，分别为预选调度算法和优选调度算法；除了调度算法以外，Scheduler还支持优先级调度、抢占调度、亲和性调度等功能；

				· Scheduler支持高可用性，同样是基于Etcd上的分布式锁实现Leader的选举；
					并且在故障时重新从Candidate中选举出新的Leader；

		· Kubelet：
				· Kubelet用于管理节点，运行在每个Kubernetes节点上；
					Kubelet用于接收、处理API Server下发的任务，上报本节点中资源对象的状态；
					Kubelet进程启动时会向API Server注册节点自身的信息，它主要负责所在Node上的Pod资源对象的管理，
					例如Pod资源对象的创建、修改、监控、删除、驱逐及Pod生命周期的管理...
				
				· kubelet会定期监控所在节点的资源使用状态并上报给API Server，这些资源数据可以帮助Scheduler为Pod选择节点；
				  kubelet也会对当前节点的image(镜像)和容器做清理工作，保证节点上的image不会占满磁盘空间，以及删除容器释放资源；
				
				· kubelet实现了三个接口：
						1. Container Runtime Interface	(CRI)：
							容器运行时的接口，提供容器运行时通用插件接口服务；CRI定义了容器和镜像服务的接口；
							CRI将kubelet与容器运行时进行解耦，将原来完全面向Pod级别的内部接口拆分为了面向Sandbox和Container的gRPC接口；
							并将镜像管理和容器管理分离给不同的service；
						2. Container Network Interface	(CNI)：
							容器网络接口，提供网络通用插件接口服务；CNI定义了Kubernetes网络插件的基础，容器创建时通过CNI插件配置网络；
						3. Container Storage Interface	(CSI)：					
							容器存储接口，提供存储通用插件接口服务；CSI定义了容器存储卷的标准规范，容器在创建时通过CSI插件配置存储卷；
				
		· Kube-Proxy：
				· kube-proxy作为节点的网络代理，运行在kubenetes的每个节点上；
					它通过监控API Server的服务和端点资源的变化，并通过iptables/ipvs等配置负载均衡器，为一组Pod提供统一的TCP/UDP流量转发和负载均衡功能；
				
				· kube-proxy时参与管理Pod-to-Service 和External-to-service 网络的最重要的节点组件之一；
				  kube-proxy相当于代理模型，对于某个IP:Port的请求，负责将其转发到专有网络上的相应服务或应用程序；
					但是，kube-proxy与其他负载均衡服务的区别在于，kube-proxy代理指向Kubernetes服务及其后端Pod发出的请求；


四、Kubernetes源码文件结构	(Project Layout)
		· 下面内容是基于Kubernetes1.14.0版本，First commit中因为年代较早没有按照Standard Go Project Layout规范；

		· Kubernetes Project Layout：
				cmd：		存放可执行文件的入口代码，每个可执行文件都对应一个main函数；
				pkg：		存放核心库代码，可被项目内部或外部直接引用；
				vendor：存放项目依赖的库代码，一般为第三方库；
				api：		存放OpenAPI/Swagger的spec文件，包括JSON/Protocal的定义；
				build：	存放与构建相关的脚本；
				test：	存放测试工具及测试数据；
				docs：	存放设计或用户使用文档；
				hack：	存放与构建、测试等相关的脚本；
				third_party：	存放第三方工具、代码或其他组件；
				plugin：存放kubernetes插件代码目录，例如认证、授权等相关插件；
				staging：			存放部分核心库的暂存目录
				transactions：存放il8n(国际化) 语言包等相关文件，可以在不修改内部代码的情况下支持不同语言和地区；
		 	根据实际的体验来说，关注于cmd、pkg、staging就足够了