整体架构图
1. 背景
服务器经历了三次演变过程：物理机、虚拟机和容器化
物理机的缺点：
- 部署慢 ：每台服务器都要安装操作系统、相关的应用程序所需要的环境，各种配置
- 成本高：物理服务器的价格十分昂贵
- 资源浪费：硬件资源不能充分利用
- 扩展和迁移成本高：扩展和迁移需要重新配置一模一样的环境
虚拟机很好解决了物理机的缺点，代表产品为vmware，其特点为：
- 易部署：每台物理机可部署多台虚拟机，且可以通过模板，部署快，成本低
- 资源池：开出来的虚拟机可作为资源池备用，充分压榨服务器性能
- 资源隔离：每个虚拟机都有独立分配的内存磁盘等硬件资源，虚拟机之间不会互相影响
- 易扩展：随时都能在一个物理机上创建或销毁虚拟机
虚拟机的缺点是：每台虚拟机都需要安装操作系统，每台虚拟机都需要虚拟出完整的操作系统，对内存等资源会造成浪费和压力。
容器化时代解决了虚拟机的缺点，并在继承虚拟机优点的基础之上，代表产品为docker，具有以下特点：
- 更高效的利用硬件资源：所有容器共享主机操作系统内核，不需要安装操作系统。
- 一致的运行环境：相同的镜像产生相同的行为
- 更小：较虚拟机而言，容器镜像更小，因为不需要打包操作系统
- 更快：容器能达到秒级启动，其本质是主机上的一个进程
docker在单机上进行编排很方便，但在一些场景下存在明显缺陷
- 但当节点较多时需要重复执行指令，并进行负载均衡，不利于自动装箱。
- 且当增加节点时认为操作繁杂，不利于水平扩缩。
- 如果要进行版本变更，更新或回滚，需要停止容器然后更新容器镜像，重新启动，当副本较多时，不利于自动化上线和回滚。
- 当出现节点宕机，节点上所有容器都停止，docker的重启策略会失效，不能自我修复。
- 如果进行负载均衡时，需要新增负载均衡器，配置节点ip和端口，容器网络隔离导致不能相互访问，维护成本较高，不利于服务发现与负载均衡。
上述均属于容器编排问题，需要一个新技术进行自动化编排，k8s应运而生。
2. 基本概念
2.1. Pod
Pod本身是豌豆荚，为k8s的最小调度单元，里面会包含一个或多个容器（Container），Pod内的容器共享存储及网络，可通过localhost通信。
2.2. Deployment
pod 上层的一个抽象，它可以定义一组 Pod 的副本数目、以及这个 Pod 的版本。一般用 Deployment 来做应用的真正的管理，而 Pod 是组成 Deployment 最小的单元
- 定义一组Pod的副本数量，版本等
- 通过控制器维护Pod的数目
- 自动恢复失败的Pod
- 通过控制器以指定的策略控制版本
2.3. Service
Pod是不稳定的，IP会发生变化，因此需要一层抽象来屏蔽这种变化，Service可以实现，其主要功能为：
- 提供访问一个或者多个Pod实例稳定的访问地址
- 支持多种访问方式ClusterIP（对集群内部访问）NodePort（对集群外部访问）LoadBalancer（集群外部负载均衡）
2.4. Volume
Volume表示存储卷，Pod访问文件系统的抽象层，具体的后端存储可以是本地存储、NFS网络存储、云存储以及分布式存储等。
- 声明在Pod中容器可以访问的文件系统
- 可以被挂载在Pod中一个或多个容器的指定路径下
- 支持多种后端储存
2.5. NameSpace
用以资源的逻辑隔离，上述小节均属于资源，不同ns下可以同名，相同ns下需唯一。
- 一个集群内部的逻辑隔离机制（鉴权、资源等）
- 每个资源都属于一个Namespace
- 同一个Namespace中资源命名唯一
- 不同Namespace中资源可重名
2.6. Master组件
kube-apiserver：Kubernetes API，集群统一入口，各组件协调者，以RESTful API提供接口服务，所有对象的资源的增删改查和监听操作都交给APIServer处理后在提交给Etcd存储。
1）提供了集群管理的REST API接口(包括认证授权、数据校验以及集群状态变更)；
2）提供其他模块之间的数据交互和通信的枢纽（其他模块通过API Server查询或修改数据，只有API Server才直接操作etcd）;
3）是资源配额控制的入口；
controller-manager：是 Kubernetes 的大脑，它通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。
scheduler：scheduler 负责分配调度 Pod 到集群内的节点上，它监听 kube-apiserver，查询还未分配 Node 的 Pod，然后根据调度策略为这些 Pod 分配节点（更新 Pod 的 NodeName 字段）。
工作原理：
kube-scheduler 调度分为两个阶段，predicate 和 priority
1）predicate：过滤不符合条件的节点
2）priority：优先级排序，选择优先级最高的节点
etcd：Etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。etcd作为一个受到ZooKeeper与doozer启发而催生的项目，除了拥有与之类似的功能外，更专注于以下四点：
1）简单：基于HTTP+JSON的API让你用curl就可以轻松使用。
2）安全：可选SSL客户认证机制。
3）快速：每个实例每秒支持一千次写操作。
4）可信：使用Raft算法充分实现了分布式。
主要功能：
1）基本的 key-value 存储
2）监听机制
3）key 的过期及续约机制，用于监控和服务发现
4）原子性操作（CAS 和 CAD），用于分布式锁和 leader 选举
2.7. Node组件
kubelet：kubelet是Master在Node节点上的Agent，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载Secret、获取容器节点状态工作。kubelet将每个Pod转换成一组容器。
每个节点上都运行一个 kubelet 服务进程，默认监听 10250 端口，接收并执行 master 发来的指令，管理 Pod 及 Pod 中的容器。每个 kubelet 进程会在 API Server 上注册节点自身信息，定期向 master 节点汇报节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。
kube-proxy：在node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作。
每台机器上都运行一个 kube-proxy 服务，它监听 API server 中 service 和 endpoint 的变化情况，并通过 iptables 等来为服务配置负载均衡（仅支持 TCP 和 UDP）。
kube-proxy 可以直接运行在物理机上，也可以以 static pod 或者 daemonset 的方式运行。
docker或rocket：容器引擎，运行容器。
2.8. K8S创建一个Pod的流程
- 用户通过kubectl向api-server发起创建pod请求。
- apiserver通过对应的kubeconfig进行认证，认证通过后将yaml中的po信息存到etcd。
- Controller-Manager通过apiserver的watch接口发现了pod信息的更新，执行该资源所依赖的拓扑结构整合，整合后将对应的信息交给apiserver，apiserver写到etcd，此时pod已经可以被调度。
- Scheduler同样通过apiserver的watch接口更新到pod可以被调度，通过算法给pod分配节点，并将pod和对应节点绑定的信息交给apiserver，apiserver写到etcd，然后将pod交给kubelet。
- kubelet收到pod后，调用CNI接口给pod创建pod网络，调用CRI接口去启动容器，调用CSI进行存储卷的挂载。
- 网络，容器，存储创建完成后pod创建完成，等业务进程启动后，pod运行成功。
流程图如下：
