在这一章中,我们将通过介绍与容器化演进密切相关的关键技术,为您打下坚实的基础。我们将从介绍应用部署在几十年间的演进开始。我们将讨论虚拟化的概念,以及超级监视器在虚拟化过程中的关键作用。我们将扩展这个讨论,以了解分布式架构、云计算模型,以及虚拟化和分布式架构如何构成云计算的核心。我们还将讨论微服务架构以及容器化与微服务架构的区别。
接下来,我们将开始讨论两个关键的容器化技术:Docker 和 Kubernetes。我们将解释为什么需要容器编排器,比如 Kubernetes 和 Red Hat 的 OpenShift 容器平台(OCP),以及"云原生"和"无服务器"是什么意思。
最后,我们将回顾一些流行的替代品,替代 Docker 和 Kubernetes,并解释这些技术之间的关系。我们还将比较两个流行的容器编排平台:Kubernetes 和 Docker Swarm。
有了这些期望,让我们开始吧!
我们需要提出的基本问题
在本节中,我们将深入探讨与应用设计和部署在过去几十年中的演进密切相关的几个基本概念,以及容器化演进中涉及的关键技术。
应用部署是如何演进的?
我们可以将应用部署的演进分为三个部署模型:传统部署模型、虚拟化部署模型和容器化部署模型。图1-1展示了应用部署模型的演变。
传统部署模型
在传统部署模型中,应用程序直接在操作系统上运行,而操作系统则在硬件上运行。这种部署模型显然存在问题,因为一个糟糕的应用程序可能会占用大部分服务器资源,而其他应用程序则无法获得足够的资源。针对这个问题的一种典型解决方案是在不同的物理服务器上运行每个应用程序,但即使对于大型组织来说,运行一组物理服务器也是昂贵的。
假设我们有四个应用程序和一台5GB的物理服务器(为了方便理解,我们只考虑RAM大小)。因此,为了解决这个问题,我们将我们的应用程序部署在四台每台1GB的不同物理服务器上,为每个应用程序保证一组固定的服务器资源。
虚拟化部署模型
在虚拟化部署模型中,应用程序在一个(虚拟)操作系统上运行,而这个(虚拟)操作系统不像传统部署模型中直接在硬件上运行,而是在虚拟机(VM)内运行。虚拟机在一个超级监视器上运行,超级监视器在一个操作系统上运行,而操作系统则在硬件上运行。这个部署模型唯一的主要问题是虚拟机过于庞大,因此可伸缩性和性能成为瓶颈。
使用之前的例子,在虚拟化部署模型中,我们会在我们的5GB物理服务器上创建四个1GB的虚拟机,然后在每个独立的虚拟机中部署我们的四个应用程序。
容器化部署模型
在容器化部署模型中,应用程序在容器内运行,而容器则在容器运行时(如Docker)上运行。现在,这个容器运行时要么在操作系统上运行,就像传统部署模型中一样,要么在一个(虚拟)操作系统上运行,就像虚拟化部署模型中一样。在这个部署模型中,容器运行时虚拟化了操作系统。
使用之前的例子,在容器化部署模型中,我们会在不同的容器中部署我们的四个应用程序,并为每个容器分配1GB的服务器资源。
这是最好且最灵活的部署模型,因为如果在任何时候我们认为我们的其中一个应用程序只需要500MB的服务器资源,那么我们可以通过在几秒钟内重新配置容器来仅使用500MB的服务器资源来进行调整,从而释放出500MB的服务器资源,然后可以在其他地方使用。而这些调整是可能的,因为容器非常轻量级。
什么是超级监视器?
虚拟机是物理计算机的仿真,而超级监视器是创建和运行虚拟机的软件。超级监视器通过模拟CPU、内存和网络资源来虚拟化主机系统的硬件,从而这些资源可以被划分,从而创建多个虚拟机。由于超级监视器提供硬件虚拟化,每个虚拟机可以运行不同的操作系统。
主要来说,超级监视器有两种类型:Type-1 和 Type-2。图1-2显示了Type-1和Type-2超级监视器的图形表示。
Type-1(本机或裸金属)超级监视器
Type-1(本机或裸金属)超级监视器在裸金属上运行(或主机的硬件上),因此我们可以说,Type-1超级监视器是对硬件的一种抽象。由于Type-1超级监视器在裸金属上运行,它们对计算机资源拥有完全的控制权,因此Type-1超级监视器可以在不与主机操作系统进行接口的情况下执行资源管理和分配。
Type-1超级监视器的堆栈看起来像这样:底部是裸金属或硬件;在硬件之上是超级监视器;在超级监视器之上是许多不同的虚拟机。
IBM z/VM、Oracle VM Server for SPARC、Microsoft Hyper-V等都是Type-1超级监视器的例子。
Type-2(主机)超级监视器
Type-2(主机)超级监视器在主机操作系统上运行,而主机操作系统则在硬件上运行。由于Type-2超级监视器不直接在硬件上运行,因此它们无法执行完整的资源分配和管理;相反,系统管理员执行资源分配和管理,并将它们分配给所需数量的虚拟机。
Type-2超级监视器的堆栈看起来像这样:底部是裸金属或硬件;在硬件上是主机操作系统;在主机操作系统上是超级监视器;在超级监视器上是许多不同的虚拟机。
VirtualBox(Oracle的产品)、VMware Player等是一些Type-2超级监视器的例子。
什么是虚拟化?
虚拟化是一个广泛的概念,意味着创建某物的虚拟表示。在IT领域,虚拟化是一种技术,允许我们对计算资源进行虚拟化,如服务器、网络、存储等。通过硬件虚拟化,我们得到了虚拟机(VMs)。在虚拟化概念中的两个核心实体是超级监视器和虚拟机。超级监视器已经在前面的部分中进行了讨论,而虚拟机只不过是超级监视器的副产品。
不同的虚拟化类型是什么?
正如前面提到的,虚拟化是一个广泛的概念,通过它我们可以创建某物的虚拟表示。在IT方面,不同的虚拟化类型可以包括:
- 服务器虚拟化
- 存储虚拟化
- 网络虚拟化
- 数据虚拟化
- 桌面虚拟化
虚拟化和云计算有何不同?
云计算不过是按需交付计算资源的过程,而虚拟化是使云计算成为可能的技术。没有虚拟化技术,就不会有云计算。在云计算中,当您创建一个计算实例时,从技术上讲,它只不过是物理服务器的虚拟实例。
云计算的另一个支柱是分布式架构。
分布式设计是什么?
分布式设计,也被称为分布式计算、分布式系统或分布式架构,是一组跨足多个计算节点的计算系统,共同合作实现一个共同的目标。这些计算系统可以是软件进程或硬件设备。
分布式设计与集中式设计相对立,集中式设计中系统的完整状态位于一个中央节点或扮演主节点角色的中央节点上。在集中式设计中,由于所有关键决策都是集中的,存在瓶颈的可能性,一个节点的失败可能导致整个系统崩溃。而在分布式设计中,这种瓶颈或级联失败的可能性大大降低。
如图1-3所示,无论是在分布式系统还是集中式系统中,都有许多节点(计算系统),但区别在于在集中式系统中,一个节点将扮演主节点的角色,管理所有其他工作节点,而在分布式系统中,没有这样的主节点。集中式系统的主节点可能导致节点的级联失败,而由于分布式系统中缺乏这个主节点,因此没有单一故障点,使得分布式系统非常具有弹性。
简而言之,拥有分布式系统或设计意味着您的系统被设计成没有单一故障点。
云计算、微服务架构和容器化,在某种程度上都是分布式系统的实际例子。
在分布式设计中,有哪些不同的应用设计架构?
根据你如何设计你的应用程序,在分布式计算中可能有四种应用程序架构:
- 一个客户端和一个服务器的架构
- 三层架构
- n层架构
- 包含点对点通信的架构
一个客户端和一个服务器的架构
这是分布式计算架构中最基本的类型,由一个服务器和一个或多个客户端组成。服务器负责提供服务,客户端通过向服务器发出请求来消耗服务。最常见的情况是使用轻量级协议,如HTTP进行请求。电子邮件服务器、Web服务器和文件服务器是客户端-服务器架构的良好示例。
由于客户端-服务器架构是一种集中式架构,因此容易受到集中式架构的问题,如通信瓶颈和单点故障的影响。
三层架构
在三层架构中,服务器端存在不止一个层次:一个层次代表应用服务器,另一个层次代表数据库服务器。
代表应用服务器的层次通常扮演中间层的角色,位于客户端和数据库服务器之间。它们包含运行应用所需的所有应用和业务逻辑。
代表数据库服务器的层次通常扮演数据层的角色,负责数据存储和管理。从客户端层没有直接与这个第三层的通信;第三层只与中间层通信。
三层架构的优势在于减少了通信瓶颈和单点故障,提高了分布式计算性能。
n层架构
在n层架构中,通常称为多层架构,是三层架构的一种升级,其中服务器的责任被进一步划分为不同的层次或层,并且每个层次都有特定的责任。
假设应用程序设计被拆分为五个部分,那么它就成为一个五层应用程序架构。三层架构是n层架构的一个示例。
点对点通信的架构
点对点架构消除了客户端和服务器的角色,因为在这种架构中,没有单独的节点扮演服务器的角色,也没有单独的节点扮演客户端的角色;任何节点都可以扮演客户端或服务器的角色。
点对点架构是最接近分散系统形式的一种。在点对点架构中,由于任何节点都可以扮演服务器或客户端的角色,因此点对点架构的可扩展性是最高的。区块链和即时通讯是点对点架构的最佳示例。
什么是云计算?
简而言之,云计算是按需提供计算资源,客户按使用量付费。这些计算资源可以是现成的应用程序、服务器(无论是物理服务器还是虚拟机器)、存储、网络等。云服务提供商将这些计算资源托管在远程数据中心,并通过互联网按需提供。
云计算模型与传统的本地IT模型相对立,传统模型中组织要么支付巨额的前期成本购买昂贵的基础设施,要么支付大量的月费,无论基础设施是否被使用。这样,成本节省是云计算的众多优势之一。云计算模型的另一个重要优势是它使基础设施的供应非常迅速。在云计算中,资源的供应可以在几次鼠标点击和几秒或几分钟内完成,这与传统的本地IT模型形成对比,客户无需经过繁琐的官僚程序,也无需等待数天或数周才能获得所请求的基础设施资源。
虚拟化和分布式架构是云计算的推动者。而容器化和微服务架构是互补技术,当它们结合在一起时,提供了一个非常具有成本效益、可扩展且容错的应用生态系统。
云部署模型有哪些类型?
总体而言,云部署模型可以分为以下几类:
- 公有云模型
- 私有云模型
- 混合云模型
公有云是一种云部署模型,在这种模型中,云提供商通过互联网向用户提供所有计算资源。Google Cloud(谷歌)、Azure(微软)和AWS(亚马逊)是公有云的示例。私有云是一种云部署模型,其中云提供商将所有计算资源在客户的本地数据中心提供给客户使用。许多公司选择私有云出于安全性和法规合规性的原因。混合云部署模型是一种同时结合公有云和私有云的云部署模型。
云服务有哪些类型?
总体而言,云部署模型可以分为以下几类:
- 基础设施即服务(IaaS)
- 平台即服务(PaaS)
- 软件即服务(SaaS)
在IaaS中,完整的基础设施,包括存储、网络、物理服务器等,都是租用的,客户负责设置和管理一切。在PaaS中,基础设施由云提供商管理,客户得到一个用于开发和交付应用程序的环境。在SaaS中,客户通过互联网获得按需访问的现成应用程序。
什么是容器化?
容器化是一种虚拟化形式,因为它们都允许将应用程序完全隔离在基础架构之外,以便它们可以在不同类型的环境中运行。通过容器化,我们可以将运行代码所需的应用程序所有组件捆绑到一个称为容器的轻量级可执行文件中,并在相同的共享操作系统上的隔离用户空间中运行它。
容器化和进程隔离的概念已经存在很长时间,但微服务的架构转变和开源Docker Engine的发布加速了这一理念的广泛采用。容器化广泛被采用的另一个主要原因是它使应用程序变得完全可移植。一旦我们将应用程序的所有组件打包到一个容器镜像中,只要在该环境中有容器运行时,我们就可以在任何环境中运行此镜像。就像JVM使Java平台独立一样,容器化使应用程序实现"一次编写,到处运行"。
容器化有许多用例,但最流行的用例之一是微服务和多云部署。
开放容器倡议(OCI)是什么?
开放容器倡议(OCI)是一个专门创建的开放治理框架,旨在制定容器运行时的开放和共同的行业标准。
基于容器的解决方案的迅速增长使得有必要开发容器技术的标准和捆绑应用程序代码的方法。Docker和其他容器行业领导者于2015年6月成立了OCI。运行时规范、镜像规范和分发规范是当前OCI的三个规范。镜像规范概述了容器镜像的创建标准。OCI镜像规范包含镜像索引、镜像清单、一组文件系统层和一个配置。分发规范概述了如何促进和规范内容的分发。
OCI标准的优势在于您可以轻松地在符合OCI的容器运行时之间迁移应用程序。
容器化相对于虚拟化的优势是什么?
图1-4展示了容器化相对于虚拟化的优势,我们将在本节详细探讨这些优势。
这些是优势:
- 可移植性: 容器化相对于虚拟化的最大优势之一是可移植性。只要在环境中运行着底层的容器运行时,容器化应用程序将在所有环境中运行相同,无论是开发环境还是生产环境。这是因为容器化应用程序具备运行所需的一切,这很类似于JVM使Java代码平台无关。
- 隔离和分配: 在虚拟化情况下,无法将应用程序放在特定的资源边界内。但通过容器化,您可以指定容器的资源限制,从而将资源边界应用于应用程序本身。请注意,这里的比较是为了直接在应用程序上提供资源限制而进行的虚拟化和容器化技术之间的比较;这与像JVM这样的运行时提供限制内存使用的选项的比较不同。即使与像JVM这样的运行时进行比较,使用JVM没有办法指定CPU和其他资源限制,而这在容器化的情况下是可能的。
- 更适合微服务: 容器化应用程序非常适合微服务架构,因为我们可以单独部署和扩展容器。因此,在微服务架构中,我们可以将应用程序分解为更小的服务,并在每个服务内部运行一个容器,根据请求流量的需求对每个服务进行扩展或缩减。
- 可扩展性和速度: 与虚拟化相比,容器可以更快地创建、复制或销毁,因为操作系统内核在应用程序之间是共享的。请注意,容器启动有多快将取决于应用程序的大小,但通常容器可以在几秒钟内启动,而虚拟机可能需要几分钟。由于容器轻量且重新创建速度更快,因此容器的扩展比虚拟机更容易。
- 资源高效: 由于容器(更准确地说是容器镜像)只包含运行所需的应用程序,与虚拟机相比,它们的大小要小得多,这允许底层机器(无论是物理还是虚拟的)在相同的服务器容量上运行更多的容器。
- 故障隔离: 在容器运行时上运行的每个容器都在与其他运行容器的隔离环境中运行;因此,如果一个容器失败,它不会影响其他运行容器的工作。实际上,这是一个优势,因为如果我们有一个包含三个服务(也即容器)的电子商务应用程序:账户、计费和目录。如果由于某种原因账户容器崩溃,那么用户仍然可以进行目录和计费。请注意,故障隔离与容错不同。容器本身不提供容错,但容器编排系统如Kubernetes提供容错。
- 自动化: 使用容器化相比虚拟化更容易设计一个能够在不同平台和资源上无缝运行的自动化解决方案。
容器化应用程序能在云基础架构上运行吗?
是的。容器化应用程序不依赖于硬件基础架构的类型。底层硬件基础架构可以是我们自己的笔记本电脑,也可以是分布在多个数据中心的云基础架构。
什么是微服务架构?
微服务(或微服务架构)是一种云原生的架构方法,其中一个应用被分解为许多松散耦合且可以独立部署的服务。
微服务架构具有许多特征,但以下是任何基于微服务架构的应用程序的最基本特征:
- 每个应用服务都应该是可以独立部署的。
- 应用程序服务之间不应该有紧密的耦合。这基本上意味着如果一个服务需要更改,那么另一个服务不应受到显著影响。
- 每个服务应该围绕一个单一的业务功能或用例构建。
- 每个服务应该被设计成可以在不影响整个应用程序的情况下出现故障。这基本上意味着如果一个服务崩溃或失败,那么整个应用程序不应该崩溃。
- 每个服务应该使用轻量级协议(如HTTP)和轻量级数据交换格式(如JSON)与其他服务进行通信。
- 最好,与所有服务的所有接口交互应通过某个API网关进行。
图1-5是对微服务架构的简单图形描述。
微服务架构具有许多优势,以下是一些基本的优势:
- 更容易构建: 微服务架构的整个理念是将一个大型应用程序拆分为更小的部分,因此构建更小的部分变得更容易。不同的团队可以专注于单一业务功能,分别处理每个部分。
- 更容易部署: 由于微服务架构中的服务较小,它们将具有较少的环境依赖和与部署大型应用程序相关的其他复杂性,从而更容易部署。
- 更容易维护: 如果大型应用程序中出现错误,那么由于有很多移动部分,它可能变成一个主要挑战,但如果应用程序规模较小,则更容易找到问题并维护应用程序。
- 更高的性能和可伸缩性: 微服务架构的大多数服务通常部署在容器化平台上,容器本身提供性能和可伸缩性。
微服务 vs 单体应用
微服务架构方法与单体架构方法相对立,单体架构方法将所有内容捆绑到一个应用程序中,并作为单个可部署单元发布。单体架构方法的最大缺点是,如果应用程序的某一部分失败或崩溃,它会导致整个应用程序崩溃,因为所有部分都紧密耦合。微服务架构通过促进内聚性和松散耦合来解决这个问题。
微服务 vs. 面向服务架构 (SOA)
微服务架构方法也与面向服务架构 (SOA) 架构方法相对立,SOA 架构方法通过服务接口设计可重用组件。在执行应用程序之间集成的 SOA 架构的中心组件是企业服务总线 (ESB)。这种架构方法的最大缺点是随着时间的推移,系统可能变得越来越复杂,并最终形成多个服务之间的相互依赖关系。总的来说,SOA 架构主要围绕集成,并具有企业范围的范围,而微服务主要围绕应用程序设计架构,并具有应用程序范围的范围。
容器化与微服务架构有何不同?
我认为将容器化与微服务架构进行比较是不正确的。容器化和微服务架构不是竞争性技术,而是相辅相成的技术。在微服务架构中,一个应用程序被拆分成较小的服务,然后每个服务都部署在一个单独的容器中,可以根据需求进行扩展或缩减。
容器是微服务架构的关键组件,其他关键组件和技术包括 Kubernetes、API 网关和消息传递。
容器化的未来是什么?
尽管在过去的十年中,容器化已经占据了主导地位,但我仍然认为容器化的未来只是开始升温。最终,几乎所有的应用程序(无论是企业应用程序还是小型应用程序)都将进行容器化,以充分利用云计算模型提供的成本优势以及应用程序维护和可伸缩性的便利性。
许多知名的技术研究公司进行了大量的调查,所有的结果都表明容器化是未来的发展方向。
理解关键的容器技术
在这一部分,我们将了解两种关键的容器技术:Docker 和 Kubernetes。我们还将讨论 Red Hat 的 OpenShift 容器平台(OCP)以及"云原生"是什么意思。
什么是Docker?
Docker是一个开源平台,允许您开发、运行和发布容器化的应用程序。简而言之,Docker是一个容器运行时,使您能够将所有应用程序代码与其依赖项(包括外部和系统依赖项)打包到一个镜像中,然后通过运行该镜像创建容器。
容器运行时是一种软件,它知道如何从容器镜像中运行容器。Docker是最流行的容器运行时之一。还有其他流行的容器运行时,例如:
- CRI-O:一个符合OCI标准的Kubernetes容器运行时接口(CRI)实现,使得可以使用符合OCI标准的运行时。
- containerd:一个云原生计算基金会(CNCF)项目,另一个开源容器运行时,它被介绍为Docker的替代品,注重简单性、稳健性和可移植性。
在Kubernetes v1.24之前,有一个使用名为Dockershim的组件直接集成了Docker Engine。Kubernetes v1.27要求您使用符合容器运行时接口的运行时。
什么是Kubernetes?
Kubernetes允许您以有序和自动化的方式部署、扩展和管理容器化的应用程序。简而言之,Kubernetes是一个容器编排器。在技术社区中,Kubernetes也被称为K8s。使用像Docker这样的容器运行时,您可以将代码、依赖库和运行时打包成一个镜像并运行它以创建容器,但容器是短暂的;如果您的容器崩溃,您需要确保另一个容器会自动创建,这就是容器编排器(如Kubernetes)所做的事情。Kubernetes还使您能够进行资源管理,将容器分组以创建集群等。
有许多建立在Kubernetes上的技术和项目,例如Kubeflow。Kubeflow项目旨在简化在Kubernetes上部署机器学习(ML)工作流的整体设计、可移植性和可扩展性。
什么是Red Hat的OpenShift容器平台(OCP)
OpenShift Container Platform(OCP)是由红帽提供的高度可扩展的Kubernetes平台,可用于开发和运行容器化应用程序。使用OCP,您可以快速将OCP集群从少数服务器扩展到数十万个服务器。
OpenShift Container Platform基于Kubernetes构建,并与其他红帽技术紧密集成,使您能够快速将应用程序从单个服务器或虚拟机迁移到任何云环境。OCP对Kubernetes进行了企业级增强,包括以下功能:
- 混合云部署:您可以在各种云部署模型中部署OCP集群。
- Red Hat Enterprise Linux CoreOS(RHCOS):这是专门为托管容器化应用程序而创建的面向容器的操作系统,也是OCP使用的操作系统平台。该RHCOS包括CRI-O作为容器运行时。CRI-O是Kubernetes CRI实现,使得可以使用符合OCI标准的运行时。CRI-O容器运行时被认为提供更好的Kubernetes体验。
- 集成的红帽技术:OCP的主要组件包括红帽企业版Linux(RHEL)和其他红帽技术。因此,OCP从红帽广泛的经过认证的企业级软件测试计划中获益。
"Cloud-Native" 的含义是什么?
简单来说,"云原生"意味着你的应用程序/设计/解决方案与云计算交付模型兼容。云原生是一种软件开发和运行应用程序的方法,充分利用云交付模型提供的分布式计算能力。 云原生应用程序的设计旨在充分利用云计算提供的弹性、灵活性、韧性和可扩展性的优势。
云原生技术,如微服务和容器编排器,使您能够在任何云部署模型中创建、部署、运行和扩展容器化和非容器化应用程序。
什么是Serverless?
Serverless是一种云计算开发模型,使开发人员能够构建应用程序而无需管理服务器。Serverless并不意味着没有服务器;服务器确实存在,但它们对应用程序开发完全透明。这意味着应用程序开发人员无需担心底层服务器;云服务提供商确保所有服务器管理任务,如配置和维护,都得到妥善处理。开发人员只需在无服务器环境中部署其代码。 无服务器开发模型通常分为两种云计算提供方式:函数即服务(FaaS)和后端即服务(BaaS)。
BaaS提供了一系列可立即使用的后端服务,如日志记录、身份验证、审计、加密和解密等。FaaS是一种基于事件的云服务;一些外部事件将触发开发人员编写的代码/逻辑,并且只有在执行代码/逻辑时客户端才会发生变化。这使得FaaS成为一种非常经济的选择。 由于无需管理服务器和其他开销,无服务器计算模型非常适合快速开发。几乎所有主要的云服务提供商都提供了可用于快速开发的无服务器服务,如谷歌云提供的Google Cloud Functions,微软提供的Microsoft Azure Functions,以及亚马逊提供的AWS Lambdas。
虽然FaaS和无服务器通常被用作同义词,但从技术上讲,它们是不同的。FaaS只是无服务器开发模型的一个小子集。无服务器是一个非常广泛的类别,涵盖许多云计算类别,如存储、计算、消息传递、API网关等。
无服务器计算模型的最大优势在于客户只支付正在使用的计算资源,这是因为无服务器环境将根据传入请求的情况提供计算资源,并在没有请求时将其缩减到零。
什么是Knative?
Knative使您能够构建事件驱动、无服务器和云原生应用程序。Knative允许您在Kubernetes环境中构建无服务器容器。Knative是一个开源项目,目前由Cloud Native Computing Foundation(CNCF)运营。谷歌与IBM、红帽和其他几家公司合作开发了Knative。
Knative也属于无服务器的范畴。因此,与无服务器类似,使用Knative,开发人员无需担心底层基础设施和服务器,可以完全专注于应用程序代码。Knative应用程序可以部署到Kubernetes和OpenShift。
为什么使用Docker和Kubernetes?
像Docker这样的容器运行时和像Kubernetes这样的容器编排器现在已经成为容器化应用程序开发的基础。而微服务、容器和Kubernetes共同构成了云计算生态系统中不可或缺的部分。
所有这些技术相互补充。具体而言:使用微服务架构,您将将应用程序分解为较小的服务,这是必需的,以便整个应用程序松散耦合,一个服务的故障不会导致整个应用程序崩溃。然后,您将使用像Docker这样的容器运行时将每个服务作为容器运行,这是必需的,因为容器非常轻量级,因此可以快速扩展和缩减,以响应流量。接下来,您将使用像Kubernetes这样的容器编排器来管理和协调所有应用程序容器,这是为了为应用程序提供高可用性和容错性。所有这些应用程序容器将运行在物理机器上(很可能不太可能)或在云中运行的虚拟机器上。
比较关键容器技术
在本节中,我们将比较和对比关键的容器技术。
Docker的替代方案有哪些?
2013年引入的Docker引擎推广了容器化的概念,而根据一项调查,在2017年的某个时刻,Docker占据了99%的容器市场份额。然而,自那时以来,许多Docker的替代方案已经发展起来。以下是五个主要的Docker替代方案(未按任何特定顺序列出)。所有这五个替代方案均为开源。
- containerd
- runC
- Podman
- LXC(Linux Containers)
- Cloud Foundry
Podman采用了无守护进程的体系结构,比Docker更安全。LXC更适用于数据密集型应用和操作。
Kubernetes的替代方案有哪些?
截至2023年,Kubernetes无疑是最受欢迎的开源容器编排器。以下是一些替代Kubernetes的开源容器编排器:
- Docker Swarm
- Marathon
- Nomad
Docker Swarm是替代Kubernetes最流行的开源容器编排器,特别适用于已经使用Docker技术(如Docker Engine、Docker Compose、Docker Hub等)的应用程序。Marathon是一个由加利福尼亚大学伯克利分校为Mesosphere的DC/OS和Apache Mesos创建的开源容器编排平台。Nomad是HashiCorp创建的一个简单的容器编排平台。
几乎所有主要的云服务提供商都以Kubernetes为基础,创建了自己的托管Kubernetes服务。以下是基于付费订阅的托管Kubernetes服务:
- GCP提供Google Kubernetes Engine(GKE)。
- 微软Azure提供Azure Kubernetes Service(AKS)。
- 亚马逊提供Amazon Elastic Kubernetes Service(Amazon EKS)。
- Red Hat提供OpenShift Container Platform(OCP)。
Kubernetes和Docker之间有什么关系?
Docker是一个容器运行时,而Kubernetes是一个容器编排器,支持来自许多不同容器运行时的容器。Kubernetes支持大多数流行的容器运行时,如Docker、containerd等。 一个很好的类比是,就像在操作系统上运行应用程序一样,你在Kubernetes上运行容器;就像操作系统可以运行一个或多个应用程序一样,Kubernetes可以运行一个或多个容器;就像操作系统编排运行应用程序一样,Kubernetes编排运行容器。
将Docker和Kubernetes进行直接比较是错误的,因为它们不是竞争关系,而是互补关系。Docker和Kubernetes可以一起使用或分开使用;然而,它们彼此之间的协同作用非常明显。
如果你真的想要比较Docker技术和Kubernetes技术,那么最好比较Kubernetes和Docker Swarm,因为它们都是容器编排器。
Kubernetes和Docker Swarm有哪些不同之处?
Kubernetes和Docker Swarm都提供容器编排功能,但Kubernetes提供了更先进和全面的容器编排能力。Docker Swarm最大的优势在于其易用性和与其他Docker技术的集成,因此如果你的系统基于Docker技术构建,那么Docker Swarm更适合满足容器编排需求。
在可伸缩性和监控方面,Kubernetes提供更强大的功能。Kubernetes具有内置的水平扩展功能,而Docker Swarm没有。但在负载均衡方面,Docker Swarm提供了自动负载均衡,而Kubernetes没有。
从开发者和管理员的角度来看,Kubernetes的学习曲线要比Docker Swarm高得多。
Kubernetes与Red Hat OpenShift、Google Kubernetes Engine等有何不同?
Kubernetes是一项开源技术,而Red Hat的OpenShift、Google Cloud的GKE、Azure Cloud的AKS以及Amazon Cloud的EKS是托管服务。托管服务意味着客户支付其使用费用。
需要注意的一点是,诸如OpenShift、GKE、AKS和EKS等所有基于Kubernetes的托管服务都以Kubernetes内核为基础,然后在其上增强了Kubernetes体验,并提供了更多功能。这些托管Kubernetes服务的众多优势之一是它们提供了一个非常用户友好的图形用户界面(GUI)。
总结
在过去的几十年里,应用部署模型从传统的部署模型发展到虚拟化部署模型,再到容器化部署模型。虚拟化是一种技术,允许我们对计算资源(如服务器、网络、存储等)进行虚拟化,而超级监视器(hypervisor)是一种创建和运行虚拟机的软件。容器化是一种虚拟化形式,因为它们都允许对应用程序进行完全隔离,以便在多个环境中运行。
分布式设计,也称为分布式架构,是分布在多个计算节点上的计算系统组,共同实现共同目标。云计算是按需提供计算资源的方式,客户按使用量支付费用。微服务(或微服务架构)是一种云原生的架构方法,其中一个应用程序被分解为许多松散耦合且可以独立部署的服务。
虚拟化和分布式架构是云计算的推动者。而容器化和微服务架构是互补技术,结合使用时提供了一个非常具有成本效益、可扩展且容错的应用生态系统。
Docker是一个开源平台,允许你开发、运行和传输容器化应用程序。Kubernetes允许你以受监管和自动化的方式部署、扩展和管理容器化应用程序。简而言之,Kubernetes是一个容器编排器。OpenShift容器平台是由Red Hat提供的高度可扩展的Kubernetes平台,允许你开发和运行容器化应用程序。
有五个流行的Docker替代方案:containerd、runC、Podman、LXC和Cloud Foundry。还有三个流行的Kubernetes替代方案:Docker Swarm、Marathon和Nomad。
在下一章中,我们将深入研究Kubernetes的概念,了解Kubernetes的历史和架构。