【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内部，流程如下： 

1. 通过 kubectl 命令行，创建一个包含Nginx 的Deployment对象。kubectl会调用 API Server 往 etcd里面写入一个Deployment 对象。
2. Deployment Controller监听到有新的 Deployment 对象被写入，就获取到对象信息，根据对象信息来做任务调度，创建对应的 Replica Set 对象。
3. Replica Set Controller 监听到有新的对象被创建，也读取到对象信息来做任务调度，创建对应的 Pod 。
4. Scheduler监听到有新的Pod被创建，读取到 Pod 对象信息，根据集群状态将 Pod 调度到某一个节点上，然后更新 Pod（内部操作是将 Pod 和节点绑定）。
5. Kubelet 监听到当前的节点被指定了新的 Pod，就根据对象信息运行 Pod。