Key Tech Terms for the Digital Landscape

什么是容器、Kubernetes 和云原生技术?

“云原生”的具体含义是什么?

随着企业组织纷纷开展大型数字化转型项目,追求更高的业务敏捷性、扩展性和效率,“云原生”这一术语随处可见,被用于各种场合。

但它的真正含义是什么?简而言之,“云原生”指的是一种新的软件抽象程度,外加一套专用技术、工具和流程,改变了应用的构建、部署和管理方式。

云原生应用的核心特征包括:

  1. 代码被打包成容器
  2. 架构为微服务的集合
  3. 开发人员和 IT 运维团队以紧密融合的敏捷方式协同合作
  4. 在富有弹性的云基础架构上进行部署和管理
  5. 自动化的、策略驱动的基础架构资源分配

云原生为企业带来的好处

踏上云原生之路的企业正在采用容器和 Kubernetes,以及广泛的云原生生态系统中的各种开源技术和商用技术。

容器和云原生技术使企业能够加速应用开发,无中断地升级应用,有效地扩展应用,并在不同的环境中轻松移植。有了这些能力,最终企业将获得更高的业务敏捷性并提升竞争优势。

容器帮助企业解决了一些关键问题。容器可以在任何地方运行,为开发人员提供强大的软件包,在一个供应商中立的数据包中提供服务升级、可扩展性、可用性和资源效率。Kubernetes 提供了一个基础架构层,IT 部门能够以程序化、可重复的方式进行规模化操作,而不是比较典型的手动管理方式。由于 Kubernetes 可以部署在本地和公有云上,提供了一个跨环境的通用操作模型。对于同时在本地和公有云上运行的企业而言,这使得 Kubernetes 成为他们的理想平台。

云原生架构

云原生架构使用容器和 Kubernetes 来构建应用,将其作为一组较小的、可组合的片段,可以有效地扩展,无中断地升级,并可以无缝迁移到其他环境。这种技术具有成本效益,安全性高,支持灵活的自动化。

本地 Kubernetes 堆栈

让我们了解一下本地 Kubernetes 堆栈的不同层次,从托管 Kubernetes 的基础架构,到运行在 Kubernetes 上的服务——开发人员可以利用这些服务来加速应用交付。请注意,一些组件可以包含在堆栈的多个部分。例如,一个 Kubernetes 发行版可能包括一个容器注册表,如 Harbor 或 Quay。另外,容器注册表也可以作为托管或管理服务提供,以便与任何发行版一起使用。

计算平台

Kubernetes 在部署位置上非常灵活,各种创新技术为 Kubernetes 提供了越来越多的操作方式和位置选择。通常情况下,Kubernetes 需要至少 3 个节点,它们之间有完整的网络连接,并连接有存储。目前,最常见的情况是 Kubernetes 在 VMware 等虚拟基础架构上运行。裸机和超融合基础架构是另外两种常见的选择。

借助额外的功能,置备和操作 Kubernetes 集群变得更加容易。通过由 API(如 Cluster API、Terraform 等)控制的基础架构,很容易置备和连接新的节点。自定义虚拟化管理程序可以提供工作负载隔离,修补容器的安全漏洞。Kubernetes 集群外的负载平衡器发挥了很重要的作用,有助于提供可用的工作负载,并动态地重新定位和扩展这些工作负载。定制硬件(如 GPU 或 TPU)可能会有利于一些工作负载。如果许多集群要在多个地点运行(例如在零售店),那么底层基础架构的分布式管理能力将非常关键。

Kubernetes 发行版

自 2015 年发布以来,Kubernetes 实现了爆炸性增长,科技巨头和初创公司一共开发了 100 多个 Kubernetes 发行版和托管平台。为了创建发行版,这些公司将 Kubernetes 的核心代码与其他项目相结合,如网络堆栈、集群管理工具、日志、监控等。

容器服务

对于一个有用的 Kubernetes 环境,除了 Kubernetes 本身之外,还需要包含其他基础架构服务。这些服务有时与发行版捆绑在一起,或者作为单独的服务附加在内,其中包括一些基本的服务,如容器注册表、Ingress、负载平衡器、Secret Store、证书管理器等等。

随着越来越多的公司在 Kubernetes 上构建和部署应用,他们依赖的许多核心服务通常也在 Kubernetes 中运行。例如,数据库(如 Redis、Postgres)、Pub Sub(Kafka)、索引(ElasticSearch)、CI/CD 服务(Gitlab、Jenkins)和存储(Portworx、MayaData、Minio、Red Hat)。

