# 《K8s源码解析》第一章阅读笔记
> K8s系统特点
- 可移植:支持公有云、私有云、混合云、多重云。
- 可扩展:模块化、插件化、可挂载、可组合。
- 自动化:自动部署、自动重启、自动复制、自动伸缩/扩展。
## 1.1 K8s发展历史
- 2003-2004年:Google发布Brog系统
- 2013年左右:Google继Brog系统发布Omega集群管理系统
- 2014年左右:Google发布了K8s(作为Brog的开源版本发布)
- 2015年左右:Google正式发布K8s1.0,并与Linux基金会合作组建了CNCF
- 2016年左右:K8s成为主流
- 2017年左右:Google和IBM发布微服务框架Istio,Amazon宣布为K8s提供弹性容器服务,年底K8s1.9发布
- 2018年左右:K8s1.10发布
## 1.2 K8s架构图
K8s系统用于给管理**分布式节点集群**中的**微服务或容器化**应用程序,并且其提供了**零停机**时间部署、**自动回滚**、**缩放**和容器的**自愈**(其中包括自动配置、自动重启、自动复制的高弹性基础设施,以及容器的自动缩放等)等功能。
- K8s系统最重要的设计之一:**横向扩展**,即调整应用程序的副本数提高可用性
K8s遵循微服务架构模式的程序,具有弹性、可观察性和管理功能,适应云平台需求。
--------
K8s系统架构遵循**C/S架构**,分为两部分:
- Master(服务端)
- Node(客户端)
> 可具有多个Master实现高可用,默认情况下一个master可完成所有工作
**Master服务端**
同时被称为主控节点,在集群中主要负责如下任务:
1. 集群的“大脑”,**负责管理所有节点**(Node)。
2. 负责**调度Pod**在哪些节点上运行。
3. 负责**控制集群**运行过程中的**所有状态**。
集群所执行的所有控制命令都是Master接收并处理。
**Node客户端**
同时被称为工作节点,在集群中主要负责如下任务:
1. 负责**管理所有Container**。
2. 负责**监控/上报所有Pod**的运行状态。
**Master组件**包含如下:
- `kube-apiserver`:集群的HTTP REST API接口,是集群控制的入口。
- `kube-controller-manager`:集群中所有资源对象的自动化控制中心。
- `kube-scheduler`:集群中Pod资源对象的调度服务。
**Node组件**包含如下:
- `kubelet`:负责管理节点上容器的创建、删除、启停等任务,与Master进行通信。
- `kube-proxy`:负责K8s服务的通信及负载均衡服务。
- `container`:负责容器的基础管理服务,接收`Kubelet`组件的指令。
## 1.3 K8s各组件功能
### kubectl
- 官方提供的**CLI**
与**K8s API Server**(kube-apiserver)进行交互,通信协议使用**HTTP/JSON**。
### client-go
- **编程**的方式进行通信交互
K8s系统的其他组件和K8s API Server通信的方式也基于`client-go`**实现**。
> 熟练使用并掌握`client-go`是每个K8s开发者必备的技能。
### kube-apiserver
也被称为 **Kubernetes API Server**。
负责那个K8s“**资源组/资源版本/资源**”以RESTful风格的形式**对外暴露并提供服务**。K8s集群中的所有组件都通过此组件操作资源对象。也是唯一与**Etcd集群**进行交互的核心组件。
> Etcd集群时分布式键值存储集群,也提供了可靠的强一致性服务发现。存储了K8s系统集群的状态和元数据。
kube-apiserver具有以下重要特性:
- 将系统中的所有资源对象都封装成RESTful风格的API接口进行管理。
- 可进行集群状态管理和数据管理,是唯一与Etcd集群交互的组件。
- 拥有丰富的集群安全访问机制,以及认证、授权及准入控制器。
- 提供了集群各组件的通信和交互功能。
### kube-controller-manager
也被称为**Controller Manager(管理控制器)**,负责管理集群中的Node、Pod副本、Service、Endpoint、Namespace、ServiceAccount、ResourceQuota等。
- 负责确保系统的**实际状态收敛到所需状态**,其默认是提供了一些**控制器**。
- 具备**高可用性**,即基于Etcd集群上的**分布式锁**实现**领导者选举机制**,多实例同时运行,通过kube-apiserver提供的**资源锁**进行选举竞争。
> 即Raft协议中的领导者选举机制,需要了解Leader、Candidate两个节点角色。
### kube-scheduler
也被称为**调度器**,目前是K8s集群的默认调度器。负责在集群中为**一个Pod资源对象**找到合适的节点并在该节点上运行
> 每次只调度一个Pod资源对象,其寻找节点的过程是一个调度周期。
- **监控**整个集群的**Pod资源对象和Node资源对象**,当监控到新的Pod资源对象时,通过**调度算法**为其选择最优节点。
> 调度算法分为两种,预选调度算法和优选调度算法。除调度策略外,K8s支持优先级调度、抢占机制及亲和性调度等功能。
- 支持**高可用性**,即上面我们所提到的领导者选举机制。
### kubelet
用于**管理节点**,运行在每个节点上。用来**接收、处理、上报Kube-apiserver**组件下发的任务。
- 负责所有Node上的**Pod资源对象的管理**。
- 定期监控所在Node的资源使用状态并上报给kube-apiserver组件,可帮助kube-scheduler调度器为Pod资源对象预选节点。
- 对所在节点的镜像和容器做清理工作。
其实现了三种开放接口:
- **Container Runtime Interface**:简称CRI,提供容器运行时通用插件接口服务。CRI定义了容器和镜像服务的接口。
- **Container Nerwork Interface**:简称CNI,提供网络通用插件接口服务。CNI定义了K8s网络插件的基础。
- **Container Storage Interface**:简称CSI,提供存储通用插件接口服务。CRI定义了容器存储卷标准规范。
### kube-proxy
作为节点上的**网络代理**,监控kube-apiserver的服务和端点资源变化,并通过iptables/ipvs等配置负载均衡器,为以一组Pod提供统一的TCP/UDP**流量转发和负载均衡**功能。
- Kube-proxy是参与管理Pod-to-Service和External-to-Service网络的最重要的节点组件之一。
> 其代理只向K8s服务及其后端Pod发出请求。
## 1.4 Kubernetes Project Layout设计
Kubernetes项目由Go语言编写。
而Go语言的**Standard Go Project Layout**也就成为该项目的参考目录结构。
> 详细信息可查看[Standard Go Project Layout](https://github.com/golang-standards/project-layout/blob/master/README_zh.md)
K8s系统组件较多,各组件的代码入口main**结构设计风格高度一致**,我们以核心组件为例,命令示例如下:
![](http://img.zhengyua.cn/img/20200902222120.png)
每个组件的**初始化过程也非常类似**,初始化过程示意图如图所示。
![](http://img.zhengyua.cn/img/20200902222134.png)
main结构定义了**进程运行的周期**,包括进程启动、运行到退出的过程。以`kube-apiserver`组件为例,其初始化过程如图所示。
![](http://img.zhengyua.cn/img/20200902222318.png)
有疑问加站长微信联系(非本文作者)