vlambda博客
学习文章列表

K8S VS Docker !结局意想不到!

Kubernetes vs Docker是云计算行业中多次提到的话题。无论您是否有技术背景,需要快速介绍,还是需要做出业务决策,我希望以下几点将一次性澄清这一问题。

Kubernetes与docker之间的共生关系

问题“Kubernetes vs Docker?”本身就相当荒谬,就像把苹果比作橙子。一个不是另一个的替代品。相反,kubernetes可以在没有docker的情况下运行,docker可以在没有kubernetes的情况下运行。但是Kubernetes可以(并且确实)从Docker中受益匪浅,反之亦然。

Docker是一个独立的应用程序,可以安装在任何计算机上运行集装箱化的应用程序。容器化是一种在操作系统上运行应用程序的方法,使应用程序与系统的其余部分隔离。您为您的应用程序创建了一个错觉,即它获得了自己的操作系统实例,尽管同一个系统上可能运行着其他容器。Docker使我们能够在单个操作系统上运行、创建和管理容器。

如果您在一组主机(不同的操作系统)上安装了Docker,则可以利用Kubernetes。这些节点或Docker主机可以是服务器或虚拟机。然后,Kubernetes允许您从单个命令行或仪表板跨所有这些节点自动化容器供应、联网、负载平衡、安全性和扩展。由单个kubernetes实例管理的节点集合称为kubernetes集群。

现在,为什么首先需要多个节点?其背后的两个主要动机是:

  1. 使基础架构更加稳定——即使某些节点离线(即高可用性),您的应用程序也将在线。

  2. 使您的应用程序更具可伸缩性——如果工作负载增加,只需生成更多容器和/或向Kubernetes集群添加更多节点。

“Kubernetes自动化扩展,管理,更新和删除容器的过程。换句话说,它是一个容器编排平台。虽然Docker是集装箱化的核心,但它使我们能够首先拥有集装箱。“


Kubernetes与docker之间的差异

原则上,Kubernetes可以使用任何容器化技术。Kubernetes可以集成的两个最流行的选项是rkt和Docker。然而,Docker赢得了最大的市场份额,这导致了在完善Docker和Kubernetes之间的集成方面的大量努力,比任何其他集装箱化技术都要多。

同样,Docker公司(Docker公司)提供了自己的容器编排引擎,名为Docker Swarm。但即使他们意识到Kubernetes已经上升到了这样的地步,即台式机(MacOS和Windows)的Docker也有自己的Kubernetes发行版。

如果有人对采用基于Docker的产品采用Kubernetes感到紧张,那么最后一点就可以摆脱所有的疑虑。这两个项目都全心全意地相互拥抱,并从这种共生中获益匪浅。

Kubernetes与docker之间的相似点

这些项目不仅仅是技术,他们是一个由人组成的社区,尽管他们存在差异,但他们是由行业中一些最聪明的人组成的。当志同道合的人合作时,他们会交换聪明的想法并互相学习最佳实践。

这些是Kubernetes和Docker共享的一些想法:

  1. 他们喜欢基于微服务的体系架构(稍后会详细介绍)。

  2. 他们热爱开源社区。两者都是开源项目。

  3. 它们主要用Go编写,允许它们作为小型轻量级二进制文件发布。

  4. 它们使用人类可读的YAML文件来指定应用程序堆栈及其部署。

从理论上讲,你可以了解其中一个而不了解另一个。但请记住,在实践中,如果您从一台机器上运行Docker的简单案例开始,然后逐渐了解Kubernetes是如何发挥作用的,那么您将受益更多。

让我们更深入地讨论这个话题……

什么是docker?

有两种方式来看待Docker。第一种方法是将Docker容器视为真正的轻量级虚拟机。第二种方法是将Docker视为软件打包和交付平台。后一种方法被证明对人类开发人员更有帮助,并导致了该技术的广泛采用。

让我们更仔细地看一下这两个不同的观点…

K8S VS Docker !结局意想不到!  Docker容器概述

传统上,云服务提供商使用虚拟机将正在运行的应用程序彼此隔离。虚拟机监控程序或主机操作系统为许多客户操作系统提供虚拟CPU、内存和其他资源。每个客户操作系统的工作方式就好像它是在实际的物理硬件上运行一样,理想情况下,它不知道在同一物理服务器上运行的其他客户机。