许多公司已经开发了相应的产品,用于管理或支持这些在客户选择的 Kubernetes 发行版上运行的应用。其中最知名的可能是微软的 Azure Arc 数据服务,它在客户环境中提供 Postgres 和 MS SQL 托管服务,但也有许多其他公司,包括 Confluent for Kafka、Crunchy Data for Postgres、Redis Enterprise for Redis、Percona、Elasticsearch、Minio、Mayadata,等等。

容器

容器是云原生软件的基本组成单元。容器由一段代码及其所有依赖项(二进制文件、库等)打包而成,并作为一个孤立的进程运行。由此形成了一个新的抽象层次。就像虚拟机 (VM) 从底层硬件中抽象出计算资源一样,容器从底层操作系统(OS) 中抽象出一个应用。

容器在几个重要方面与虚拟机不同。容器在资源占用方面小得多,启动速度快,而且更容易在云环境中移植。与虚拟机不同,容器在本质上是短暂的。

容器为微服务软件架构铺平了道路。传统的应用在本质上是一个整体,而基于微服务的应用是一些较小的、可组合的片段(服务)的集合,可以独立扩展并支持无中断升级。一个服务由一个或多个容器组成,执行一个共同的功能。

基于容器/微服务的应用有助于简化并加速软件开发过程,需要开发人员和 IT 运维团队之间进行更紧密的整合和协调,这一理念被称为“开发运维一体化”(DevOps)。

Virtual Machines (VMs) vs containers

图 1:虚拟机和容器的比较

Kubernetes

由于容器化应用适合于分布式环境,并且使用计算、存储和网络资源的方式与传统应用不同,它们需要一个专门用于协调容器化工作负载的基础架构层。

Kubernetes 已经成为主流的容器编排器,并经常被称为面向云的操作系统。它是一个可移植、可扩展的开源平台,用于管理容器化的工作负载和服务,有助于实现声明性配置和自动化。

具体来说,Kubernetes 可以:

  • 将容器分配给机器(调度)

  • 通过容器运行时启动指定的容器

  • 处理升级、回滚和系统的不断变化

  • 应对故障(容器崩溃等)

  • 创建集群资源,如服务发现、VM 间网络、集群入口/出口等

Kubernetes 是为可扩展性、可用性、安全性和可移植性而设计的。它优化了基础架构的成本,将工作负载分配到可用资源上。Kubernetes 集群的每个组件也可以针对高可用性进行配置。

Kubernetes 拥有活跃的全球社区,得益于社区成员的不断贡献,Kubernetes 迅速发展,现在有各种 Kubernetes 发行版可供用户使用。虽然最好是使用经 CNCF 认证的发行版(一致性有助于实现互操作性),但围绕 Kubernetes 生命周期管理功能的智能自动化,加上存储、网络、安全和监控功能的轻松集成,对于生产级云原生环境至关重要。

选择“云原生”的挑战

云原生技术为商业敏捷性和创新提供了新的动力,但配置、部署和管理它们对任何类型的企业来说都是一项挑战。首先,Kubernetes 及其云原生技术的生态系统非常深入,而且发展迅速。此外,传统基础架构不是为 Kubernetes 和容器使用 IT 资源的方式而设计的。这对软件开发人员来说是一个很大的障碍,他们往往需要按需提供资源,同时为他们的云原生应用提供易于使用的服务。最后,每个组织最终都会混合使用基于本地和基于公有云的 Kubernetes 环境,但能否从多云的灵活性中获益,取决于能否有效管理和监控所有的部署。

云原生最佳实践

在数据中心构建企业级 Kubernetes 堆栈是 IT 运维团队的一项重要工作。在基础架构上运行 Kubernetes 和容器化应用非常关键,这些基础架构要有弹性,并能响应性地进行扩展,以支持动态的分布式系统。

Nutanix 超融合基础架构 (HCI) 为在 Kubernetes 上大规模运行云原生工作负载提供了理想的基础架构基础。Nutanix 为 Kubernetes 平台组件和应用数据提供了更好的弹性,并且可扩展性要优于裸机基础架构。Nutanix 还简化了基础架构生命周期管理和有状态容器的持久性存储,消除了企业在部署和管理云原生基础架构时面临的一些最艰巨的挑战。

相关产品和解决方案

Nutanix Kubernetes 引擎

快速部署生产就绪的 Kubernetes 并简化生命周期管理。

面向 Kubernetes 的 HCI

Nutanix HCI 是 Kubernetes 和云原生应用的理想基础架构。

云原生应用的持久性存储

Nutanix 数据服务和 CSI 助您轻松 Kubernetes 中配置和管理永久存储。

查阅我们的热门资源

Nutanix 产品试用

试用 Nutanix Kubernetes 引擎

通过 Red-Hat 和 Nutanix 构建一流的混合多云堆栈

立刻开启超融合基础架构 (HCI) 之旅

即刻开始体验 Nutanix