如何理解去docker与k8s

今天就跟大家聊聊有关如何理解去docker与k8s，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。

Kubernetes(简称K8S)与容器技术，可以说是近几年最火热的技术之一。提起K8S，大家都知道是google开源的容器编排工具。今天想先谈谈，我理解的容器、K8S是什么，以及为什么它们能火起来。

Why Docker

既然说K8S是一个容器编排的工具，那么要搞清楚K8S是什么，首先得搞清楚，容器是什么，以及为什么要用容器技术。

形象的来说，一个linux容器，实际就是一个进程，还是个被系统欺骗的进程。为什么这么说呢？一个运行在容器里的进程，主要有以下特点：

• 它被宿主机操作系统隔离了，它看不到宿主机上的其他进程，以为自己就是pid为1的进程

• 它被宿主机操作系统限制了硬件资源，它能使用的cpu、内存等硬件资源只是宿主机的一部分

• 在被宿主机操作系统限制了存储空间，让这个进程认为宿主机的某个目录就是系统根目录

这几个欺骗进程的技术，就是是容器技术的三板斧，用于资源隔离的namespace，用于资源限制的cgroup,以及用于伪装进程根目录的rootfs。这三种技术，都是是早已存在于linux中的，只是docker公司比较创新的把这三种技术整合在一起，并且，提出了容器镜像及镜像仓库等概念，把这个进程及相关的依赖环境都一起打包成可分发及重复使用的镜像文件，方便容器能在不同机器之间移植。这样，在任何地方，只要能运行docker，就能把容器镜像跑成一个包含这应用进程及相关依赖环境的容器实例。

这里用利用K8S官方文档的图，简单说下生产中的场景，看看容器技术能解决什么问题。

左图是传统的物理机部署应用方式的方式，可以看到除了一个应用的运行，除了程序本身，离不开应用配置、库、等等依赖环境。通常情况下，一个应用的上线，要经历开发环境、pre环境、beta环境、灰度测试、生产环境等等不同的基础环境。开发的同学在开发环境跑通了代码，到其他环境运行时，由于各环境依赖、配置、安全需求不同，可能会出现各种问题。运维的同学忙着在不同的环境中统一依赖。不同应用各种语言，各种应用的特殊依赖需求，也造成了CI/CD逻辑复杂，难以统一。

右图是用了容器技术之后的场景。一个容器镜像的实质就是程序进程加所有运行时环境及配置、依赖的集合。只要各个环境的底层能兼容docker，就能实现所有环境部署的一致性。开发同学不用关心生产环境和开发环境的差异可能会导致应用运行问题，运维同学部署一个应用，只要确保容器镜像能正常运行就好。CI/CD的自动化也相对容易实现很多。从而极大增加开发效率、应用迭代效率及节省了运维工作量。

说到这里，不得不说下容器与传统意义的虚拟机间的对比。其实二者都可以理解为虚拟化，它们最本质的区别是，容器是操作系统层级的虚拟化，而虚拟机是硬件层级的虚拟化。参看下图。

在容器编排这个概念出现的时候，Kubernetes并不是唯一的一个容器编排工具，主流的工具还有Docker公司原生的swarm和Apache基金会的mesos，为什么K8S能笑到最后，成为容器编排的事实标准呢？我理解K8S对比它们有两个最大不同点：（这里不对swarm和mesos做详细介绍了，实际也确实没怎么玩过）

K8S对容器又做了一层抽象，也就是POD。

不同于与其他两个工具，K8S管理的原子对象，其实并不是容器，而是POD。按照官方文档的定义，一个POD，是由一个或多个共享存储及网络的容器，以及描述怎么运行这些容器的集合，所以，POD实际是一个抽象的概念。k8s对容器的所有操作，比如动态伸缩、监控等，实际上都是对pod的管理。那这层抽象的好处是什么呢？
上面有提到过，容器实质就是被特殊处理的进程。想像一个web业务，web应用进程输出的日志需要被大数据agent进程处理。这个业务如果想容器化，通常有两个做法。一是分别起来两个容器，挂载宿主机同一个目录来存放日志。另一种是起一个操作系统级别的容器或supervisord容器作为enterpoint，来管理web服务和agent进程。前一种方式，这个两个容器就被框在这台宿主机上了，要实现业务实例横向扩缩容，要考虑两个容器的运行情况和存储挂载，逻辑比较复杂。后一种方式，你要为每个容器再额外开一个supervisord进程，更重要的是，由于entrypoint是supervisord进程，web应用和大数据agent对docker来说，都是不可见的。即使nginx出错频繁重启，只要supervisord还活着，Docker就认为这个容器是正常的。

我们再来看看，使用了pod这个概念以后，有什么变化。一个pod里面同时起了web服务进程和大数据agent两个容器实例，首先，pod里的容器实例是共享存储和网络namespace的，也就是说，这两进程的存储数据是直接共享的，不需要额外的挂载动作。其次，这个pod是作为一个整体被k8s管理着的，k8s会监控pod里每个容器的状态，并根据策略在有问题时进行自动干预。从这个意义上说，pod才更类似传统的虚拟机。

• 声明式API
  第二点也是比较重要的方面，是K8S的声明式api(貌似swarm的新版也支持了，同样没玩过就不细说了)。什么是声明式API呢，可以参考上面系统图中的描述文件。比如要我需要集群中跑10个web服务容器，传统的命令式API是一步步调用命令构建出容器。而使用声明式api，只要告诉K8S我要10个web容器，K8S就会自动将web集群实例数维持在10个，并且，在某个pod出问题退出时，K8S会自动重新拉起新pod，使集群始终保持10个pod实例在跑。这就使得管理集群变得很简单，只要通过配置文件描述出希望的集群状态，而不用去关注中间的实现过程。

总结：

• Why Dokcer：用容器技术跑应用，相比原来的物理机及虚拟机更高效、轻量、省资源，同时大大方便了不同环境下的应用部署及分发。

• Why Kubernetes：生产集群光跑容器还不够，还要对容器应用作为一个业务系统集群进行编排及管理，而K8S的一些优势使得它成为目前容器集群编排管理工具的事实标准。
  最后的最后再多提一点，实际上，容器技术不止Docker公司一家在做，Kubernetes也不是只能管理Docker容器。只是，无论从市场份额、应用性还是开发社区的热度来说，它们都是目前容器技术最主流的解决方案，就生产环境来说，目前基本没有必要去考虑其他的容器技术了。

看完上述内容，你们对如何理解去docker与k8s有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注亿速云行业资讯频道，感谢大家的支持。