在本系列文章的第一篇中我阐述了从基础设施的容器化角度阐述了什么是容器，什么是Docker以及它们是怎么来重新定义运维工作以及对基础设施产生的影响。但是，仅仅了解了容器与Docker还不足以将它们运用到我们实际的技术栈中去；所以在本篇文章中我会介绍Kubernetes——一个容器的编排（orchestration）工具——我选择用它来为基础设施容器化部署提供支持。
Google是容器的“重度玩家”，在Google内部的成百上千台服务器上夜以继日的运行着数以十亿计的容器；时间一长，便开发出了自己的容器管理工具集用于管理如此巨量的基础设施——Borg；而就在几年前，Borg团队将多年积累的容器运行编排管理经验聚集到了一个新的项目，取名叫做Kubernetes，并将其开源贡献给了大众。
Kubernetes——继承自Borg，是一组能够彼此配合与协作的工具与服务的集合，通过使用这组工具，就能解决我在上一篇博客中所提出的容器服务化所面临的问题。当然，Kubernetes一个非常复杂的系统，它由很多互相配合使用的组件构成；同时，它也是一个适用于生产环境使用，并经过严格与广泛测试过的，并在除google公司以外很多公司检验过的成熟产品。Kubernetes的学习曲线也是很陡峭的，但是庆幸的是它的官方文档是非常全的；任何关于Kubernetes的细节都能在其官方文档中找到答案；同时还为每个知识点配置了很多例子与开发建议，当然还有可能出现的报错说明；更加令人惊讶的是，Kubernetes的官方文档网站还提供了一个基于浏览器的互动式的操作指导，我个人非常推荐大家去试试。
正像我之前说的，你会发现Kubernetes有很多东西需要掌握，是这样的；但是你并不需要理解所有关于Kubernetes的技术细节才能够正确使用它。在这篇文章中，我会把我了解到的关于Kubernetes的一些基础知识、概念以及我现在使用的那些工具做个介绍。
资源（Resources）
从整体来看，Kubernetes集群是由很多由JSON或者YAML定义的‘资源’组成，我个人比较推崇使用YAML写配置，因为它读写都很容易，同时还支持注释。
我不会阐述Kubernetes中所有的‘资源’类型，因为太多而且还在增加；我会介绍在Kubernetes中启动一个应用所需要了解的几个基本‘资源’类型，如：Pod、Deployment、Service与Namespace；我还会围绕这几种资源类型介绍其他一些概念与如何使用它们。
Node
首先是Node，它代表Kubernetes集群运行的宿主物理机或者虚拟机服务器，它为容器提供必要的计算资源如：CPU与内存。
Pod
Kubernetes中最底层的抽象则是Pod。一个Pod中可以包含一个或者多个运行的容器，这些容器运行在同一个Node上，并且共享此Node的资源。在同一个Pod中的容器可以互相通过localhost的方式通信，这样就可以以集群与可扩展方式运行一个应用提供了支持。
Pod就是Kubernetes中的‘不可变层（immutable layer ）’；Pod不会升级，只会关闭、丢弃与被代替。它们可以被手动启停，但是不建议这样。在Kubernetes集群中对Pod的配置与管理都是通过‘Deployment’来完成。
Deployment
Deployment是Kubernetes集群的管理引擎，它负责管理集群中频繁的Pod启停工作，如：它负责配置一个集群中一共需要跑多少个Pod，Pod运行的内容，以及根据部署方案或者Node、集群发生的问题来决定如何来启停Pod。（技术上来说，Deployment把上面说的一些工作交给了Replica Set来做了，但是现在没必要了解这么多）
这是一个Deployment，它配置了3个nginx Pods：
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: role: web spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80
Service
一个集群可以有多个Deployment，每个Deployment管理多个Pods与容器，这很好；但是，如何将容器中运行的服务暴露给外部网络呢？这就需要Service来解决了。Service提供了一个从Deployment与Pod到外部网络以及外部网络到内部容器的一个双工的通道。其中，NodePort Service类型的Service提供了容器的内部访问机制，但是也能够将部分高段的端口（30000-35000）映射给集群外部以访问集群内部的容器。如果你使用Amazon（AWS）或者google的容器引擎（GKE），你就可以使用LoadBalancer类型的Service，它可以通过配置一些规则在你的云环境中实现一个负载均衡器。
这可能有些难理解，我下面举一个例子来说明。比如，我们在一个rails应用的前端加一个nginx的负载均衡，同时使用redis作为此应用的数据后端，只需要内部访问。假如，我们使用GKE或者AWS来部署，我们的负载均衡指向nginx，nginx将请求路由到rails应用程序，同时通过redis读写数据。下面是Service的配置文件，注意其中的selector节点中label（后面的label节会提及）值role:web让Kubernetes知道此LoadBalancer类型的Service的具体Deployment在哪。（上节讲Deployment时例子中的3个nginx）。
## # nginx # Listen to the world on port 80 and 443 ## apiVersion: v1 kind: Service metadata: name: nginx labels: role: web spec: type: LoadBalancer ports: - name: http port: 80 targetPort: 80 - name: https port: 443 targetPort: 443 selector: # Find all Resources that are tagged with the "role: web" label # In our case, it will find the nginx Deployment mentioned above role: web --- ## # Rails # Listen for traffic on 8080 so we don't have to run as root. ## apiVersion: v1 kind: Service metadata: name: rails labels: role: rails spec: type: NodePort ports: - port: 8080 targetPort: 8080 selector: role: rails --- ## # Redis ## apiVersion: v1 kind: Service metadata: name: redis labels: role: redis spec: type: NodePort ports: - port: 6379 targetPort: 6379 selector: role: redis
Namespace
在Service上面我们还可以定义它的Namespace属性，它实际上只是个标识符，用于封装、划分你的基础设施。Kubernetes内部就是用命名空间的方式来区分自己内部的服务（kubedns, kube-proxy等等）与用户自己定义的服务，Kubernetes的命名空间是：kube-system 。如果你不定义命名空间，Kubernetes会将你的‘资源’放置到一个默认的命名空间中，在大多数情况下，这就足够了；但是，当你在多个团队何总的情况下，使用命名空间可以防止资源的冲突与混淆。
下面是一个命名空间的例子：
apiVersion: v1 kind: Namespace metadata: name: my-app
Labels
Kubernetes中大量使用Label在整个集群中来标记与查找资源。你可以通过上面提供的例子中找到线索，Deployment中有labels节点，它的值跟下面Service中selectors中的值是对应的。Kubernetes用Label将各种‘资源’中定义的配置关联在了一起，引用的层级是：Service->Deployment->Pod->Container。
就像开始说的，Kubernetes是个很大的生态系统，并且随着版本的迭代不断的在变得更加复杂。但是，只要你了解这些基础知识，基本的‘资源’如何使用，接下来学习更深的知识就会变得容易。下一步我会介绍以下内容：