VMware是第一个普及这一概念的公司之一。但是,这种虚拟化有几个问题。首先,资源的提供需要时间。每一个虚拟磁盘映像都是大而笨重的,准备好一个虚拟机使用可能需要一分钟的时间!

其次更重要的问题是系统资源利用效率低下。操作系统内核是控制狂,他们想要管理可以使用的内容。因此,当客户操作系统认为可以使用2GB内存时,即使运行在该操作系统上的应用程序只使用其中的一半,它也会控制该内存。

另一方面,当我们运行容器化的应用程序时,我们操作系统(您的标准库、包等)本身虚拟化,而不是硬件。现在,您不再为虚拟机提供虚拟硬件,而是为应用程序提供虚拟操作系统。如果需要,您可以运行多个应用程序并对它们的资源利用率施加限制,并且每个应用程序将无视其运行的数百个其他容器。

K8S VS Docker !结局意想不到!K8S VS Docker !结局意想不到!  Docker - 作为开发人员的工具

开发人员面临的一个问题是,应用程序运行的生产服务器与开发应用程序的自己的开发机器(通常是笔记本电脑和工作站)之间存在差异。让我们设想一下,您的桌面上运行着Windows10,但您想为Ubuntu18.04编写应用程序。也许您正在使用Pythonv3.6编写应用程序,而Ubuntu服务器仍在3.4版本上运行。


有太多的变量需要考虑,所以我们使用Docker来抽象这种复杂性。Docker可以安装在任何操作系统上,甚至支持Windows和Mac OS X。因此,您可以将代码打包到Docker映像中,使用Docker在本地运行和测试,以确保从该Docker映像创建的容器在生产中的行为相同。


注意:所有依赖项(如编程语言版本、标准库等)都包含在该镜像中。


这种将Docker镜像视为软件包的方式导致了以下流行的引用:


“Docker会做些什么来解决tar的问题。”

apt,包管理器,仍然在使用tar,但是用户不必担心它。同样,在使用Docker时,我们也不必担心包管理器,尽管它仍然存在。即使在开发node.js技术的基础上,开发人员也更喜欢在node的官方docker映像之上构建docker映像。

所以,这只是对Docker是什么以及为什么人们可能想知道它的简要概述,即使他们不参与DevOps。

现在让我们继续讨论Kubernetes。

什么是Kubernetes?

如上所述,Kubernetes采用集装箱化技术。它允许我们跨多个计算节点(可以是VM或服务器)运行容器。一旦Kubernetes控制了一组节点,根据我们在任何给定时间的需要,容器可以旋转或拆除。

如果您访问他们的官方网站,Kubernetes明确表达其目的:

“Kubernetes是一个开源系统,用于自动化容器化应用程序的部署,扩展和管理。”

到目前为止,我们只介绍了Kubernetes的一个简短概述,即自动创建一组容器。应用程序需要有存储空间,并且需要管理一些DNS记录。您需要确保参与计算的节点彼此安全连接,以此类推。拥有一组不同的节点而不是单个主机会带来一组完全不同的问题。

Kubernetes架构的简要概述将帮助我们了解它如何实现所有这些以及更多功能。

K8S VS Docker !结局意想不到!  Kubernetes架构 - 简要概述

关于Kubernetes集群,您需要了解两个基本概念。第一个是节点。这是Kubernetes管理的VM和/或裸机服务器的常用术语。第二个术语是pod,它是Kubernetes的基本部署单位。pod是需要共存的相关Docker容器的集合。例如,您的Web服务器可能需要与Redis缓存服务器一起部署,以便您可以将它们中的两个封装到一个Pod中。Kubernetes将它们并排展开。如果它对你来说更简单,你可以完全想象一个由一个容器组成的容器,这样就可以了。

回到节点,有两种类型的节点。一个是主节点,其中安装了Kubernetes的核心,它控制应用程序实际运行的各个工作节点上的pod的调度。主节点的工作是确保维护所需的群集状态。

K8S VS Docker !结局意想不到!

