Kubernetes 如何打赢容器之战？

背景

PaaS

PaaS 技术，一句话概括就是：它提供了“应用托管”的能力。

早期的主流做法基本上是租 AWS 或者 OpenStack 的虚拟机，然后把这些虚拟机当作物理机一样，用脚本或者手工的方式在上面部署应用。这个过程中如何保证本地环境和云端环境的一致性是一个很大的课题，而提供云计算服务的公司的核心竞争力就是比拼谁做的更好。从某种意义上来说 PaaS 的出现，算是一个比较好的解决方案。

以 Cloud Foundry 为例，在虚拟机上部署上 Cloud Foundry 项目后，用户可以很方便地把自己的应用上云。以上帝视角来看这个过程：Cloud Foundry 最核心的是提供了一套应用的打包和分发机制，它为不同的编程语言定义了不同的打包格式，它能把可执行文件、启动参数等等一起打包成压缩包然后上传至 Cloud Foundry 存储中心，最后由调度器选择虚拟机，由虚拟机上的 Agent 下载并启动应用。

分布式系统

随着软件的规模越来越大，业务模式越来越复杂，用户量的上升、地区的分布、系统性能的苛刻要求都促成服务架构从最初的单体变成 SOA 再到如今的微服务，未来还可能演变为 Service Mesh ，Serverless 等等。

如今，一个完整的后端系统不再是单体应用架构了，多年前的 DDD 概念重新回到大家的视线中。现在的系统被不同的职责和功能拆成多个服务，服务之间复杂的关系以及单机的单点性能瓶颈让部署和运维变得很复杂，所以部署和运维大型分布式系统的需求急迫待解决。

容器技术

前面提到诸如 Cloud Foundry 的 PaaS，用户必须为不同语言、不同框架区分不同的打包方式，这个打包过程是非常具有灾难性的。而现实往往更糟糕，当在本地跑的好好的应用，由于和远端环境的不一致，在打包后却需要在云端各种调试，最终才能让应用“平稳”运行。

而 Docker 的出现改变了一切，它凭借镜像解决了这个问题。Docker 一不做二不休，干脆把完整的操作系统目录也打包进去，如此高的集成度，保证了云端和本地环境的高度一致，并且随时随地轻易地移植。

谁也不知道就因为“镜像”这个简单的功能，Docker 完成了对 PaaS 的降维打击，占有了市场。此时，一些聪明的技术公司纷纷跟进 Docker，推出了自家的容器集群管理项目，并且称之为 CaaS。

容器技术利用 Namespace 实现隔离，利用 Cgroups 实现限制;在 Docker 实现上，通过镜像，为容器提供完整的系统执行环境，并且通过 UnionFS 实现 Layer 的设计。

Docker 容器是完全使用沙箱机制，相互之间不会有任何接口。通过 Docker，实现进程、网络、挂载点和文件隔离，更好地利用宿主机资源。Docker 强大到不需要关心宿主机的依赖，所有的一切都可以在镜像构建时完成，这也是 Docker 目前成为容器技术标准的原因。所以我们能看到在 Kubernetes 中默认使用 Docker 作为容器(也支持 rkt)。

Kubernetes

铺垫了这么多，终于说到本文的主角了。说 Kubernetes 之前，不得不提 Compose、Swarm、Machine 三剑客，其实在 Kubernetes 还未一统江湖之前，它们已经能实现大部分容器编排的能力了。但是在真正的大型系统上，它们却远远不如 Mesosphere 公司出品的大型集群管理系统，更别说之后的 Kubernetes 了。

在容器化和微服务时代，服务越来越多，容器个数也越来越多。Docker 如它 Logo 所示一样，一只只鲸鱼在大海里自由地游荡，而 Kubernetes 就像一个掌舵的船长，带着它们，有序的管理它们，这个过程其实就是容器编排。

Kubernetes 起源于 Google，很多设计都是源自于 Borg，是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效，并且提供了应用部署，规划，更新，维护的一种机制。

小结

至此，读者了解了 Kubernetes 的前世今生，由 PaaS 的火热，引爆了容器技术的战争，而赢得这场战争中最关键的即是拥有强大的容器编排的能力，而 Kubernetes 无疑是这场战争的胜利者。

设计理念

这一部分，我们会围绕 Kubernetes 的四个设计理念看看这些做法能给我们带来什么。

声明式 VS 命令式

声明式和命令式是截然不同的两种编程方式，在命令式 API 中，我们可以直接发出服务器要执行的命令，例如： “运行容器”、“停止容器”等;在声明式 API 中，我们声明系统要执行的操作，系统将不断向该状态驱动。

我们常用的 SQL 就是一种声明式语言，告诉数据库想要的结果集，数据库会帮我们设计获取这个结果集的执行路径，并返回结果集。众所周知，使用 SQL 语言获取数据，要比自行编写处理过程去获取数据容易的多。

apiVersion: extensions/v1beta1 
kind: Deployment 
metadata: 
 name: etcd-operator 
spec: 
 replicas: 1 
 template: 
 metadata: 
 labels: 
 name: etcd-operator 
 spec: 
 containers: 
 - name: etcd-operator 
 image: quay.io/coreos/etcd-operator:v0.2.1 
 env: 
 - name: MY_POD_NAMESPACE 
 valueFrom: 
 fieldRef: 
 fieldPath: metadata.namespace 
 - name: MY_POD_NAME 
 valueFrom: 
 fieldRef: 
 fieldPath: metadata.name 

我们来看看相同设计的 YAML，利用它，我们可以告诉 Kubernetes 最终想要的是什么，然后 Kubernetes 会完成目标。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!