为什么是容器，Docker和Kubernetes?

最新推荐文章于 2024-07-04 17:28:24 发布

dotNET跨平台

最新推荐文章于 2024-07-04 17:28:24 发布

阅读量455

点赞数

如果你是一名IT行业的从业者，还没有听说过以上3个词的任何一个，抱歉，你可以改行了；如果你是一名技术人员，无论你是程序员，测试人员，运维工程师还是时髦的DevOps工程师，你还没有运行过docker ps，抱歉，你也可以转行了。

容器 … 伴随着2013发布的开源项目Docker，以迅雷不及掩耳盗铃之势迅速席卷了整个IT行业，一瞬间每个人都在谈论容器，谈论Docker，谈论Kubernetes。但，这一切都不是一瞬间的事情 … …

为什么是Docker?

让我们把时间拉回到1995年，那一年我刚刚进入北京理工大学管理学院，成为了一名大一的新生。虽然是管理学院，但不务正业的自己还是喜欢鼓捣各种电子产品，借着高三假期在中关村打工的机会认识了一些“业内人士”，也在学校里面帮人攒机赚点外块。

640?wx_fmt=jpeg

当然赚外快就需要关注各种配件行情，所以开始关注各种技术杂志；这个时候开始，在各种电脑类杂志上开始频繁出现一个词汇，就是 Web Service。当时的我还完全看不懂这里面的玄机，而容器的发展应该说从那个时候就已经埋下了伏笔。

640?wx_fmt=png

在1995年，任何一种技术栈所开发出来的软件都是无法很方便和其他技术栈进行通讯的，除非使用共享内存，文件系统的方式。跨进程访问是一个阻碍技术发展的巨大难题，而对这个难题最不满意的其实是企业的管理者们。因为对于管理者而言，一旦购买了某个厂商的某个技术栈的产品，那么就必须一直“忠实”的与这个厂商合作下去，同时一直使用同样一个技术栈开发后续的扩展。什么意思呢，就是说如果你用Java开发一个系统（注意：这只是个例子，1995年的Java还仅限于applet的状态），你是不可能使用任何其他语言，比如：C#，PHP，Python等，与这个系统进行集成的。这个状态让企业管理者感到非常不可接受，因为他们感觉被绑架了，明明市场上有根好的解决方案，有便宜的开发人员，但仅仅因为技术的限制我就必须和这个厂商合作。

这个问题必须解决！

同时，1995年互联网开始普及，于是科学家们开始研究使用网络通信的方式来解决跨进程访问的问题，这样才出现了Web Service这种借助标记语言(XML)来抽象不同技术栈的实现方式，统一使用简单的纯文本报文的方式来实现跨进程访问的技术。这种方式从那个时候一直在持续被改进，并最终演化成了今天的Rest API的标准。这件事情，到2015的时候已经不再是一个障碍了，你现在可以使用任何语言，在任何系统上和其他语言的系统进行自由高效的通讯。在这个过程中，IT系统架构也随之改变，从原来只能是一个厂商，一个操作系统，一个技术栈的烟囱式架构，逐渐演变成不同厂商，不同技术，不同操作系统的网状架构 … … 其实这就是我们所说的集中式到分布式，单体到微服务的整个演化过程。

这个过程中，企业管理者终于自由了，技术人员也终于自由了，大家不再受限于某种单一的技术，可以自由的选择适合的组件来“拼装”一个IT系统。这件事情同时也和整个开源运动互相推动。现如今，在一个IT系统中引入某种开源组件，或者与一个第三方系统进行集成都不再是一个技术问题。大家变得随意，自由，敏捷起来。

640?wx_fmt=png

但是，任何事情都有它的两面性。在获取了自由，敏捷的同时，整个IT架构变得无比复杂，开发人员开始组装出高度异构化的系统，而运维环境也开始采用更加复杂的分布式，x86，虚拟化和云来支撑这类异构的系统。

这个时候，企业管理者的另外一个大麻烦又来了，如何管理这复杂的NxN问题？不仅仅技术变得更加复杂，人员知识结构也成为了一个巨大的瓶颈。原来的IT运维人员只需要掌握一个技术栈的知识，而现在每个服务都使用不同的技术栈运行在不同的硬件或者虚拟化平台上。

这个问题也必须解决！

640?wx_fmt=png

于是，聪明的技术人又一次发挥了充分的想象力，利用容器的方式完美的解决了这个问题。Docker通过统一开发人员打包交付代码的方式，和统一运维人员运行软件包的方式，让开发人员做到“一次构建，多次运行”，让运维人员做到“配置一次，运行任何应用”。

640?wx_fmt=png

最终，Docker以自己特有的逆向思维模式用最简单的方式解决了这个问题。具体请参考：Docker，容器，虚拟机和红烧肉