以下是Kubernetes图的简要概述,如上所示。

在Kubernetes Master,我们有:

  1. kube-controller-manager:这负责考虑集群的当前状态(例如,X个正在运行的pod)并做出决定以实现期望的状态(例如,改为具有Y个活动pod)。它会监听kube-apiserver以获取有关群集状态的信息

  2. kube-apiserver:这个API服务器暴露了Kubernetes的齿轮和杠杆。它由WebUI仪表板和命令行实用程序(如kubeclt)使用。这些实用程序又由人工操作员用于与Kubernetes集群交互。

  3. kube-scheduler:这是决定如何在整个集群中调度事件和作业的方式,具体取决于资源的可用性,运营商设置的策略等。它也会监听kube-apiserver以获取有关集群状态的信息。

  4. etcd:这是Kubernetes主节点的“存储堆栈”。它使用键值对,用于保存策略,定义,机密,系统状态等

我们可以拥有多个主节点,这样即使主节点发生故障,Kubernetes也能够存活。

在工作节点上,我们有:

  1. kubelet:这会将有关节点运行状况的信息转发回主节点,并执行主节点给它的指令。

  2. kube-proxy:此网络代理允许应用程序的各种微服务在集群内相互通信,并且如果您愿意,还可以将应用程序公开给世界其他地方。原则上,每个pod可以通过此代理与每个其他pod进行通信。

  3. Docker:这是拼图的最后一块。每个节点都有一个Docker引擎来管理容器。

当然,还有更多的Kubernetes,我鼓励您探索所有这些。

全行业采用docker和Kubernetes

到目前为止,我们讨论过的许多概念听起来不错,但它们是否经济实惠?他们是否真的会帮助您的业务增长,减少停机时间并节省人力和计算能力方面的资源?

K8S VS Docker !结局意想不到!  生产中的docker

当涉及到采用Docker时,答案很简单。尤其是如果您的软件采用了基于微服务的体系结构,那么您绝对应该为每个微服务使用Docker容器。

这项技术相当成熟,几乎没有人能反对它。请记住,仅仅容纳您的代码并不会让您更好。如果您真的想要使用容器化平台,请尝试避免单片设计并寻求微服务。

K8S VS Docker !结局意想不到!  生产中的Kubernetes

人们不应该因为在生产中对Kubernetes受到指责,我个人认为这背后的原因是双重的。

首先,大多数组织盲目地跳跃而不了解分布式系统的基本概念。他们试图建立自己的kubernetes集群,并使用它来承载简单的网站或小型可扩展应用程序。

“如果你对系统没有深入的了解,这是非常危险的。事情很容易打破“

其次,Kubernetes正在迅速发展,其他组织也在向其添加自己的特殊之处,如服务网格、网络插件等。其中大多数都是开源的,因此对操作人员很有吸引力。但是,在生产中运行它们并不是我推荐的。要跟上它们,需要对集群进行持续的维护,并且需要花费更多的人力。

但是,组织可以使用云托管的Kubernetes平台来运行其应用程序。像AWS、Azure、Joyent或GCE等公司提供的全球数据中心的可用性实际上可以帮助您充分利用Kubernetes的分布式特性。当然,您不必担心维护集群。

这是中小型组织经常错过的事情。如果您想在节点故障中生存并获得高可伸缩性,那么不应该在单个1U机架上甚至在单个数据中心上运行kubernetes。

那么,生产中的Kubernetes?是的,但对于大多数人,我会推荐云托管解决方案。

容器和云计算的新时代

Docker并非作为操作系统级别的虚拟化软件,它作为软件打包和交付机制进行销售。Docker容器引起其竞争对手不关注的唯一原因是这种软件交付方法。

Dockerfiles让自动构建变得更加容易。由于docker-compose,复杂的多容器部署现在已经标准化。软件工程师通过提供完整的CI / CD解决方案(包括构建和测试Docker镜像以及管理公共或私有Docker注册表),使容器达到其逻辑极端。

Kubernetes已经将容器从卡在一台计算机上解放出来,使得这种技术变得更加吸引人。慢慢地,但肯定地,集装箱化将成为每个云依赖服务的标准,因此,更早采用这种技术非常重要,而不是更晚。这样做可以最大限度地降低迁移成本和相关风险。

