pod是k8s中能够被创建、调度和管理的最小部署单元。一个pod是由若干个docker容器构成的容器组。pod包含的容器运行在同一个Minion(Host)上，看作一个统一管理单元，pod内的容器是共享网络和存储的。

        Ø  pod是IP等网络资源分配的基本单位，这个IP以及对应的network namespace是由pod里的容器共享的。

        Ø  pod内的所有容器也共享存储卷（volume），当一个volume挂载到一个docker容器的文件系统上，该目录下的数据可以被同一个pod中的其他容器访问到。

        从linux namespace角度看，pod中的容器还共享PID namespace、IPC namespace、UTS namespace。

2.  Labels

        labels是一组绑定到k8s对象（比如pod）上的键/值对，同一个对象labels属性的key值必须独一无二。labels的数据结构非常简单，key和value均为sring类型的map结构。

        k8s引入labels的目的是面向用户，使之成为用户级的k8s对象的标识属性。k8s对象创建时，labels进行绑定操作，绑定之后labels也可以进行增删和修改。labels属性将对象划分成各个子集。一个对象可以有多个labels，一个labels也可以有多个对象。

3.  Kubectl

        kubectl是k8s的一个客服端工具，可以利用这个工具对k8s对象（pod、replication controller、service）进行增加、删除、修改、查询操作。创建k8s对象的通用方法如下：

kubectl  creat  –f  obj.json

        其中obj。json可以是定义pod、replication controller、service等k8s对象的JSON格式的资源配置文件。简单的配置文件内容如下：

        kind字段表明该资源是一个pod。

        labels字段即该pod的标签。

        desiredState描述的是pod期望的资源状态，所有的资源对象都会告诉系统自己期望的资源状态。k8s负责搜集该资源对象的当前状态并与期望状态进行比较。k8s需要保证不管发生什么情况都要保证资源对象的状态达到其期望的状态。manifest、containers字段描述pod内部的容器属性，包括容器名、镜像、端口映射。k8s自动实现用户容器到宿主机端口的映射关系。

4.  pod内的容器网络与通信

        pod内的容器是共享network namespace的，那么k8s是怎么做到这一点的呢。其实k8s在启动pods时会自动启动一个网络容器，并且pod内的其他容器都借助—net=”container”的方式使用这个网络容器来定义自身的网络，这样就实现了这些容器共享一个network namespace。网络容器不需要做任何工作，因此它占用的资源可以忽略不计。

5.  replication controller

        replication controller是pod复制的抽象，它决定了一个pod有多少个同时运行的副本，并保证这些副本的期望状态和当前状态一致。一般，只要创建一个pod，就会创建一个与之对应的replication controller，让这个controller一直守护pod，直到pod删除。

        与pod对象类似，k8s使用一份JSON格式的资源配置文件来定义一个replication controller对象。这个资源配置文件主要由3个方面组成：一个用于创建pod的pod模板（pod template），一个期望副本数和一个用于选择被控制的pod集合的label selector。资源配置文件示例如下：

        从上面的描述文件中可以看出，replication containers通过使用预定义的pod模板来创建pod，一旦pod创建成功，对模板的任何更改都不会对已经在运行的pod有任何影响。replication controller对pod数量和健康状况的监控时通过副本选择器（repliac selector，label selector的一种）来实现的。

        删除一个replication controller不会影响它所创建的pod，如果想删除一个replication controller所控制的pod，需要将该replication controller的副本数（replicas）字段设置成0，这样所有的pod就会被自动删除。另外，用户需要保证一个pod只属于一个replication controller，这是因为replication controller没有相应的查重机制，如果一个pod对应多个replication controller，那么这些replication controller之间会产生冲突。

6. service

        service是pod的路由代理抽象，用于解决pod之间的服务发现问题。在k8s中，pod的ip地址是不固定的，因此需要一个代理来确保需要使用的pod的应用不要知晓pod的真实ip地址。另外，当使用replication controller创建了多个pod副本时，需要一个代理来为这些pod做负载均衡。所以service这个名字容易引起误解，或许应该定名为proxy或者route更贴切些。