Kubernetes集群包含有节点代理kubelet和Master组件(APIs, scheduler, etc)，一切都基于分布式的存储系统。下面这张图是Kubernetes的架构图。
Kubernetes 节点
在这张系统架构图中，我们把服务分为运行在工作节点上的服务和组成集群级别控制板的服务。
Kubernetes节点有运行应用容器必备的服务，而这些都是受Master的控制。
每次个节点上当然都要运行Docker。Docker来负责所有具体的映像下载和容器运行。
kubelet
kubelet负责管理pods和它们上面的容器，images镜像、volumes、等。
kube-proxy
每一个节点也运行一个简单的网络代理和负载均衡。 正如Kubernetes API里面定义的这些服务也可以在各种终端中以轮询的方式做一些简单的TCP和UDP传输。
服务端点目前是通过DNS或者环境变量( Docker-links-compatible 和 Kubernetes {FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 变量都支持)。这些变量由服务代理所管理的端口来解析。
Kubernetes Master
Kubernetes控制面板可以分为多个部分。目前它们都运行在一个master 节点，然而为了达到高可用性，这需要改变。不同部分一起协作提供一个统一的关于集群的视图。
etcd
所有master的持续状态都存在etcd的一个实例中。这可以很好地存储配置数据。因为有watch的支持，各部件协调中的改变可以很快被察觉。
Kubernetes API Server
API服务提供Kubernetes API 的服务。这个服务试图通过把所有或者大部分的业务逻辑在单独得组件或插件中实现,从而使其具有CRUD特性。它主要处理REST操作，在etcd中验证更新这些对象（并最终存储）。
Scheduler
调度器把未调度的pod通过binding api绑定到节点上。调度器是可插拔的，并且期待支持多集群的调度，未来甚至希望可以支持用户自定义的调度器。
Kubernetes Controller Manager Server
所有其它的集群级别的功能目前都是由控制管理器所负责。例如，端点对象是被端点控制器来创建和更新。这些最终可以被分隔成不同的部件来让它们独自的可插拔。
replicationcontroller是一种建立于简单的 pod API之上的一种机制。一旦实现，最终计划把这变成一种通用的插件机制。
