转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。
上节中咱们提到了社区生态的倒退使得Kubernetes失去了良性的倒退和流传。比起绝对关闭的Docker社区凋谢的CNCF社区取得了更大胜利，但仅仅是社区的生机比照还不足以让Docker这么快的败下阵来，其根本原因是Kubernetes的对容器编排技术的了解比起Docker更胜一筹。这种劣势简直是压到性的降维打击，Docker毫无还手之力。
接下来便为大家介绍在这场容器大战之中，Kubernetes如何占据劣势位置。
容器编排
所谓容器编排，其实就是解决容器和容器之间的关系，在一个分布式的大型零碎里，不可能是以多个繁多个体存在的，它们可能是一个与多个，一群与一群这样相互交织着。
Docker的容器编排性能
Docker构建的是以Docker容器为最外围的PaaS生态，包含以Docker Compose为主的简略容器关系编排，以及以Docker Swarm为主的线上运维平台。用户能够通过Docker Compose解决本人集群中容器之间的关系，并且通过Docker Swarm治理运维本人的集群，能够看到这所有其实就是当初Cloud Foundry的PaaS性能，所主打的就是和Docker容器的无缝集成。
Docker Compose做到的是为多个有交互关系建设一种“连贯”，把它们全副编写在一个docker-compose.yaml文件中，而后对立公布（我前面说到的组里的ELK性能就是这样做的），这样做也有长处，就是对于简略的几个容器之间的交互来说十分便当。然而对于大型的集群来说却有些无济于事，并且这种每呈现一种新需要就须要独自做一项新性能的开发模式，将使前期代码保护变得十分困难。
Kubernetes如果要和Docker反抗，必定不能仅仅只做Docker容器治理这种Docker自身就曾经反对的性能了，这样的话别说分庭抗礼，可能连Docker的根本用户都吸引不到。因而在Kubernetes设计之初，就确定了不以Docker为外围依赖的设计理念。在Kubernetes中，Docker仅是容器运行时实现的一个可选项，用户能够根据本人的爱好任意调换本人须要的容器内容且Kubernetes为这些容器都提供了接口。此外，Kubernetes精确的抓住了Docker容器的一个致命性的弱点进行了本身翻新。
接下来就让咱们一起来理解，这个给Docker造成降维打击的内容到底是什么？
Kubernetes的容器编排性能
与Docker这种站在容器视角上只能解决容器之间的关系所不同，Kubernetes所做的是从软件工程的设计理念登程，将关系进行了不同类的划分，定义了严密关系（Pod之间）和交互关系（Service之间）的概念，而后再对不同的关系进行特定的编排实现。
乍一听你可能是一头雾水。这里举个不太理论然而一看就懂的例子：如果把容器之间的关系比作人之间的关系，Docker能解决的是仅仅是站在繁多个体的角度上，解决人与人之间的人际关系；而Kubernetes确是上帝，站在上帝视角不仅能解决人与人之间的人际关系，还能解决狗与狗之间的狗际关系，最次要的是能解决人与狗之间的来往关系。
而实现上述严密关系的原理，就是Kubernetes翻新的Pod。
Pod是Kubernetes所翻新的一个概念，其原型是Borg中的Alloc，是Kubernetes运行利用的最小执行单元，由一个或者多个严密合作的容器组合而成，其呈现的起因是针对容器的一个致命性弱点——繁多过程这问题的扩大，让容器有了过程组的概念。通过第一节，咱们晓得了容器的实质是一个过程，其自身就是超级过程，其余过程都必须是它的子过程，因而在容器中，没有过程组的概念，而在日常的程序运行中，过程组是经常配合应用的。
应用Pod解决严密关系
为了给大家介绍Pod解决严密关系的原理，这里举一个过程组的例子：
Linux中有一个负责操作系统日志解决的程序rsyslogd是由三个模块组成，别离是：imklog模块、muxsock模块以及rsyslogd本人的main函数主过程。这三个过程组肯定要运行在同一台机器上，否则它们之间的基于Socket的通信和文件的替换都会呈现问题。
而上述的这个问题，如果呈现在Docker中，就不得不应用三个不同的容器别离形容了，并且用户还得本人模仿解决它们三个之间的通信关系，这种复杂度可能比应用容器运维都高的多。并且对于这个问题的运维，Docker Swarm也有本人自身的问题。以上述的例子为根底，如果三个模块别离都须要1GB的内存运行，如果Docker Swarm运行的集群中有两个node，node-1残余2.5GB，node-2残余3GB。这种状况下别离应用docker run 模块运行上述三个容器，基于Swarm的affinity=main束缚，他们三个都必须要调度到同一台机器上，然而Swarm却很有可能先调配两个去node-1，而后残余的一个因为还剩0.5GB不满足调度而使这次调度失败。这种典型的成组调度（gang scheduling）没有被妥善处理的例子在Docker Swarm中常常存在。
基于上述的需要，Kubernetes有了Pod这个概念来解决这种严密关系。在一个Pod中的容器共享雷同的Cgroups和Namespace，因而它们之间并不存在边界和隔离环境，它们能够共享同一个网络IP，应用雷同的Volume解决数据等等。其中的原理就是在多个容器之间创立其共享资源的链接。然而为了解决到底是A共享B，还是B共享A，以及A和B谁先启动这种拓扑性的问题，一个Pod其实是由一个Infra容器联结AB两个容器独特组成的，其中Infra容器是第一个启动的：
Infra容器是一个用汇编语言编写的、主过程是一个永远处于“暂停”状态的容器，其仅占用极少的资源，解压之后也仅有100KB左右。
实例演示在Kubernetes中的Pod
介绍了一通，接下来咱们在实例中为大家演示Pod长什么样子。
咱们在任意一个装有Kubernetes的集群中通过以下的yaml文件和shell命令运行处一个Pod，这个YAML文件具体是什么意思临时不必理睬，之后我会对这个YAML做一阐明，咱们目前只须要明确：Kubernetes中的所有资源都能够通过以下这种YAML文件或者json文件形容的，当初咱们只须要晓得这是一个运行着busybox和nginx的Pod即可：
创立这个hello-pod.yaml文件之后运行以下命令：
通过上述命令，咱们就胜利创立了一个pod，咱们能够从执行后果看到infra容器的主过程成为了此Pod的PID==1的超级过程，阐明了Pod是组合而成的：
至此，咱们应该要了解Pod是Kubernetes的最小调度单位这个概念了，并且也应该把Pod作为一个整体而不是多个容器的汇合来对待。
咱们再看看形容这个Pod的文件类型YAML。
YAML的语法定义：
YAML是一种专门编写配置文件的语言，其简洁且弱小，在形容配置文件方面远胜于JSON，因而在很多新兴的我的项目比方Kubernetes和Docker Compose等都通过YAML来作为配置文件的描述语言。与HTML雷同，YAML也是一个英文的缩写：YAML Ain't Markup Language，聪慧的同学曾经看进去了，这是一个递归写法，突出了满满的程序员气味。其语法有如下特色：
- 大小写敏感
- 应用缩进示意层级关系，相似Python
- 缩进不容许应用Tab，只容许应用空格
- 缩进的空格数目不重要，只有雷同层级的元素左侧对其即可
- 数组用短横线-示意
- NULL用波浪线~示意
明确了以上概念，咱们把YAML改写成一个JSON，看看这之间的区别：
这两种写法在Kubernetes中是等效的，上述的JSON能够失常运行，然而Kubernetes还是更举荐应用YAML。从下面的比照中咱们也能发现，在之前的应用中始终很好用的JSON当初也略显蠢笨，须要些大量的字符串标记。
看完语法，咱们再来说说上述YAML中的各个节点在Kubernetes所示意的意思。Kubernetes中的有一种相似于Java语法万物皆对象的概念，所有外部的资源，包含服务器node、服务service以及运行组Pod在kubernetes中皆是以对象的模式存储的，其所有对象都由一下固定的局部组成：
- apiVersion：在官网文档中并没有给出相应的解释，然而从名字能够看出这是一个规定API版本的字段，然而此字段不能自定义，必须合乎Kubernetes的官网束缚，目前咱们用到的根本都是v1稳定版
- kind：指明以后的配置是什么类型，比方Pod、Service、Ingress、Node等，留神这个首字母是大写的
- metadata：用于形容以后配置的meta信息，比方name，label等
- spec：指明以后配置的具体实现
所有的Kubernetes对象根本都满足以上的格局，因而最开始Pod的YAML文件的意思是“应用v1稳固版本的API信息，类型是Pod，名称是hello-pod，具体实现是开启ProcessNamespace，有两个容器。
晓得了YAML的概念，让咱们在回归主题。为了解决容器繁多过程问题，只创立Pod的起因之一是Google通过Pod实现了本人的容器设计模式，而Google则为Kubernetes编写了最适宜的容器设计模式。
举个最罕用的例子：
Java我的项目并不能像.Net Core我的项目那样编译实现后间接自宿主运行，必须要把编译生成的war包拷贝到服务宿主程序比方Tomcat的运行目录下才能够失常应用。然而在理论状况中越大的公司分工越明确，很大概率负责Java我的项目开发和服务宿主程序开发的团队并不是同一团队。
为了让上述情况中的两个团队能够各自独立开发并且还能够严密单干，咱们能够应用Pod解决这个问题。
上面这个yaml文件就定义了一个满足上述需要的Pod：
在这个yaml文件中，咱们定义了一个java程序和tomcat程序的容器，并且对这两个容器之间的容器进行了一次挂载操作：将java程序的/app门路以及tomcat程序的/root/apache-tomcat/webapps同时挂载到了sample-volume这个挂载卷上，并且最初定了这个挂载卷就是一个内存数据卷。并且定义了java程序所在的容器是一个initContainer，阐明此容器是在tomcat容器之前启动的，并且启动之后执行了一个cp的命令。
在上述Pod形容了这样一个场景：程序运行开始运行时，Java容器启动，把本人的war包sample.war拷贝到了本人的/app目录下；之后tomcat容器启动，执行启动脚本，执行的war包从本人的/root/apache-tomcat/webapps门路下取得。
能够看到通过上述的配置形容，咱们既没有改变Java程序，也没有改变tomcat程序，却让它们完满的配合工作了，实现理解耦操作。这个例子就是容器设计模式中的Sidecar模式，还有很多设计模式，感兴趣的同学能够去进一步自行学习。
总结
以上介绍的就是Kubernetes为了解决严密关系而形象进去的概念Pod的根底内容了，须要留神的是，Pod提供的只是一种编排的思维，而不是具体的技术计划，在咱们应用的Kubernetes框架中，Pod只不过是以Docker作为载体实现了而已，如果你应用的底层容器是虚拟机，比方virtlet，那这个Pod创立时就基本不须要Infra Container，因为虚拟机天生就反对多过程协同。
在说完了Pod的根底的内容，在下一节中咱们将会为大家介绍在接下来的容器编排和平之中，Kubernetes又是如何怀才不遇。