作为一名长期从事运维的工程师来说，我会时常审视维护服务器工作的简单性与可重现性；而我的一个最重要的工作原则便是“永远不要手动操作服务器”。所有服务器都必须由工具进行启动（provisioned）与配置以运行，同时通过工具来监控、维护服务器的状态——而我的选择是Chef；当然你也可以有很多其他选择如：Ansible、Salt与Puppet。
在Collective Idea中，Chef确实运行得非常好，它管理着公司内部与外部客户的很多服务器。但是，渐渐的我也意识到了Chef的一个缺陷：对变化的处理不好。生产环境的应用与基础设施都是有很多复杂的构件（creatures）组成，这些构件都由很多变化的组件（moving parts）组成，组件之间又有大量的显式或者隐式的依赖——它们随时都会由于不可预知的原因发生变化。其中，有些变化容易处理，如配置文件更改或者对系统进行微调；但是其他一些就比较复杂，如，不停机升级一个应用依赖的Ruby运行时版本。而且，还有一些对服务器的调整需要人工操作，如，升级操作系统内核后的重启等。
简而言之，以我多年使用Chef的经验，它在搭建新的运行环境与配置系统上确实工作得非常好，而且也是我需要的；但是在处理一些升级，变更等需求的时候，就会变得非常费事而且容易出错。有没有工具能够减轻服务器升级变配带来的痛苦呢？
不可变基础设施
解决问题的一个方案是“不可变基础设施”应用部署模式；具体表现为，相对于一个个机器的升级（针对上面所讲的情况）基础设施，这种方式会直接丢弃掉老版本的基础设施，然后将应用程序整体迁移到一个已经升级完毕的新的基础设施中运行。但是，本质上“不可变基础设施”部署方式仍然需要一个类似于Chef的工具用于初始化、配置与启动基础设施，不同的是一旦一个基础设施在运行了，它的状态与配置就不允许发生变更；如果有配置变更需求则启动新的基础设施来代替老的。当然，这种部署方式有其自己的复杂性，它必须能够随时删除或者下线一个老的基础设施然后启动一个新的——任何时候都有可能发生。那么问题就来了，对于数据库来说怎么升级？升级新的web服务器后怎么重新注册到老的负载均衡器上？升级新的负载均衡器又如何能保持其下诸多的Web服务器不掉线的升级？实际上，要完全实现不可变基础设施的服务器部署是有很多技术瓶颈的，导致其在现实环境中很难实现。有些工具如： Packer 能够在一定程度上减轻创建虚拟机镜像的工作难度的，但是你仍然需要面对一整套的环境搭建工作，这通常需要花费很长的构建与生成时间，因为你一般需要下载数G的文件来搭建一个单独的系统。
有没有方法能够同时兼顾不可变基础构架的方便直观，而且镜像文件又能保持足够小呢？有没有工具使我们打包镜像时剔除掉操作系统与底层抽象只保留应用程序本省与其依赖呢？这样我们就能只部署一个很小的镜像，迁移那些发生变化的数据，最后节约大量的部署时间。这就是 容器 技术为我们带来的改变，如 Docker 与 rkt （读音同“rocket”）。在容器为基础的基础环境中，底层的服务器与虚拟机都被抽象成了资源如：CPU与内存。
因为我平时使用Docker所以在以下介绍中我用Docker为工具来讲述我的观点，当然还有其他类似的容器化工具如rkt，效果是一样的。
Docker
Docker，简单来说，它将应用程序的执行文件、命令都打包在一起，称为镜像（image），然后在宿主机或者虚拟机上部署运行这个镜像；而运行起来的镜像被称为“容器”，反过来说，容器就是运行时的镜像。容器在一个封闭、隔离的环境中运行，在这个环境中它认为自己是系统中唯一运行的程序，这种隔离性保证一个宿主机可以同时运行多个容器，但是互相并不知道对方的存在。Docker镜像文件是一次写入的（write-once，就像一张光盘），这使得Docker基础环境看上去就是一个不可变基础构架。镜像与容器永远不会更新，新的镜像生成伴随着老的容器的关闭，而这个过程相对于关闭与启动一个服务器或者虚拟机来说只需要非常短暂的时间。
所以，你会问，那我们Collective Idea是不是把所有的服务都迁移到了Docker上了？我的回答是，没有，现在还没有。容器的使用有个单一职责的原则需要遵循：运行多个容器，各个容器只完成一个单一的工作。进一步说，将服务容器化的过程就是基础构架SOA化的过程；这个过程一样面临很多问题与困难：
- 容器与容器之间如何发现与通信？
- 如何决定在哪运行以及运行多少个容器？
- 如何获取容器运行的日志与运行状态信息？
- 如何部署新的镜像？
- 容器崩溃时都发生了什么？
- 如何只将特定的一部分容器暴露在公网或者内网环境下？
直至当下，相比现在服役的Chef工具来说，回答这些问题以及大规模在Collective Idea部署Docker应用都还不太成熟。但是，现在还是涌现出了很多解决我提出的问题的工具，而且还提供了可用于生产环境的容器化部署方案，如：Docker公司自己的Docker Compose；但是我们还是选择了Google的方案——Kubernetes ，它号称融合了Google在十几年来在其超大规模数据中心运行了数十亿个容器的经验。
在本系列文章的第一篇中我阐述了从基础设施的容器化角度阐述了什么是容器，什么是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是个很大的生态系统，并且随着版本的迭代不断的在变得更加复杂。但是，只要你了解这些基础知识，基本的‘资源’如何使用，接下来学习更深的知识就会变得容易。下一步我会介绍以下内容：