原文地址：https://github.com/kubernetes/kubernetes/blob/release-1.3/docs/design/architecture.md

Kubernetes architecture

一个运行的 kubernetes 集群，包涵 agents 节点（kubelet）和主节点组件（APIs，调度器等等），这些构建于分布式存储之上。下图展示了一个我们期望的架构，尽管我们还在完善，比如让kebelet（所有的组件）运行在容器当中，并使所有的调度程序100％可插拔。

The Kubernetes Node

当我们审视整个系统架构时，我们将其分解为两部分，在工作节点上运行的服务和群级控制层面的服务。

Kubernetes node 节点具有运行应用程序容器所需的服务，并可从 master 系统进行管理。

当然，每个节点都要运行Docker。Docker负责下载镜像，管理容器运行的细节。

kubelet 管理 pods 和他们的容器，镜像，磁盘卷等资源。

每个节点还运行一个简单的网络代理和负载均衡器（有关详细信息，请参阅服务常见问题解答）。这反映了services（在每个节点上的Kubernetes API中定义的服务文档以获取更多详细信息），并且可以跨一组后端执行简单的TCP和UDP流转发（循环）。

Service endpoints 目前通过DNS或环境变量找到。这些变量解析为 service proxy 管理的端口。

Kubernetes控制层分为几部分组件。目前它们都在一个主节点上运行（single master node），但预计很快就会改变，以支持集群的高可用。这些组件协同工作以提供群集的统一视图。

集群中 master 节点的所有持久状态都存储在etcd中。它提供了一种可靠的方法，存储配置的数据。通过对watch的支持，可以非常快速地将变更通知到各个组件。

apiserver提供Kubernetes API。它旨在成为一个 CRUD-y 服务器，大多数/所有业务逻辑在单独的组件或插件中实现。apiserver主要处理 REST 操作，验证它们，并更新etcd（或者其他存储）中的相应对象。

Scheduler 程序通过 /binding API 将未调度的 pod 绑定到节点。调度程序是可拔插的，我们希望将来支持多个集群调度程序甚至用户提供的调度程序。

所有其他集群级功能当前由 Controller Manager 执行。例如，Endpoints 对象由 endpoints controller 创建和更新，节点由 node controller 发现，管理和监视。这些最终可以分成单独的组件，使它们可以独立插入。

replication controller是一种机制，它在simple pod API 之上的层级。一旦实现，我们最终计划将其移植成为通用插件机制。