640?wx_fmt=png

如果你对运维自动化工具有所了解，就一定知晓Ansible, Chef, Puppet以及Vagrant等等这些工具。但，如果把Docker和这些工具做比较，你就会发现他们其实解决了同一个问题，但使用了2种完全不同的思路。Docker是用简单的办法解决复杂的问题，而其他那些工具都使用复杂的办法来解决复杂的问题。

640?wx_fmt=png

到这里，我想我已经解答了前面2个问题，为什么是容器和Docker?

为什么是Kubernetes？

这个问题我想从《2018全球DevOps现状调查报告》中针对云计算发展的这张总结来说明，云计算所需要具备的五个核心特征恐怕大家都了解。但是即便过去这些年各大企业都在风风火火的建设自己的云计算，但其实没有几个企业的所谓云计算具备了这些特征。特别是大多数传统企业所建设的云计算，都是打着云计算的幌子继续卖传统数据中心的狗肉。

即便是已经上了公有云的很多企业，也仍然按照老的方式在使用先进的云计算平台，生生的把公有云用成了库房里面的服务器。

640?wx_fmt=png

这些问题当然不仅仅是技术问题，还涉及到管理，文化和传统思维方式的问题。但是抛开这些非技术因素不谈，仅仅说技术，如果云计算仅仅能够解决IaaS层的问题，对于企业来说确实很难挖掘出真正的价值，最后也就是个虚拟化数据中心而已。企业业务真正需要的是PaaS层面的东西，但因为上述整个IT行业向异构化发展的趋势，一直没有一个真正的通用化的，可以被企业自己的数据中心玩得起来的PaaS出现。具体问题，可以看看CloudFoundry的发展现状就知道了。

这个时候，恰好Docker出现了，那么对于企业来说，上层对接应用技术栈的问题被完美解决了，还需要一个方案能够完美解决对接底层IaaS云计算基础设施的对接问题。

这个问题也必须被解决。

640?wx_fmt=png

可以这样说，有了编排平台，你可以在一个混合的云环境上运行任何你想要运行的应用，不用关心技术栈，不用关心操作系统，不用关心哪朵云，也不用关心应用在哪里。你完全可以在Azure上放3个节点，在AWS放3个节点，另外在家里的破旧服务器也放上3个节点来运行你的集群和应用。

编排平台解决了困扰企业管理者上云最大的担忧，就是被厂商绑定，被技术绑定，被操作系统绑定。特别是传统企业的管理者，终于找到了一个成熟的方案可以盘活自己花费巨资建立的"云计算"数据中心，让自己的“云”成为一朵真的云，真正为业务为开发者服务。

Kubernetes就是这样一个技术，它满足了企业管理者们这“最后一公里”的诉求。

一句话总结这满满长路

生命诚可贵，爱情价更高，若为自由故，二者皆可抛 … …

其实，每次聊起这些话题，有一肚子的话可以说。所以这一次，我请来了2位国内对容器，Docker，Kubernetes都非常熟悉，并且对于云计算解决方案，特别是基于微软Azure Stack混合云解决方案非常熟悉的老师来聊一聊关于容器，Docker和Kubernetes的话题。

话题1: Windows 上的 Linux 容器和私有云里面的Kubernetes是怎样玩的？

提起Docker，可能大多数人都不会觉和Windows有什么关系，但是Windows上也是可以运行容器的，而且是可以同时运行Windows和Linux两种操作系统的容器。是不是觉得很诡异？

640?wx_fmt=png

这一次就请彭爱华（网名：盆盆）老师来为大家刨析一下Windows上支持容器的技术内幕。彭爱华老师自从2014年开始就连任微软最有价值专家，并且著有多本Windows技术内幕的权威书籍。这次盆盆老师将为大家现场演示在Windows上同时运行2种容器，还将演示在Azure Stack中部署Kubernetes的实例环境。这些内容盆盆老师在刚刚结束的微软技术大会和CloudNative的KubeCon大会上都进行过分享，但是因为受限于会场网络环境，都只有视频展示，这一次我们将可以直接观看盆盆老师操作真实的Azure Stack环境完成Kubernetes的部署。还可以直接提问交流哦，想想都过瘾！

话题2: 企业上K8s的那些不得不跨越的门槛

要把Kubernetes真正用起来，其实还是有很高的门槛的，这些是现在困扰大多数企业开发者的难题。Alan Liu老师在帮助企业落地K8s环境方面具有非常丰富的经验，这次也将给大家实地演示使用全托管的Azure Kubernetes Services环境，配合Azure Pipeline流水线，并结合开源的Draft工具来完成基于k8s的DevOps流水线搭建和实战。

640?wx_fmt=png