知识点1--认识Docker

IT界2014年之前，对于服务器虚拟化的使用，有过一个流派，基于Windows server系统+VMware组成服务器集群，但是后期由于这样的使用方式维护成本相当高，比如服务器的序列、服务器台账以及服务器与服务器之间的切换等等，诸如此类的问题都需要人工去主导，所以这种流派渐渐的泯灭消失在正式环境开发中，如今只会在一些学习环境下见到这样的环境，就比如作者在2021年的时候上班的公司接了公家学校合同组建IT的相关专业，当时公司方面赞助学院微机教室的器材中，软件方面就是提供了一台华为的服务器，在这台服务器上搭的Windows Server 2008+vmware。

2014年以后，主流的正式开发中，所使用的虚拟化技术就是linux+docker+k8s，两者相比之间好处就在于系统支持上linux比WINDOWS更利于服务器的运行，同时docker将虚拟化的使用变得更简洁更轻量化，大大的简化了运维成本，而k8s是后面我们要介绍的一个东西，它其实是基于docker的一个脚手架，这个脚手架的作用就像我前面说的，用来解决服务器的序列、服务器故障切换等等的运维问题，它的运行是用逻辑单元pod，可以把pod看成我们开发好的一个大服务，一个pod里面包含着n个docker，这些docker承载着组成这个大服务的各种环境镜像。

言归正传，Docker它的本质是将某个服务做成镜像，用的时候实例化一个容器环境，有点开箱即用的味道。最直观的好处就是当我们开发一个东西后，拿到它的人不在需要一点一点的复刻运行环境，只需要拿到我们提供的Docker镜像就可以直接运行。

另一点好处启动快，我们在开发中常常用到VMware，但是该虚拟机软件下的虚拟机实例启动一次往往是分钟级的，但是Docker运行的虚拟容器的重启是秒级的。这里说的虚拟机实例和虚拟容器有些差别，虽然vmware和docker都是虚拟化技术的软件，可VMware的虚拟机实例说的是一个完整的操作系统，而虚拟容器它本质上是一个被隔离的进程，其中运行了Docker镜像的实例对象。

在Docker的技术背景下生成了一个概念DevOps，它的核心思想是开发既运维，白话就是不要运维岗位了，开发使用Docker保证环境的维护，但是目前为止这个概念还不现实，不是说技术达不到，而是社会工作结构就不允许资本家怎么干。当然这种概念虽然不现实，但是它的本意是好的，它是为了更快速的交付和部署、更便捷的升级和容器伸缩、更简单的运维以及更高效的资源利用。

这里强调一下容器伸缩，其实也有一部分高效利用资源的意思，典型的例子就是阿里双十一、春运买票或者微博热点等业务背景下，需要大量的服务器资源，这个时候需要的资源可能动辄上千台服务器，你总不能去手动搭建吧？时间不说是否足够，人力成本就能拖垮你，就算真的搭建出来了，万一出现意外呢？最后不出现意外，使用结束这些资源后怎么办呢？放哪里不动等下一次用？

综上所述，Docker的优点也就体现出来了，轻量化秒级的快速启动速度、简单易用、活跃的社区，支撑统一的打包部署运行方案、镜像支持增量分发、易于构建良好的API、资源的利用尤其是内存和IO的开销。

大家在使用Docker的时候注意，Docker是用Go语言写的，而且出的比较晚，同时一般使用它都是在Linux上，当然Windows也可以，只是很少有人用，当前使用的CentOS中理论上只有6.5及其以上的版本可以运行Docker，因为Docker最低需要Linux的内核版本达到2.6.32-431或更高。

Docker的核心三大要素分为镜像、容器、仓库，其中镜像就和我们安装系统的ISO一个意思，是实例化容器时的模板。容器是镜像的实例。仓库是存放镜像的地方。

图看不懂没关系，知道Docker的三要素是什么就行。

最后要知道一点，但凡使用Docker的项目，大概率不是一个大项目，因为大项目所需要的资源已经不需要去考虑虚拟化这种经济用法了，比如作者见识过海油的项目，一个大机房百来台机器，都是直接上物理机的，更本不考虑虚拟化，倒不是有钱，而是开发出来的系统所承受的业务量导致已经没有必要虚拟化了。

对于我们开发工程师来讲，还要知道一件事，Docker和k8s两者分开来讲的话，他们各自在各自的领域权重都很大，如果抛开k8s不讲，在日常的工作中开发和测试，你使用docker完全没有问题。但是如果和k8s放在一起来讲包含运维的整个开发体系，那么你使用docker其实是不健康的，因为这两种技术一直无法直接互通，需要通过k8s提供的CIR接口，才能将docker作为k8s的容器引擎来使用。K8s官方一直因为这个事情而不爽docker，但是由于docker出生时间比k8s早，所以在2014年k8s刚起来的时候，正巧碰着docker的巅峰期，本来也是挣扎过的，但最后小胳膊拧不过大腿，捏着鼻子认了，才在2016年开始耗费大量的精力，主动去迎合docker，推出了CIR接口。但是随着k8s的发展，在虚拟化容器编排领域，已经占了相当大的市场份额，说句最直白的话，完全可以单方面一脚踹了docker，从用户市场方面耗死docker，只是因为k8s的使用厂商没有办法一时之间迭代掉docker容器技术，所以k8s有这个心，却没有付出实际行动。直到1.20.15版本的时候，眼看时机成熟，k8s直接宣布正式踹了docker。这一点可以看github上k8s的1.20.15的版本说明https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation，开头第一句就告诉你，从此版本开始已经不再支持docker，并且会将相关内容在后期版本删掉。作为程序员我们管不着两个技术官方之间怎么互掐，到底是最后docker醒悟去主动配合k8s？还是docker被k8s耗死？亦或者是其他的结果，我们都管不着。我们只需要关心一点，就目前两个技术还没有达成一致之前，如果你想用k8s+docker组合，只能用1.20.15以下的k8s版本，而Docker版本保险起见最高用18.06.3左右的，右也不要右出太多。