介绍
K8s诞生融入来自Google多年的大规模容器化运维经验，作为开源捐献给了社区。
云操作系统
K8s已经成为部署和云原生生应用事实上的标准平台
架构简介
控制面
k8s集群由主节点master和工作节点worker node组成
主节点master node是组成控制平面的集合。实际环境主节点必须高可用，至少 3-5 个节点
API Server
API Server是k8s的中央车站，所有组件通信都通过API Server来完成。
API Server通过HTTPS对外提供RESTFul风格的API接口，使用者的YAML配置文件也是通过这个接口实现的，描述了用户希望应用运行时达到的期望状态（desired state）。
Controller Magager
Controller管理器实现了全部后台控制循环，完成对集群监控并对事件做出响应。
Controller管理器是Controller的管理者，负责创建，并监控他们执行
一些循环包括：
- 工作节点controller
- 终端controller
- 副本controller
每个Controller都在后台独立启动循环监听功能，负责监听API Server的变更
目的是保证集群当前状态与期望状态相匹配
Schedule
整体来看，调度器通过监听API Server来启动新的工作任务，并将其分配到合适且处于正常运行状态的节点中。
为了实现，这样的工作，调度器需要过滤掉不能工作的节点，并排序，选择分数高的节点来运行指定的任务。
ETCD（集群存储）
整个控制面中，只有集群存储是有状态的部分，他持久化的存储了集群的的配置与状态。
通常集群存储会选中比较常用的分布式数据库ECTD，用户需要 3-5 个ETCD副本保证存储的高可用。
etcd认为一致性比可用性更加重要，意味着etcd出现脑裂，会停止为集群提供更新能力，集群依然可用，只是不能更新
工作节点
工作节点是k8s集群中的工作者。负责：
- 监听API Server分派新任务
- 执行分派的新任务
- 向控制面回复执行的结果（通过API Server）
Kubelet
Kubelet是每个工作节点的核心部分，使用重要的代理端，并且每个工作节点上都有部署。
实际上，通常来说，工作节点和Kubelet这两个术语基本上是等价的
新的工作节点加入集群，kubelet就会部署到新节点上，kubelet负责将当前工作接待你注册到集群，集群获得节点的CPU、内存信息
容器运行时（docker、containerd..）
kubelet需要通过一个容器运行时，才能够执行任务。比如拉取镜像、启动容器等
k8s早期使用docker作为容器运行时，近期版本，k8s迁移到容器运行时接口（CRI）的模块中，支持丰富的容器运行时。
cri-containerd，是一个开源项目，通过CRI接口接入到K8s，目前已经取代docker的位置。
kube-proxy
kube-proxy运行在集群每一个工作节点上，负责本地集群网络。例如保证每个工作节点获取唯一的ip。实现了本地Iptable，以及IPVS来保证POD间网络路由与负载均衡。
详解POD
VM中，调度基本单位是虚拟机VM；docker中调度基本单位是容器；k8s世界中，调度基本单位是Pod。
k8s支持容器化应用，但是用户无法直接在k8s集群中运行一个容器，容器必须在Pod中才能运行。
Pod与容器
一个Pod可以有一个容器，这是最佳实践
高级用法：一个Pod运行一组容器（Muti-container Pod），适用于强绑定的容器
Pod是用于运行容器的一个有限制的环境，他本身不会运行任何东西，提供承载容器的沙箱而存在。
神秘的Pause容器
Pause容器全称为infrasturcture container（infra）基础容器，负责init pod，其他pod都会从pause容器中fork出来。
- 每个pod都有一个Pause容器，其他为业务容器，业务容器共享Pause容器的网络栈和Volume挂载卷
- 同一个pod容器，通过localhost就能通信
调度单元
k8s最小的调度单元是pod，如果有扩缩容需求，通过增加或者删除Pod实现。
千万不要在一个pod中增加更多容器来完成扩缩容，多容器的pod仅使用共享资源、紧密相连的容器使用
pod部署是原子化操作，意味着pod中所有容器都启动成功，才认为pod启动成功，才能提供对外相应。
一个pod只会被唯一的工作节点调度。
Pod的生命周期
Pod会被创建、运行、销毁
如果Pod出现预期之外的销毁，k8s会自动创建Pod，但是ID和IP都会发生变化，所以程序设计的时候，千万不要依赖Pod，认为Pod是极其不稳定的。
Deployment（部署）
大多数时间，通过更上层的控制器来完成Pod的部署。
上层控制器包括Deployment、DaemonSet以及StatefulSet。
Deployment除了控制Pod外，还提供扩缩容管理、不停机更新以及版本控制等
Deployment、DaemonSet以及StatefulSet还实现了自己的Controller与监控循环，可持续监控集群状态，保证当前状态与预期相符。
Service
Pod非常重要，但是可能随机故障并销毁。如果通过Deployment或者DaemonSET对Pod进行关管理，出现故障的Pod被替换后，id和IP会不同，对于不稳定的Pod，如果用户的其他部门需要依赖Pod，则非常不稳定，基于以上，提出Service机制。
Service为一组Pod提供了稳定的网络，和对外的入口
如果Pod数量增加，在Service也会生效，新的Pod会无缝添加到Service中，对外提供服务。
