业内人士说：“ Docker和Kubernetes之间的关系生动的体现在各自的logo设计中，Docker是载有集装箱的鲸鱼，而Kubernetes则是一只远洋巨轮的罗盘，数量众多的集装箱装载着组应用，罗盘管理指挥着这些成千上万的集装箱运送到正确目标服务中，二者可谓相辅相成，缺一不可。”

　　在前面两篇文章中， Docker和Kubernetes两个明星产品已经轮番上阵展现自身“才艺”，因此大家对它们有了一定的了解。深圳超算中心建设的“深圳市城市公共服务云”的PaaS平台能力正是基于这两个技术来打造，其中Docker是容器技术，Kubernetes是容器编排技术。如开头所说，Docker和Kubernetes相辅相成，在深圳超算中，二者缺一不可。

　　本文中，我们将介绍Kubernetes的七个组件，这些组件在前文《从深圳城市公共服务云建设谈Kubernetes（一）》的Docker Swarm和Kubernetes的对比中有现身。

　　本文介绍的组件或对象还包括PersistenVolume、PersistenVolumeClaim、Label、Node、NameSpace。掌握了这几个对象，用户就可以部署绝大多数应用。其他的组件或对象我们将在今后再介绍。Kubernetes把这些组件称为资源（Resources）。

　　1、Namespace：命名空间。

　　Kubernetes用Namespace隔离资源、对象。不同Namespace里的资源对象不能协作。Kubernetes集群在建立起来时，有两个Namespace——kube-system和default，前者是Kubernetes集群管理服务（比如Kubernetes-dashboard、Kube-dns）所在的Namespace；后者是默认的Namespace，如果在创建资源时未指定资源的Namespace，则将资源放在default里。Namespace可以用来做用户隔离。

　　2、Node：一个Node对象对应到Kubernetes集群的一个工作节点（Worker Node）。

　　在集群Master上可以通过Node对象来查看相应工作节点的状态、删除节点、添加节点。在Master上用命令kubectl get nodes [(-n=|--namespace=)]可以查看指定命名空间所有节点；如果未指定命名空间，则查找default命名空间里的Node资源。kubectl describe node[(-n=|--namespace=)]可以查看节点的详细描述。

　　3、Pod：Pod是一个逻辑对象，对应着容器。

　　但是Pod又不是容器，一个Pod里可以包含一到多个容器。同一个Pod只能部署在一个工作上，但是Kubernetes集群上部署的应用一般都有高可用性的要求，所以同一个Pod在其他的工作节点上可能存在副本。Pod的生命周期比较短，是临时性的存在——在集群的资源和任务调度时，可能会由一个节点调度到其他节点，大致的过程是在新的节点上先新创建一个Pod副本，然后删除原先节点上的Pod；在应用灰度升级时，老版本的Pod也会在新版本Pod创建后消亡；根据弹性伸缩策略，在业务增长时会新增Pod，在业务量回落时又会销毁若干Pod。在Master上用命令kubectl get pods [(-n=|--namespace=)]可以查看指定命名空间所有Pod；如果未指定命名空间，则查找default命名空间里的Pod资源。kubectldescribe pod[(-n=|--namespace=)]可以查看pod的详细描述

　　4、Service：Kubernetes通过Service将Pod暴露成服务。

　　每个Service对应于一个ClusterIP，集群内的节点和其他服务、Pod可以通过这个ClusterIP访问该Service。Service有一个负载均衡机制，Service暴露的每个Pod是这个Service的一个Endpoint，连接到Service的请求最终被负载均衡机制发到其中一个Pod。Service有三种网络方式暴露服务——ClusterIP、NodePort、LoadBalance。其中ClusterIP方式暴露的服务只有一个集群内IP和服务端口，只有集群内的节点和Pod才能访问这个服务，访问方式为通过服务的集群内IP和服务端口来访问；NodePort方式除了给服务一个集群内IP和端口外，还提供一个Pod所在节点的端口，以供集群外的机器通过Pod所在的IP地址和这个节点的端口来请求服务，集群内的节点和Pod依然可以通过服务在集群内的IP和服务端口来访问服务；LoadBalance目前只支持谷歌云设施和AWS云设施，LoadBalance方式可使得集群外和集群内的节点都可以通过服务IP和端口来访问服务。在Master上用命令kubectl get services[|svc] [(-n=|--namespace=)]可以查看指定命名空间所有Service；如果未指定命名空间，则查找default命名空间里的Service资源。kubectl describe Service[(-n=|--namespace=)]可以查看Service的详细描述。

　　5、Label

　　Kubernetes可以用Label对象给集群内的资源打上标签，这样在部署应用和发布服务时，可以使用标签来完成资源过滤、亲和性部署、反亲和性部署等。比如，可以将某个Pod部署在标签为某个值的节点上。

　　6、PersistentVolume：持久化卷。

　　前文提到，Pod是临时性的存在，其随时可能消亡也随时可以创建；甚至可能出于某种原因停掉某个服务，一段时间后再重启这个服务。对于有状态的服务、数据库服务等，如果Pod中的数据随Pod消亡，则后果是灾难性的。所以对于这些服务，需要将Pod中的数据持久化到节点的存储或者其他存储上。PersistenVolume则是定义了这个持久化数据卷，在创建Pod时，可以将这个卷挂到Pod的某个目录下，将该目录下的数据持久化，这样Pod的数据不会随Pod消亡而消亡，并且下次Pod重新拉起时也可以使用到这些数据。持久化卷可以使用Pod所在节点的存储、集群内共享存储、nfs等。值得注意的是，持久化卷使用Pod所在节点的存储极有可能带来数据不一致的问题，因为Pod并不总是创建在同一个节点上，这个方案只能结合Label使用。在Master上用命令kubectl get PersistentVolumes[|pv][(-n=|--namespace=)]可以查看指定命名空间所有Service；如果未指定命名空间，则查找default命名空间里的PersistentVolumes资源。kubectl describe PersistentVolumes< pv name> [(-n=|--namespace=)]可以查看PersistentVolumes的详细描述。

　　7 、PersistentVolumeClaim

　　PersistentVolume在创建后，只有绑定了PersistentVolumeClaim后才能被Pod挂卷。在Master上用命令kubectlget PersistentVolumeClaims[|pv]c [(-n=|--namespace=)]可以查看指定命名空间所有PersistentVolumeClaims；如果未指定命名空间，则查找default命名空间里的Service资源。kubectl describe PersistentVolumeClaims[(-n=|--namespace=)]可以查看PersistentVolumeClaims的详细描述。

　　Kubernetes支持使用Yaml文件定义所有的资源，然后从yaml文件创建、修改、删除资源。我们将在后面两篇文章中分别介绍剩下的资源和如何使用yaml定义、创建、修改、删除资源，请继续关注中心后期更新！