其实，严格说来，容器编排Kubernetes，简称K8S，是CNCF（云原生计算基金会）的最核心的项目。几乎其它所有技术都是建立在K8S基础之上，丰富与扩展K8S的能力。
最应该讲的云原生计算其实就是K8S，不过我的这个顺序也是按照CNCF官方的按字母的排序来讲，也没有关系。
关于容器编排Kubernetes，其实很难一篇文章讲的清楚，K8S有着它强大的能力，与之相对应的就是它的复杂性。这篇文章做为介绍云原生官方各种技术的介绍性文章，我就着重让大家对K8S有个初步的认识就好了。
我在这篇文章中主要阐述：
- • 究竟什么容器编排技术
什么是容器编排
容器编排的背景主要是两个技术的不断发展，
- • 其一是微服务架构的兴起与流行，架构越发的呈现多个微小的服务合作共同完成的趋势
- • 其二是在微服务发展的基础之上，容器技术的发展
上述两个技术的发展，导致了一个需要解决的问题，就是服务的部署与运营的困难性
1. 单体架构的时代
我们回到单体架构的模式中去吧，再回顾一下在单体架构中我们是如何部署与运营服务的。
通常，完成一个单体架构的开发后，我们最终会获得一个Jar包或War包，也可能是ZIP包，形态各异。但它们的部署方式都是一样的，找一个或多个服务器，将这些包上传到服务器中，再使用命令或做成服务去启动它。
大多数情况下，基于高可用的考虑，一个单体服务我们会横向扩容，部署多份。前面再使用负载均衡来分发。
这种模式下，一切部署都依赖于开发或运营人员手工的操作。由于服务仅就1个，再怎么高可用，也没有多少，这种方式运转良好，很久以来都一直是这个模式。
不要说单体服务，就我看到的，很多所谓的微服务现在仍然保持着这种部署与运营模式。
2. 微服务的时代
但是，来到微服务时代或云原生时代，情况就不太一样了。
设想一下，一个项目有数十个服务，每个服务又通常根据实际业务需求需要部署可能数个到数百个甚至是成千上万个实例不等。这么算下来，你需要部署数十个 * 数百个这样规模的服务实例。
设想一下，如果一个个部署，要多少人或多少时间来部署这成千上万个实例，一个个服务器的操作系统的安装，Java运行环境的安装，再上传服务包，再启动它们，再组成集群，再来配置负载均衡，哪些服务出问题时，再登录到对应的服务器上去，重启它或撤掉这个服务？
这现实么？
当然不现实，所以，随着微服务的发展，服务的部署与运营的自动化就成为了一种必须了，是一定会出现并发展的技术与趋势。
3. 容器技术的时代
而同时，容器技术不断发展，进一步促使自动部署的可能性。过往我们都是一个Jar或War，但那不是一个可自运行的构建物，你还得给它挑选一个操作系统，安装必要的JDK环境等，做成服务来启动它，不同的技术这些东西还不一样。
但有了容器技术，从过往的构建物变成了可自运行的容器镜像，你只需要下载一个镜像，启动它，不再需要关心它的各种操作系统，环境以及必要的依赖。
但类似Docker这样的容器技术，它只解决了单个服务的自运行问题，对于整个系统，有数百个服务的情况下，它就表现的无能为力了。
于是，在容器技术之上，就出现了容器编排技术。而容器编排不管你如何定义它，它的核心能力与目地就是：
自动化的管理成千上万个容器服务
这就是容器编排的核心能力，不管是K8S，Docker Swarm还是OpenShit或其它，也不管容器编排在这之外提供了什么其它能力，最核心与关键的就是这一点。
自动化的管理成百上千个容器服务，你只需要一份指令，告诉容器编排，要部署多少个实例等，其它的一切，从下载容器镜像，到部署到服务节点，到启动它，到健康检查服务健康，到自动移除失效的服务再补充新的服务，甚至是根据Metric数据自动扩容等等一切能力，都由容器编排来实现。
也就是，在容器编排的时代，你是妥妥的
"运筹策帷幄之中，决胜于千里之外"
容器编排的能力
当然，关于容器编排的能力，还是可以稍微具体的说一下，以便对容器编排有进一步的了解。
容器编排
- 1. 根据声明式配置，自动启动与运行服务
有了容器编排，你只需要定义一个声明文件，大多是yaml格式（当然也有些支持JSON等），在声明文件中指系统的每个服务的期望状态，容器编排会自动调度与安排工作节点来启动与运行这些服务，达到你期望的状态。
无须你关心服务会部署到哪个节点，无须你关心服务的IP是多少，一切都交给容器编排工具去完成。
所谓的期望状态，是指服务的实例数量（比如授权服务需要100个实例），服务可分配的内存，CPU限额等，这些统称为期望状态
- 2. 将服务器资源做为一个资源池来分配资源
有了容器编排技术，你不需要关心去分配资源，比如A服务需要更好的CPU，需要更多的内存，怎么去购买不同的服务资源系统等。容器编排把所有的服务器资源统一计算为一个资源池。
比如你有10台服务器，总共有160核CPU，160G内存以及10000G硬盘空间，那容器编排就把这些资源做为一个资源池，根据你的期望或它自动使用一些算法，分配到不同资源到不同的服务。
你要做的，就是在需要时，增加一些工作节点，加入到容器集群中去就行了。至于如何分配资源，不需要你来操作。
- 3. 服务的可用性自动处理
服务挂掉了，收到警告了，要跑到服务器上去重启？
在单体服务，这是运维人员经常需要做的一件事，但是在容器编排时代，这一切都不需要了，你只需要为服务定义合适的健康检查机制（比如提供一个REST用做健康检查），容器编排技术会定期自动的根据你的配置去检查服务的健康性，如果一个服务节点当机了，容器编排技术也能自动侦测到。
当发现不健康的服务时，容器编排技术处理非常简单直接高效，销毁此服务，重新调度在可用节点上再新起一个服务来替换它，这一切都是自动的。
当然，对于有状态的服务与无状态的服务，在这一点上可能稍有不同，这里略过不谈。
- 4. 服务的自动扩缩
这个特性在部分容器编排技术上有，比如K8S (HPA，水平自动扩缩），Docker Swarm则没有。
自动扩缩是指根据服务所承受的请求与资源情况，自动的为此服务新加实例或删减实例。
比如，你可以定义：如果服务资源已经平均到60%的CPU，则扩容服务这样的规则。这样，在一些特别的时间，当有大规模并发涌入时，容器编排能自动的对服务进行扩容。
是不是非常方便？
- 5. 服务发现与查找
在微服务时代，你需要在架构层面，考虑服务发现与查找的实现。比较有名的比如Zookeper，NacOS或Spring Cloud中的一些技术。
但是容器编排本身就提供了基于DNS等的一些服务查找与发现机制，这意味着都不需要你关注与实现这样的服务与查找机制，使用容器编排的服务与查找机制就可以了。
在架构上可以节省很多工作。
云操作系统
由于容器编排的这些强大的管理能力，使得我们在部署一个服务时，压根不用考虑底层的操作系统，CPU与内存等这些了。只需要不断增加服务器到容器编排集群中去，然后在容器编排的能力之上，再去考虑如何部署与运营我们的系统。
因此，这样的技术也被称为云操作系统
而在所有的容器编排技术中，以Kubernetes最为流行，成为事实上的主导与标准。
但这并不部署着只有K8S，也有类似Docker Swarm其它的一些容器编排技术存在，而K8S本身由于其复杂性，又有一些变种存在，比如MicroK8S,MiniKube等。
下一篇，继续聊一下Kubernetes。
