【K8s】Kubernetes架构理解
抽空学习了一下Kubernetes，感觉和大数据领域内集群的资源管理、任务调度等有异曲同工之处，简单总结一下备忘。
【概念】
Kubernetes是一个工业级的容器编排平台，单词有点长，常用K8s代称。
其主要功能有：
- 调度：例如，部署Pod时，将Pod部署到较为空闲的机器节点。
- 自动恢复：例如，机器节点健康检查，将故障机器节点上的Pod迁移到正常机器节点上。
- 弹性伸缩：例如，业务负载检查，当CPU/内存使用率过高，或Pod服务响应时间过长等预置前置条件满足时，自动扩容。
PS:
Pod是一组关系非常密切的容器的集合，例如容器间需要进行直接文件交换、共享某些Namespace、之间有非常频繁的RPC调用等。Pod才是K8s的原子调度单位，而不是容器。
【官方架构】
【理解】
官方的这个图是K8s的技术架构，其实在技术架构之前，应该有个更简化的K8s的逻辑架构做基础。理解输出如下：
- etcd：
是一个分布式存储组件，用来存储的集群所有状态，还具备事件订阅和监听、Leader 选举的能力。
事件订阅和监听：其他各个组件通信，都并不是互相调用API来完成的，而是把状态写入etcd，其他组件通过订阅etcd中的状态监听变化，然后做后续的处理，然后再一次把更新的数据写入etcd。
Leader 选举：组件比如Scheduler，为了做实现高可用，通过etcd从多个(通常是3个)实例里面选举出来一个做Master，其他都是Standby。
- API Server：
上述etcd并不是直接被访问，而是通过API Server代理后被访问。API Server相当于API网关，将对etcd接口的调用封装为标准的RESTFul API。
此外，API Server还实现了一些附加功能，例如身份认证、缓存等。
- Controller Manager：
实现任务调度。直接请求Kubernetes做调度的都是任务，例如Deployment、Deamon Set或者Job，每一个任务请求发送给Kubernetes 之后，都是由 Controller Manager 来处理的。
每一种任务类型对应一个 Controller Manager，例如：Deployment对应Deployment Controller,ReplicaSet对应ReplicaSet Controller。
- Scheduler：
实现资源调度。Controller Manager会把任务对资源Pod的要求，写入到etcd。Scheduler监听到有新的资源Pod要求被调度，会根据整个集群的各个节点的资源情况，将Pod分配到较为空闲合适的节点上。
- Kubelet：
是一个Agent，运行在每一个节点上，它会监听etcd中的Pod的信息，发现有分配给它所在节点的Pod需要运行，就在节点上运行相应的Pod，并且把状态更新回到etcd。
- Kubectl：
是一个提供给用户的命令行工具，用户通过它调用API Server，发送请求写入状态到etcd，或者查询etcd中的状态。
【举例】
假如要运行一个多个实例的Nginx，那么在 Kubernetes内部，流程如下：
- 通过 kubectl 命令行，创建一个包含Nginx 的Deployment对象。kubectl会调用 API Server 往 etcd里面写入一个Deployment 对象。
- Deployment Controller监听到有新的 Deployment 对象被写入，就获取到对象信息，根据对象信息来做任务调度，创建对应的 Replica Set 对象。
- Replica Set Controller 监听到有新的对象被创建，也读取到对象信息来做任务调度，创建对应的 Pod 。
- Scheduler监听到有新的Pod被创建，读取到 Pod 对象信息，根据集群状态将 Pod 调度到某一个节点上，然后更新 Pod（内部操作是将 Pod 和节点绑定）。
- Kubelet 监听到当前的节点被指定了新的 Pod，就根据对象信息运行 Pod。
