摘要：本系列文章着眼于实际部署，带您快速掌握Kubernetes。本文主要介绍部署之前需要了解的原理和概念，包括Kubernetes的组件结构，各个组件角色的功能，以及Kubernetes的应用模型等。
【编者按】Kubernetes可用来管理Linux容器集群，加速开发和简化运维（即DevOps）。但目前网络上关于Kubernetes的文章介绍性远多于实际使用。本系列文章着眼于实际部署，带您快速掌握Kubernetes。本文为上篇，主要介绍部署之前需要了解的原理和概念，包括Kubernetes的组件结构，各个组件角色的功能，以及Kubernetes的应用模型等。
十多年来Google一直在生产环境中使用容器运行业务，负责管理其容器集群的系统就是Kubernetes的前身Borg。其实现在很多工作在Kubernetes项目上的Google开发者先前就在Borg这个项目上工作。多数Kubernetes的应用部署模型的思想都起源于Borg,了解这些模型是掌握Kubernetes的关键。Kubernetes的API版本目前是v1，本文以代码0.18.2版为基础来介绍它的应用部署模型，最后我们用一个简单的用例来说明部署过程。在部署结束后，阐述了它是如何用Iptables规则来实现各种类型Service的。
Kubernetes架构Kubernetes集群包括Kubernetes代理(agents )和Kubernetes服务(master node)两种角色，代理角色的组件包括Kube-proxy 和Kubelet，它们同时部署在一个节点上，这个节点也就是代理节点。服务角色的组件包括kube-apiserver，kube-scheduler，kube-controller-manager，它们可以任意布属，它们可以部署在同一个节点上，也可以部署在不同的节点上（目前版本好像不行）。Kubernetes集群依赖的第三方组件目前有etcd和docker两个。前者提供状态存储，二者用来管理容器。集群还可以使用分布式存储给容器提供存储空间。下图显示了目前系统的组成部分：
Kubelet组件管理Pods和它们的容器，镜像和卷等信息。
Kube-ProxyKube-proxy是一个简单的网络代理和负载均衡器。它具体实现Service模型，每个Service都会在所有的Kube-proxy节点上体现。根据Service的selector所覆盖的Pods, Kube-proxy会对这些Pods做负载均衡来服务于Service的访问者。
Kubernetes服务节点Kubernetes服务组件形成了Kubernetes的控制平面，目前他们运行在单一节点上，但是将来会分开来部署，以支持高可用性。
etcd所有的持久性状态都保存在etcd中。Etcd同时支持watch，这样组件很容易得到系统状态的变化，从而快速响应和协调工作。
Kubernetes API Server这个组件提供对API的支持，响应REST操作，验证API模型和更新etcd中的相应对象。
Scheduler通过访问Kubernetes中/binding API, Scheduler负责Pods在各个节点上的分配。Scheduler是插件式的，Kubernetes将来可以支持用户自定义的scheduler。
Kubernetes Controller Manager ServerController Manager Server负责所有其它的功能，比如endpoints控制器负责Endpoints对象的创建，更新。node控制器负责节点的发现，管理和监控。将来可能会把这些控制器拆分并且提供插件式的实现。
Kubernetes模型Kubernetes的伟大之处就在于它的应用部署模型，主要包括Pod、Replication controller、Label和Service。
PodKubernetes的最小部署单元是Pod而不是容器。作为First class API公民，Pods能被创建，调度和管理。简单地来说，像一个豌豆荚中的豌豆一样，一个Pod中的应用容器同享同一个上下文：
PID 名字空间。但是在docker中不支持
网络名字空间，在同一Pod中的多个容器访问同一个IP和端口空间。
IPC名字空间，同一个Pod中的应用能够使用SystemV IPC和POSIX消息队列进行通信。
UTS名字空间，同一个Pod中的应用共享一个主机名。
Pod中的各个容器应用还可以访问Pod级别定义的共享卷。