Kubernetes内部组件工作原理介绍

2018-05-08 10:31:00
Kubernetes
转贴:
dockone
5599
本篇文章讲述了Kubernetes内部组件的工作原理,及创建Pod的流程。如果你是运维人员或者是Kubernetes的使用者,你可以不需要知道Kubernetes的内部工作原理,但是如果你想理解Kubernetes内部的工作原理,这篇文章非常适合你。

读这篇文章的前提是,你已经大致了解并会运用Kubernetes。这篇文章不会去描述什么是Kubernetes及其组件(如:Pod、Node、Kubelet)。

本篇将讨论Kubernetes核心组件及这些核心组件是如何让Kubernetes 对“爵士乐即兴演奏"。通常将像Kubernetes这样的通用系统称为容器的 “管弦乐编排"。但是管弦乐编排,必须有一个预先计划的指挥家。因此,这并不是Kubernetes的一个好的描述。相反,Kubernetes更像是爵士乐即兴演奏,有一系列演员互相配合协调完成演奏。

接下来,开始介绍每个核心组件的功能。然后将看一个典型的调度和启动一个Pod的流程。

Datastore:etcd

etcd是Kubernetes的存储状态的数据库。虽然Kubernetes系统中有重要的内存缓存,但etcd被认为是记录系统状态。

etcd的快速总结:它是一个集群分布式数据库,它可以提供分布式数据的一致性。这类的系统(如ZooKeeper、Consul)是在Google开发的chubby系统之后形成的,这些系统也称为"锁服务器",因为他们可以实现分布式锁。etcd和chubby的数据模型是一个简单的层次化的Key,并存储了简单的非结构化value,这看起来像是一个文件系统。有意思的是,在Google,chubby被频繁用于为实现访问本地文件和对象存储的功能的抽象文件接口。然而,分布式数据库的高度一致性,提供了数据的严格写入顺序并允许client原子性的对数据做更新操作。

可靠的系统的状态管理是任何系统中非常困难的一件事情。在分布式系统中,它是更加困难的,因为它引入了一致性算法,如raft或paxos。通过使用etcd,Kubernetes可以专注系统的其他部分。

etcd的watch机制是Kubernetes工作的关键。系统允许client去执行轻量级的对于Key值变化事件的订阅。当要watch的数据发生变化时,client会立即得到通知。这可以用作分布式系统组件之间的协调机制。 一个组件一旦写入etcd,其他组件可以立即对该变化作出反应。

etcd的消息机制正好和PubSub消息队列机制相反。在许多消息队列系统系统中,topic不存储真正的用户数据,但发布到这些topic的消息含有丰富的数据。对于像Etcd这样的系统,Key(类似于主题)存储了真实的数据而消息(数据变化通知)不含独特的丰富消息。换句话说,对于消息队列来说,topic很简单,而像etcd则正好相反。(译者认为此处概括的非常准确)

Policy Layer:API Server

Kubernetes的核心组件是API Server,它是Kubernetes系统和etcd直接对话的唯一组件。实际上,etcd是API Server的实现细节,理论上也可以用其他分布式存储系统来支持Kubernetes。

API Server是一个策略组件,提供对etcd的过滤访问。它的作用本质上是相对通用的,目前正在被分解处理。因此,API Server也可以用于其他系统的控制平面。

API Server的主要货物是资源,通过暴露简单的REST API向外提供服务。这些资源有一个标准结构可以实现一些扩展功能。无论如何,API Server,允许各类组件创建、读取、写入、更新和监视资源。

API Server的具体的功能:
  1. 认证和授权。Kubernetes有一个可插拔的认证系统。有一些内置的用户认证机制和授权这些用户访问资源。此外,还有一些方法可用于向外部服务提供这些服务。这种可扩展性是Kubernetes构建的核心功能。
  2. API Server运行一组可以拒绝或修改请求的准入控制器。 这些允许策略被应用并设置默认值。 这是确保在API Server客户端仍在等待请求确认时进入系统的数据有效性的关键。 虽然这些准入控制器目前正在编译到API Server中,但目前正在进行的工作是使其成为另一种可扩展性机制。
  3. API Server有助于API版本控制。API版本的一个关键问题是允许资源的字段的改变,字段添加,弃用,重新组织和以其他方式转换。 API Server在etcd中存储资源的“true"表示,并根据满足的API版本转换/呈现该资源。 自项目早期开始,规划版本控制和API的发展一直是Kubernetes的一项重要工作。

API Server一个重要特性是支持watch机制。这意味着API Server的客户端可以使用与etcd相同的协调模式。Kubernetes中的大多数协调包括写入另一个组件正在监视的API服务器资源的组件。 第二个组件将对几乎立即发生的变化做出反应。

业务逻辑:Controller Manager and Scheduler

这些是通过API Server进行协调的组件。这些称为Controller Manager和Scheduler的组件绑定到单独的服务器Master上。

Scheduler组件将做许多事情让系统工作:
  1. 查找未分配给节点的Pod(未绑定的Pod);
  2. 检查集群的状态(缓存在内存中);
  3. 选择具有空闲空间并满足其他约束条件的节点;
  4. 将pod绑定到该节点。

Controller Manager组件,实现ReplicaSet的行为。(ReplicaSet可以确保任何时候都可以运行一个Pod模板的副本数量)。控制器将根据资源中的选择器 监控ReplicaSet 资源和一组Pod。为了保持在ReplicaSet中稳定的一组Pod,控制器将创建、销毁Pod。

Node Agent:Kubelet

每一个Node上都有一个Agent。这也像其他组件一样对API Server进行身份验证。Agent负责监视绑定到其节点的一组Pod,并确保这些Pod正常运行,并且能实时返回这些Pod的运行状态。

典型的流程

为帮助理解,创建Pod的整个流程,时序图如下:

这个时序图展示了创建pod的流程,基本的流程如下:
  1. 用户提交创建Pod的请求,可以通过API Server的REST API ,也可用Kubectl命令行工具,支持Json和Yaml两种格式;
  2. API Server处理用户请求,存储Pod数据到etcd;
  3. Schedule通过和API Server的watch机制,查看到新的Pod,尝试为Pod绑定Node;
  4. 过滤主机:调度器用一组规则过滤掉不符合要求的主机,比如Pod指定了所需要的资源,那么就要过滤掉资源不够的主机;
  5. 主机打分:对第一步筛选出的符合要求的主机进行打分,在主机打分阶段,调度器会考虑一些整体优化策略,比如把一个Replication Controller的副本分布到不同的主机上,使用最低负载的主机等;
  6. 选择主机:选择打分最高的主机,进行binding操作,结果存储到etcd中;
  7. Kubelet根据调度结果执行Pod创建操作: 绑定成功后,会启动container,docker run,scheduler会调用API Server的API在etcd中创建一个bound pod对象,描述在一个工作节点上绑定运行的所有pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息,一旦发现应该在该工作节点上运行的bound pod对象没有更新,则调用Docker API创建并启动pod内的容器。

总结

通过使用API Server作为中心协调点,Kubernetes能够以松耦合的方式,实现组件相互交互。 希望读完此文,你可以对Kubernetes创建Pod的原理有更深入的认识。

原文链接: Core Kubernetes: Jazz Improv over Orchestration(翻译:范浩)
发表评论
零 乘 玖 =
评论通过审核后显示。
文章分类
联系方式
联系人: 王春生
Email: chunsheng@cnezsoft.com