【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。