本文讲的是容器、Docker与Kubernetes——什么是Kubernetes以及它是如何使得容器化基础设施变得简单【编者的话】本文是系列文章第2篇，主要介绍Kubernetes。
在本系列文章的 第一篇 中我阐述了从基础设施的容器化角度阐述了什么是容器，什么是Docker以及它们是怎么来重新定义运维工作以及对基础设施产生的影响。但是，仅仅了解了容器与Docker还不足以将它们运用到我们实际的技术栈中去；所以在本篇文章中我会介绍Kubernetes——一个容器的编排（orchestration）工具——我选择用它来为基础设施容器化部署提供支持。
Google是容器的“重度玩家”，在Google内部的成百上千台服务器上夜以继日的运行着数以十亿计的容器；时间一长，便开发出了自己的容器管理工具集用于管理如此巨量的基础设施—— Borg ；而就在几年前，Borg团队将多年积累的容器运行编排管理经验聚集到了一个新的项目，取名叫做Kubernetes，并将其开源贡献给了大众。
Kubernetes——继承自Borg，是一组能够彼此配合与协作的工具与服务的集合，通过使用这组工具，就能解决我在 上一篇博客 中所提出的容器服务化所面临的问题。当然，Kubernetes一个非常复杂的系统，它由很多互相配合使用的组件构成；同时，它也是一个适用于生产环境使用，并经过严格与广泛测试过的，并在除google公司以外很多公司检验过的成熟产品。Kubernetes的学习曲线也是很陡峭的，但是庆幸的是它的 官方文档 是非常全的；任何关于Kubernetes的细节都能在其官方文档中找到答案；同时还为每个知识点配置了很多例子与开发建议，当然还有可能出现的报错说明；更加令人惊讶的是，Kubernetes的官方文档网站还提供了一个基于浏览器的互动式的 操作指导 ，我个人非常推荐大家去试试。
正像我之前说的，你会发现Kubernetes有很多东西需要掌握，是这样的；但是你并不需要理解所有关于Kubernetes的技术细节才能够正确使用它。在这篇文章中，我会把我了解到的关于Kubernetes的一些基础知识、概念以及我现在使用的那些工具做个介绍。
我不会阐述Kubernetes中所有的‘资源’类型，因为太多而且还在增加；我会介绍在Kubernetes中启动一个应用所需要了解的几个基本‘资源’类型，如：Pod、Deployment、Service与Namespace；我还会围绕这几种资源类型介绍其他一些概念与如何使用它们。
Pod就是Kubernetes中的‘不可变层（immutable layer ）’；Pod不会升级，只会关闭、丢弃与被代替。它们可以被手动启停，但是不建议这样。在Kubernetes集群中对Pod的配置与管理都是通过‘Deployment’来完成。
这是一个Deployment，它配置了3个nginx Pods：
这可能有些难理解，我下面举一个例子来说明。比如，我们在一个
下面是一个命名空间的例子：
就像开始说的，Kubernetes是个很大的生态系统，并且随着版本的迭代不断的在变得更加复杂。但是，只要你了解这些基础知识，基本的‘资源’如何使用，接下来学习更深的知识就会变得容易。下一步我会介绍以下内容：
在本系列的第3篇中我会介绍更多的关于启动、配置与管理Kubernetes集群的更细节的内容。
在本系列文章的 第一篇 中我阐述了从基础设施的容器化角度阐述了什么是容器，什么是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是个很大的生态系统，并且随着版本的迭代不断的在变得更加复杂。但是，只要你了解这些基础知识，基本的‘资源’如何使用，接下来学习更深的知识就会变得容易。下一步我会介绍以下内容：
- 任何应用都有敏感信息需要保持安全（数据库密码等），Kubernetes中的secrets资源就是用来在Pod与容器中保护你的敏感信息的；
- DaemonSet资源类型用于定义在部分或者所有Nodes中都冗余的运行一个Pod。
- Job资源用于创建一次性的任务，例如当你需要迁移一个数据库时可以使用。
在本系列的第3篇中我会介绍更多的关于启动、配置与管理Kubernetes集群的更细节的内容。
原文链接：CONTAINERS, DOCKER, AND KUBERNETES PART 2（翻译：肖劲）
原文发布时间为：2017-03-01
本文作者：肖劲
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：容器、Docker与Kubernetes——什么是Kubernetes以及它是如何使得容器化基础设施变得简单
