Kubernetes - 基础架构的未来

Kubernetes - 基础架构的未来

Kubernetes 如何实现现代化微服务架构

下一代应用程序开发

从仅靠裸机硬件来支持应用程序开发至今,IT 基础架构领域已发生了巨大的变化。在2000年代初期,一家名为 VMWare 的公司打破了常规,它们制作了外观和行为都类似于硬件的软件层抽象(虚拟机)。虚拟机和裸机之间的主要差别是虚拟机可以使用虚拟化出基础架构。虚拟化功能增加了灵活性、可伸缩性、可靠性、性能以及总体容量,同时降低了资金和运营成本。

近年来,云计算和大数据的融合引爆了另一项改进技术,以提供更大的灵活性和便利性,即采用容器来促进软件开发和微服务的扩展。

容器是一种更有效的打包软件的方式,包括软件运行时所需的所有元素,例如代码、运行时环境、系统工具、系统库和设置。

有了容器,各种活动组件和基础架构之间的依赖关系变得没有那么复杂和明显,从而使开发人员能够在相同的开发环境和技术栈中协同工作开发。

Kubernetes1.png

类似虚拟机,但是更强大

虚拟机的兴起与容器的兴起之间有很多相似之处。在虚拟机出现之前,我们想要扩展基础架构以支持软件开发需要,必须购买更多服务器,并对其进行物理扩展,这是一个非常消耗资源的过程,并且成本很高,而且还要保持性能和可用性。但是虚拟机的出现改变了一切,我们可以更轻松地扩展规模,而无需找硬件供应商购买服务器。我们可以增加现有硬件的利用效率,在现有基础架构上扩展成千上万的虚拟机。同样的,容器技术也做着同样的事情,它充分利用现有硬件的每一寸资源,并且规模更大。

使用容器有很多好处,首先,由于 DevOps 团队采用了更有效的软件开发方法,使每个团队成员都受益匪浅。容器通过减少资源浪费,使得工程团队更加敏捷化,团队间可以在微服务的框架下更快地构建和分享代码。更重要的是,容器化通过轻量化和资源高效来提高扩展性。开发效率和速度提高,加上高可扩展性,导致开发时间充裕,成本降低。

容器具有高度的灵活性好可扩展性,有了容器,我们可以在每个虚拟机上启动更多进程来增加虚拟机效率。由于容器之间是隔离的,因此我们可以在容器内容运行各种类型的工作负载,从而确保每个工作负载免受其他容器打扰,容器之间不会相互影响。

易于使用是容器的另一个优势,类似于虚拟机相较于物理硬件更易于创建、扩展和管理,容器相较于虚拟机也更加简单,启动一个容器在几秒内就可以完成。运行虚拟机后,启动一系列繁重进程的日子已经一去不复返了,现在,容器为我们提供了在现有虚拟机上运行轻量级、进程间隔离服务的豪华体验。这使我们能够轻松地扩展规模,而不会陷入繁重的 DevOps 工作。

下一个领域:容器编排

随着容器技术爆炸式增长,容器编排技术也随之迅速增长。与当初 VMWare 公司提供了一整套工具来启动、创建、销毁和监控虚拟机一样,容器也需要进行监控和协调来确保其下的服务是正常工作的。

容器编排技术使开发人员可以更好跟踪、安排和运行大规模容器。如果我们想在多个服务器和虚拟机上运行多个容器,需要大量的 DevOps 资源来帮助实现这个目标。

这么多移动组件需要我们回答好几个问题,例如如何启动正确的容器,如何确保容器彼此间可以正常通信,存储注意事项是什么,以及如何确保我们基础架构的高可用性,难怪我们需要引入容器编排这个概念。幸运的是,已经有工具专门解决这些问题,消除了在底层虚拟机上协调容器执行的复杂性,例如 AWS 提供的 EC2 实例。我们不必担心基础架构问题,例如我们的程序运行在什么物理硬件上。

同样,容器编排工具使我们在启动新容器时,不必担心哪台底层虚拟机会负载工作量。例如 Kubernetes 这样的容器编排工具会做类似的事情,它会计算虚拟机是否利用充分,然而决定在哪台虚拟机上运行容器。

Kubernetes:现代应用程序的现代基础架构

正如 The New Stack 最新调查数据表明,容器的使用对容器编排起到了很大的催化作用。实际上,在生产环境部署使用容器的用户中,有60%表示它们使用了 Kubernetes 进行容器编排,另有 19% 受访者表示正在使用 Kubernetes 的初级阶段。

那么 Kubernetes 到底是什么?Google 于2014年创立了 Kubernetes 这样一个开源项目,致力于构建健壮的容器编排系统,以在生产环境中运行数千个容器,通过流程自动化,Kubernetes 可以消除许多繁重的手动任务和基础架构复杂性,帮助部署、扩展和管理容器化应用程序,而之前,这些都是由 DevOps 团队来做的。

Kubernetes 使我们不仅可以轻松地运行容器,而且还可以在容器中运行不同类型的负载。Kubernetes 真正兴起的原因是它能理解用户在运行一个系统,而不仅仅只是运行一个容器。并非每个容器都一样,容器可以是Web应用,也可以是数据库。

Kubernetes2.png

Kubernetes 解决的常见问题包括:

  • 我们如何设计一个可以包含许多活动组件的应用程序,但是却可以轻松编排和部署
  • 我们如何设计一个可以从一个云平台迁移到另一个云平台的应用程序
  • 我们如何使用一个数据库实例,与多个应用实例保持一致
  • 我们如何确保负载在多个容器中均匀分布
  • 我们如何复用我们现有的技术栈,从而快速地设计和开发应用程序

