转载请注明出处：葡萄城官网，葡萄城为开发者提供业余的开发工具、解决方案和服务，赋能开发者。
上节中咱们提到了社区生态的倒退使得 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 又是如何怀才不遇。