分布式操作系统的案例

我会说明为什么你应该采用Kubernetes。云计算已经发展成为这个竞争激烈的市场,谷歌,微软,亚马逊和许多其他玩家互相竞争。

这大大降低了在云中部署软件的成本。关于Kubernetes的最好的事情是它是一个很大程度上是开源的,所以你可以理解发生了什么,而不会让细节陷入困境。

以下是Azure推销其Kubernetes服务:

“使用Azure Kubernetes服务来创建和管理Kubernetes集群。Azure将处理集群操作,包括创建,扩展和升级,从而使开发人员可以专注于他们的应用程序。首先,使用Azure Kubernetes Service创建一个集群。“

只要了解它在表面层上是如何工作的,就可以让您在分布式系统中运行软件时对其进行推理。但您不必担心实际管理底层集群!


亚马逊、谷歌和DigitalOcean也很快提供了类似的解决方案。即使是小企业和个体开发人员现在也可以在全球范围内扩展其应用程序。稍微了解一下它是如何实现的并不伤人,所以你至少应该对Kubernetes和Dockers有一个短暂的熟悉。


每次当你想到“Kubernetes vs.Docker?”反对者会说docker很酷,但是kubernetes有点极端。但是整个计算机科学都是关于极端自动化的,Kubernetes把集装箱化模型带到了逻辑上的极端!

更微妙的差异:网络

许多Kubernetes与Docker的争论都源于基础知识,如存储堆栈和网络的实现。Docker和Kubernetes都喜欢以不同的方式做事。

容器需要的不仅仅是CPU和一些内存才有用。在像Kubernetes和Docker主机这样的平台上运行应用程序之间存在许多细微差别。这些差异太多了,不能在这里简明扼要地提及,但总是引起我注意的是网络方面的事情。

Kubernetes指定每个pod应该能够在给定的命名空间中与群集中的每个其他pod自由通信。Docker有一个创建虚拟网络拓扑的概念,而您必须指定您希望容器连接到哪些网络。像这样的区别确实可以让人们推迟试验,但是当你考虑Kubernetes与Docker的根本区别时,它们是至关重要的:

“前者意味着跨群集运行,而后者则在单个节点上运行。”

除了这种困境之外别无选择,你需要耐心等待学习。渐渐地,你就会上升到另一个高度。

采用docker和Kubernetes的理念

使用Docker,其好处相当明显。如果您在Docker容器上发布应用程序,那么它也可以在任何Linux发行版上运行。即使是基于Illumos的操作系统,也不是Linux,支持Docker,并且可以运行Docker容器。

您的应用程序实际上可以分解为几个微服务,这样每个微服务都可以打包为Docker容器。通过定义良好的API,可以轻松地将新功能添加到现有API中。例如,如果您想要分析,只需启动可以与数据库通信的Hadoop容器。

同样,当谈到Kubernetes时,用户和云服务提供商实际上可以通过采用它来获益。由于它基于容器化,因此与传统虚拟机不同,云服务提供商可以有效地利用其资源获得高密度的容器。这使他们可以大幅降低价格。

另一方面,用户可以在全球范围内部署他们的应用程序,从而减少延迟并改善用户体验。

这种转变的唯一例外是桌面应用程序开发人员。由于大多数桌面应用程序可能使用云进行更新和/或备份,但它们主要设计为在单个计算机上运行。

容器太棒了!它们使我们能够以全新的数字方式思考服务和系统。Docker和Kubernetes都将留在这里。他们不断变化,将自己转化为未来更美好的事物。让您的公司参与技术时代,并实施您的基础设施最需要的容器。

为以容器为中心的平台设计更新的软件不仅可以使您的应用程序更具可扩展性,而且还可以更加面向未来。坚持使用旧虚拟机可能现在可以使用,但是几年之后,您最终将要承担将所有内容迁移到容器或完全放弃项目的巨额成本。希望现在,如果有人提出“Kubernetes vs Docker”的主题,你不会被行话冲昏头脑。

长按二维码 ▲

如有启发,帮我点个在看,谢谢↓