尽管 Kubernetes 已经成为了事实上的容器编排系统标准,但人们对它仍存在一些误解,首先,很多人最初不了解 Docker 和 Kubernetes 之间的区别。简而言之,Docker 用于创建容器,Kubernetes 提供了对这些 Docker 容器的管理。另外一个误解是,Kubernetes 并不是一个平台服务(PaaS),虽然我们可以将它开发成一个 PaaS 平台。

Kubernetes 如何完成工作

在 Kubernetes 中,每个节点在虚拟化环境或物理机中运行一个 Docker 引擎和多个服务。节点有两种类型:主节点(用于给定器群的控制器)和工作节点(用于运行以容器为单位的服务)。

在工作节点中,我们有一个 点(Pod) 的概念,它表示部署在同一个主机上的工作单元或容器集合。通常情况下,我们将在 pod 内运行单个容器或服务,但是,在某些情况下,某些容器内的服务耦合的比较紧密,可以在一个 pod 内启动多个容器。

然后,Kubernetes 将 pod 连接到用户的环境,并且统一管理,其中包括扩展、滚动部署和监控,pod 有自己的 IP 地址,这意味着应用程序可以通过 Kubernetes 的服务发现轻松找到我们的服务。

接下来是 服务(Service) 的概念,服务将具有相同功能的 pod 集合合并成一个整体。当创建服务时,集群的所有节点都会知晓这个新服务,这里要做的是创建一个单一的入口,可以与一组 pod 进行通信。服务的部署简化了容器设计,并使用户更容易发现容器。

标签(Label) 是一种组织概念,它可以为 Kubernetes 资源创建元数据标签,便于之后搜索,开发人员可以轻松地根据标签进行查询。由于 Kubernetes 中的许多功能都依赖于查询集群中的资源,所以标签功能对确保开发人员效率至关重要,标签是服务和副本控制器的基础。

卷(Volume) 代表容器可以访问和存储信息的位置,对于应用程序来说,卷显示为本地文件系统的一部分。卷还可能是本地存储、Ceph、Gluster、Elastic Block Storage 等其他后端存储实现。

命名空间(Namespace) 是 Kubernetes 内部的分组机制。服务、容器、副本控制器和卷在命名空间内可以协同工作,但是命名空间提供了集群之间的隔离性。

副本控制器(Replication Controller) 用于维护容器副本数量,使其易于扩展。如果某个容器发生故障,副本控制器将启动另一个容器,以确保始终有固定数量的可用容器副本。

容器编排全景

还有几个工具也提供了容器编排功能,与 Kubernetes 竞争最激烈的是 Docker Swarm 和 Mesosphere DC / OS。Docker Swarm 上手比较简单,Kubernetes 与之相比部署和管理方面都非常复杂。

Mesosphere DC / OS 是为大数据设计的容器编排工具,它旨在与其他工作负载(例如机器学习和大数据)且同运行容器,并提供与其相关工具(例如 Apache Spark 和 Apache Cassandra)的集成。

总体而言,Kubernetes 是目前这三个之中最成熟,也是最受欢迎的,社区贡献者数量多,企业采用率高。它们成功的关键在于它们不仅可以提供启动容器和监控这些容器的能力,并且还专注与在平台之上创建不同类型的容器组,以解决不同类型的高级工作负载。

例如,在 Kubernetes 中,我们可以找到系统的原生对象和实体,这些可以帮助我们启动一个守护程序、启动容器,或者启动数据库。对于其他解决方案,运行的容器间没有任何差别,在任何时间都可以销毁。

Kubernetes 如何改变微服务架构

微服务框架对当今企业中 IT 解决方案开发的影响显而易见。从较高的层次看,微服务允许将应用程序设计为较小的独立服务,而这些服务不依赖特定的编程语言。这意味着,当我们构建单体应用时,微服务架构允许工程组织将应用程序分解为互不依赖的各种组件,然后将这些组件组合在一起,提供类似单体应用程序的全部功能。

这些组件或微服务通过 API 相互通信,由于它不依赖编程语言,因此多个团队间可以跨语言构建各种组件,而不存在兼容性问题,例如,我们可以让一个团队在 Ruby 环境中运行微服务,另一个团队在 Python 环境中运行微服务,两者使用 Kubernetes 相互通信。

当我们使用微服务架构时,弄清楚如何监控不同服务也很重要。这就是 Kubernetes 及其不断发展的工具生态系统应用的场景,Kubernetes 为组织提供了更多的过渡方案,从虚拟机到容器。因此当我们使用 Kubernetes 时是开箱即用的,很多监控工具,CI/CD 工具还有很多平台都原生支持了 Kubernetes。

因此,使用 Kubernetes 的决定并不仅仅是基于使用哪种容器编排工具来促进微服务策略,而是在考虑整个工具生态系统。Kubernetes 生态系统为我们提供了一整套模块,为我们打造坚如磐石的基于容器的微服务架构。

光明的未来

容器正在迅速包围软件开发的世界,Kubernetes 作为未来的基础架构,势头也不会放缓,通过其深厚的专业知识,企业采用率和强大的生态系统,它已成为容器编排工具的首选。随着越来越多的贡献者个 IT 服务供应商支持该框架,Kubernetes 将继续改进和扩展其功能、支持更过的应用程序类型,并与其他生态系统集成。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,753评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,668评论 3 396
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 166,090评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 59,010评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 68,054评论 6 395
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,806评论 1 308
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,484评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,380评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,873评论 1 319
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 38,021评论 3 338
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,158评论 1 352
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,838评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,499评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,044评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,159评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,449评论 3 374
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,136评论 2 356