本节内容提纲：
- Namespace
- Pod
- Controller
- Deployment
- Job
- Service
- ConfigMap
图1：Kubernetes之log
一、Namespace
Namespace是对一组资源和对象的抽象集合，是将集群资源划分为多个用途(通过 resource quota)的方法。例如：将系统内部的对象划分为不同的项目组或用户组。常见的pods, services, replication controllers和deployments等都是属于某一个namespace的（默认是default）。不同 Namespace 里的资源是完全隔离的。Kubernetes 默认创建了两个 Namespace，分别是default和kube-system。
图2：namespace
二、Pod
Pod是Kubernetes 的最小工作单元。每个Pod包含一个或多个容器。Pod 中的容器会作为一个整体被Master调度到一个Node上运行。所有的容器都是在pod中被管理，一个或多个容器放在pod里作为一个管理单元。由一个叫“Pause”的根容器，加上一个或多个用户自定义的容器组成。
图3:Pod结构
三、Controller
负责集群内的Node、Pod副本、服务端点（Endpoint）、命名空间（Namespace）、服务账号（ServiceAccount）、资源定额（ResourceQuota）的管理，当某个Node意外宕机时，Controller Manager会及时发现并执行自动化修复流程，确保集群始终处于预期的工作状态。Kubernetes 提供了多种以下 Controller：Replication Controller（副本控制器）、Node Controller、ResourceQuota Controller、Namespace Controller、Endpoint Controller和Service Controller等。
四、Deployment
Kubernetes提供了一种更加简单的更新RC和Pod的机制，叫做Deployment。通过在Deployment中描述你所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成你所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。
五、Job
用于调配pod对象运行一次性任务，容器中的进程在正常运行结束后不会对其进行重启，而是将pod对象置于completed状态。若容器中的进程因错误而终止，则需要依据配置确定重启与否，未运行完成的pod对象因其所在的节点故障而意外终止后会被重新调度。从程序的运行形态上来区分，我们可以将Pod分为两类：长时运行服务（jboss、mysql等）和一次性任务（数据计算、测试）。RC创建的Pod都是长时运行的服务，而Job创建的Pod都是一次性任务。
六、Service
Kubernetes中的核心要素Service提供了一套简化的服务代理和发现机制，天然适应微服务架构。Kubernetes分配给Service的固定IP是一个虚拟IP，并不是一个真实的IP，在外部是无法寻址的。真实的系统实现上，Kubernetes是通过Kube-proxy组件来实现的虚拟IP路由及转发。所以在之前集群部署的环节上，我们在每个Node上均部署了Proxy这个组件，从而实现了Kubernetes层级的虚拟转发网络。从而实现Service代理外部服务、Service内部负载均衡以及发布Service等功能。
七、ConfigMap
很多生产环境中的应用程序配置较为复杂，可能需要多个config文件、命令行参数和环境变量的组合。并且，这些配置信息应该从应用程序镜像中解耦出来，以保证镜像的可移植性以及配置信息不被泄露。社区引入ConfigMap这个API资源来满足这一需求。ConfigMap包含了一系列的键值对，用于存储被Pod或者系统组件（如controller）访问的信息。这与secret的设计理念有异曲同工之妙，它们的主要区别在于ConfigMap通常不用于存储敏感信息，而只存储简单的文本信息。
閱讀更多 DoDo在線 的文章
