适合在虚拟化环境中部署 Kubernetes 的三个场景

在《虚拟化 vs. 裸金属：K8s 部署环境架构与特性对比》文章中，我们从架构和特性的角度，对比了在虚拟化和裸金属环境部署 Kubernetes 的优劣势，并在文末列举了两者更适合的应用场景。本文，我们将聚焦以虚拟化环境支持 K8s 的适用场景，并针对其中 3 个典型场景展开深入讨论。

重点内容：

Gartner 等分析机构在报告中表示，虚拟化（以及超融合）作为一种非常成熟的技术，承载了大部分用户的 Kubernetes 集群和容器化应用。
得益于虚拟化技术在资源效率、弹性扩展和安全隔离方面的优势，以下三种场景非常适合基于虚拟化部署 Kubernetes：

a. 需要快速部署和灵活伸缩 Kubernetes 集群。

b. 需要为"多租户"提供各自的 Kubernetes 运行环境。

c. 需要在有限资源内同时支持虚拟化和容器化应用。
对于"高性能"需求的应用，用户应结合应用需求场景和部署条件，综合判断所需的基础架构，评估"理论性能"的同时，更关注"实际使用效率"。
文末可获取《IT 基础架构团队的 Kubernetes 管理：从入门到评估》电子书。

分析机构：以虚拟化支持 Kubernetes 成为多数用户选择

为了应对不断变化的市场需求和技术挑战，云原生应用已经成为了许多企业用户的首选解决方案。云原生是一种构建和运行应用的方法，它充分利用云计算的优势，提供高度可扩展、弹性和自动化的应用部署；而容器作为云原生的核心组件，为应用的打包、运行和管理提供了轻量级、高效的解决方案。云原生应用首选应通过容器化技术进行改造，并运行在容器中。

对于正迈向云原生的企业用户，他们的容器化应用最适合运行在哪种类型的 IT 基础设施上呢？得益于容器化技术实现了应用程序与底层硬件解耦，这些应用能够在多种环境中进行部署。Gartner 在 2023 年 5 月更新的《服务器虚拟化市场指导》中，总结了各类应用负载在服务器上的承载形态，包括：直接运行在物理服务器的 Host OS 上、运行在虚拟化服务器中的 Guest OS 上、运行在物理服务器的容器中、运行在虚拟化服务器的容器中，以及虚拟化和容器化的混合运行环境。

其中，虚拟化环境或虚拟化-容器化混合环境成为最多数用户的选择。Gartner 在《市场指导》里指出："......容器在虚拟机内部运行。到目前为止，这种模式在企业内部环境中已经成为容器部署的最常见模式。"虽然在私有云中的容器化部署呈增长趋势，但是 Gartner 分析师认为虚拟化与容器化将在较长时期内共存："尽管（向公有）云迁移的趋势和容器采用率不断提高，2027 年仍有 70% 的数据中心 x86 工作负载将继续使用基于 Hypervisor 的虚拟化（2020 年约 80%）"。

除了上述 Gartner 的分析，我们还可以参考来自 Juju 的《Kubernetes 和云原生运维报告 2022》。该报告汇集了来自全球范围内 1300 余位受访用户的数据，调查涉及混合云和多云环境的运维、Kubernetes、虚拟机、裸机等多方面内容。这份报告中的一项调查内容是："您在哪些环境中运行 Kubernetes 集群？"（这个问题允许多选，因为每个用户的 IT 系统中，都可能存在两种或两种以上的基础设施环境并存的情况。）通过对反馈数据的统计（见下图），我们可以看到：全球范围内有 58% 的受访者使用"公有云提供的 Kubernetes 环境"（见下方注释），毫无悬念地占据榜首；基于"私有云部署 Kubernetes"的受访者比例为 37%。如果对选择了"私有云部署"的调查结果（37%）进行细分，我们可以看到其中大部分（23%）是在私有云的虚拟机上部署 Kubernetes，而在裸金属服务器上部署 Kubernetes 的比例仅为 8%。

注：实际上，公有云上的 Kubernetes 服务绝大多数是部署在公有云的虚拟机（云主机）上。

以上 Gartner 的分析和 Juju 的调查数据表明，虚拟化作为一种非常成熟的技术，承载了大部分用户的 Kubernetes 集群和容器化应用。这一方面是因为虚拟化技术的广泛使用，另一方面还得益于，虚拟化环境能够在许多 Kubernetes 生产使用场景下发挥独特的优势。

下面，我们将结合具体场景，解读虚拟化，以及基于虚拟化的超融合架构，在资源效率、弹性扩展和安全隔离方面，为 Kubernetes 带来的价值。

图基于容器的云原生应用与基础环境解耦

基于虚拟化部署 Kubernetes 的适用场景分析

1. 需要快速部署和灵活伸缩 Kubernetes 集群

场景

在需要快速构建的 Kubernetes 集群时，虚拟化（包括传统虚拟化和超融合）作为基础设施是非常适用的方式。众所周知，虚拟机的创建和变更速度远远快过物理服务器。在以下这些场景中，"敏捷地构建 Kubernetes 集群"是最重要的需求：

1）在企业内部，出于试用、演示、测试目的，用户可能频繁地（以"周"或"月"为周期）创建和删除 Kubernetes 集群；

2）在集群使用过程中，可能频繁地（以"周"或"月"为周期）需要根据业务量的增长快速增加集群资源，在业务量降低时释放 Kubernetes 集群的资源以支持其他应用；

3）故障和灾难发生时，如果原有 Kubernetes 集群无法快速恢复，需要快速地（以"分钟"或"小时"为单位）搭建临时替代的集群，并在原有基础设施恢复后删除临时的集群。

难点

通常在物理服务器上部署 Kubernetes 集群所需的时间以"周"为单位；长期运维物理服务器上 Kubernetes 集群的熟练工程师，借助自动化工具，可以将这个时间单位缩短为"天"。尽管这对前两种场景来说尚可接受，但仍无法满足第三个场景的需求。此外，由于操作环节繁多且重复性高，有必要通过自动化和标准化提高操作效率和准确性，从而解放 IT 运维人员，使他们能够更专注于系统整体优化，实现更高质量的服务和交付。

在实际的企业 IT 环境中，不同品牌和型号的物理服务器在硬件配置、固件和 BIOS、远程管理工具、驱动程序和操作系统支持、网络和存储配置、硬件兼容性和供应商支持等方面存在差异。这可能导致自动化流程中需针对这些差异进行特定配置，从而削弱流程的自动化和标准化，延长物理服务器达到生产就绪状态所需的时间。

在物理服务器上启用基于 Type-1 Hypervisor 的虚拟化过程中，也需要针对这些差异进行特殊配置。然而，在 Hypervisor 部署完成后，虚拟服务器的创建、删除和变更就不再涉及这些因素，通常可以在数分钟内完成虚拟机的生命周期管理。因此，基于虚拟机快速创建、删除和变更 Kubernetes 集群，可以实现分钟级的敏捷性。

图：在物理服务器上安装 Kubernetes 的过程

对于以上场景 2）和场景 3），也有可供选择的其他方法：预先置备一些基于物理服务器的 Kubernetes 节点/集群，作为生产系统的热备份或冷备份；当有扩容需求或发生故障、灾难时，利用容器的可迁移特性，将业务迁移到预先准备好的备用节点/集群上------这确实是一部分用户在采用的方案。与基于虚拟机的动态Kubernetes 集群扩缩容和灾备方案相比，基于物理服务器的扩缩容和灾备方式将要求更高的成本，这是因为：备用 Kubernetes 节点/集群的主要配置（Kubernetes 版本、网络插件、存储插件、负载均衡插件、Ingress Controller 等）必须和主用集群一致，因此一组备用节点/集群资源只能专属于某一个特定的主用集群，这种特点在以下场景中会成为企业 IT 的负担：

如果用户有多个不同配置的主用 Kubernetes 集群，就要为每个主集群准备专用的备用节点/集群，不能共享备用资源，成本更高而资源利用率低；
为避免应用在主备 Kubernetes 集群间无法迁移的问题，需要对企业内部所有 Kubernetes 集群的配置进行统一。然而，这对基础架构和 Kubernetes 集群的运维提出了更高要求，可能导致难以对 Kubernetes 集群进行整体变更。这种情况下，一些需要个性化配置的新应用可能难以快速上线，从而削弱了云原生应用的敏捷性优势；
备用 Kubernetes 节点/集群资源在正常情况下只能闲置，不能用作其他业务的物理服务器或虚拟化服务器。

虚拟化环境的价值

以上三个不足，如果使用虚拟机作为 Kubernetes 的运行基础，就能很好地解决：

**多个备用集群：**可以在一套硬件设备上，通过虚拟化创建并维护多个不同配置的备用 Kubernetes 集群，以满足不同应用和工作负载的需求；
**动态资源分配和资源共享：**在没有承担临时扩容或灾备工作负载的情况下，多个备用虚拟化 Kubernetes 集群均可以保持较低的资源占用水平，此时有较多资源可以为其他虚拟化、容器化应用提供运行环境；可以随时对备用集群规模进行快速扩展以临时承载业务，并在业务回切到主用集群后对备用集群进行快速缩减，从而提高资源利用效率、减少闲置资源的浪费。

2. 需要为"多租户"提供各自的 Kubernetes 运行环境

场景

"多租户"就是指在一套基础架构资源池上，允许多个用户或者团队（我们统称之为"租户"）共享资源，但又互不干扰。

支持"多租户"为何如此重要？在企业内部，各个业务项目和部门可能采用不同的技术栈和应用架构，这要求 IT 基础架构管理员为他们提供定制化的 Kubernetes 集群。通过部署多个集群，可以针对各业务线的资源、性能、安全性和可用性需求提供合适的解决方案。例如：

针对不同业务项目和部门开发的各式容器化应用，可能需运行于具有不同环境参数、插件和服务的平台，以适应各种业务场景和技术需求。
来自不同第三方软件供应商（ISV）的容器化应用，可能需要在具有不同版本和网络配置的 Kubernetes 集群上运行。
企业内不同部门间需要保护敏感数据和应用，防止数据泄露，以及避免安全威胁在各部门应用之间横向传播。

图：不同"租户"的应用之间需要隔离

难点

在多租户场景下，要提供不同的 Kubernetes 集群并在它们之间实现隔离，以确保业务安全，不同使用者可能非常关注从内核层面和网络层面对 Kubernetes 集群上的应用进行隔离的方式和效果：

内核层面

Kubernetes 所管理的容器，是轻量级的虚拟化技术，它使用操作系统的内核功能（如 Linux 的 Cgroups 和 Namespaces）来为应用程序提供隔离。容器之间共享同一个内核，但每个容器都有自己的文件系统、网络栈和进程空间。这种隔离方式相对较弱，这使得潜在的安全风险更高。如果容器内的应用程序被攻击者成功入侵，攻击者可能更容易突破容器的隔离层，并影响其他容器或宿主系统。当然，通过配置安全策略和使用增强型隔离技术（如 SELinux 和 AppArmor），可以降低这种风险。这些容器安全技术和方法还在不断改进中，还不能消除使用者的种种顾虑；而且，部署更多新型容器安全技术，也就随之增加了容器运行环境和应用系统的复杂度。

与共享操作系统内核的容器化技术相比，虚拟机提供成熟的硬件级别的隔离，通过模拟硬件资源来为每个虚拟机实例提供完整的操作系统环境。这种严格的隔离有助于确保：一个虚拟机上容器出现的问题不会影响到其他虚拟机，一个 Kubernetes 集群上出现的问题，也不会扩散到其他 Kubernetes 集群。

网络层面

同一个 Kubernetes 集群中的所有容器通常使用同样的网络方案和地址空间，很难实现差异化配置。Kubernetes 原生的网络隔离方法只有网络策略（NetworkPolicy），这些策略的编写和维护的工作量非常大。如果采用为 Pod 配置多网卡并且混合使用多种 CNI 的方式，可能导致复杂性急剧增加，网络配置很容易出现问题或冲突，通常不推荐。

虚拟化集群上的虚拟网络技术可以使不同 Kubernetes 集群的网络完全隔离，并提供基于虚拟网络的路由、负载均衡和安全功能。对于网络和安全有差异化需求的不同应用，可以由构建在不同的虚拟网络上的不同 Kubernetes 集群进行承载，不会在同一个 Kubernetes 集群内部引入非常复杂的网络、服务和安全插件及相应配置。

虚拟化环境的价值

为满足这些安全隔离的需求，构建并维护多个基于虚拟机的 Kubernetes 集群成为一种非常合适的方法。将单一大型 Kubernetes 集群拆分成多个小型集群，除了可以满足上述内核层面和网络层面的隔离需求外，还具备以下优点和价值：

**更好的扩展性和弹性：**随着业务的发展，可能需要对集群进行扩展以满足不断增长的资源需求。部署多个 Kubernetes 集群可以更好地实现集群的弹性扩展和收缩，使 IT 基础架构管理员能够灵活地为不同的业务项目和部门分配资源；
**更低的总体成本：**可以节省硬件、能源和维护成本，从而降低整体的运营成本；
**更便于运维管理：**通过部署多个 Kubernetes 集群，IT 基础架构管理员可以更好地监控和管理每个集群的运行状况。这有助于及时发现潜在问题，确保应用的正常运行，并降低故障恢复时间。

由此可见，对于有"多租户"类型需求的企业用户来说，如果单个"租户"对资源的要求没有超出总体硬件资源的 50%，所有"租户"的资源需求峰值没有超出硬件资源的总和，那么基于虚拟化技术在同一组硬件设备上构建多个不同的 Kubernetes 集群就是一种更加可行、更加高效的方式。

注：有一种情况是例外：某些行业和应用场景可能需要遵循非常强力的合规要求，例如数据主权、数据保护等。在这种情况下，多种应用、多个部门之间即便通过虚拟机层面的隔离，也不符合行业特定的数据隔离和保护的要求，只有为每种应用创建基于独立硬件的运行环境，才能符合相应的合规要求。

3. 需要在有限资源内同时支持虚拟化和容器化应用

场景

由于各种现实条件的制约，很多企业用户必须在同一套硬件资源上同时支持虚拟化和容器化应用。比如：

由于预算有限，短期内无法添置新服务器硬件；
由于机房空间有限，无法容纳更多硬件；
由于最终使用者所处地理位置分散，需要将硬件分布在不同站点（下图）。

图：分支/边缘站点应用的混合部署、统一管理

难点

在这些场景中，可能不满足为虚拟化应用和容器化应用单独组建集群的硬件条件；或者由于分支/边缘站点上的虚拟化和容器化应用可能对资源总量需求并不高，单独分配硬件资源反而进一步加剧了资源闲置和管理复杂度的问题。

虚拟化环境的价值

在成熟的虚拟化平台上建设 Kubernetes 集群，实现虚拟化与容器化应用的混合部署，是应对以上场景的一种最佳方式。这种方式的优势和价值在于：

**虚拟化技术成熟：**基于 Type-1 Hypervisor 的虚拟化技术已经相当成熟，具有较好的性能、隔离性和安全性，几乎所有生产级应用都已经被证明可以部署在虚拟化环境中。
**完善的管理体系：**虚拟化平台具有完善的管理工具和软件，可以对异构集群、异地集群进行管理，而且很多企业用户已经有了丰富的虚拟化管理经验。
**良好的兼容性：**通过虚拟机提供的 GuestOS 可以完美地模拟硬件的运行环境，Kubernetes 集群运行在虚拟机里完全不必担心兼容问题。
**灵活的资源分配：**虚拟化技术可以更灵活地分配计算、内存和存储资源，并在共享资源的同时实现有效的隔离，有助于实现资源的最优利用。
**更高的资源效率：**虚拟化技术对资源的动态使用可以确保资源在多个不同用途的虚拟机之间更加均衡地分配，从而提高整体资源利用率。

关于虚拟化管理开销对容器应用性能的影响

当谈论在虚拟化环境中运行容器化应用时，我们必然会面临与虚拟化管理相关的开销问题。许多用户选择在物理服务器上运行 Kubernetes 和容器化应用，主要原因在于：基于 Hypervisor 的虚拟化方式在物理服务器上增加了一层额外的处理开销，他们担心这会降低容器的运行性能。

这种担忧并非完全没有依据，但具体的性能差异受多种因素影响，如虚拟化技术、资源分配策略以及应用程序类型。在实际应用场景中，我们需要根据具体需求和性能指标来权衡虚拟化带来的安全性、效率提升和性能损失。就像赛车与轿车的区别：F1 赛车只需要考虑在专业赛道内的速度和操控性，而家用 MPV 需要考虑舒适性、安全性、成本等因素，而将部分"性能"让步给"综合体验"；同时，实际的道路环境会出现交通管制和拥堵，这时赛车和轿车在实际到达时间上可能不会有很大差别。由于 MPV 可以同时搭载多个乘客和多种货物，其综合运输效率也会高于 F1 赛车。

因此，"高性能"容器化应用需要什么样的运行环境，应当放到特定的应用需求场景中进行讨论。如果应用具备以下特点，它就比较适合在专属的物理服务器环境下运行：

运行状态长时间恒定的应用，如果其资源消耗基线超过单台物理服务器资源的 50%，这种应用适合独享硬件资源的模式；
运行状态长时间恒定的应用，如果同时具备：不会出现性能突发导致的扩容、集群内部资源和机制可以满足灾难恢复的要求、版本更新间隔长（例如超过 6 个月甚至 1 年）这三个特点，那么这类应用在完成一次运行环境配置后，可以长时间保持不变，因此可能不需要虚拟化的便利性和灵活性；
运行状态随时间波动的应用，其峰值资源消耗超过单台物理服务器资源的 50%，可能难以通过虚拟化与其他应用共享资源------因为应用本身的资源消耗，再加上虚拟化管理机制对资源的消耗，可能导致调度机制复杂且频繁，将降低系统整体的稳定性和可靠性，抵消了虚拟化带来的资源利用率提升；
需要使用 GPU 资源的应用------虽然现在的技术允许将 GPU 直通给虚拟机上的 GuestOS，也可以通过 GPU 虚拟化技术将单个 GPU 硬件的能力在集群范围内共享，但对于要求很高处理性能的应用来说，这些方法"可能"仍无法满足需求。在这种情况下，有些用户认为物理服务器能更好地发挥 GPU 的性能。

在常见的应用中，以下这些应用通常会消耗大量资源：

**高性能计算 (HPC) 应用：**这些应用通常需要执行大量的计算任务，例如天气预报、量子力学模拟、生物信息学分析等。为了确保计算速度和准确性，HPC 应用通常需要独占大量服务器资源。
**大数据处理和分析：**大数据应用，需要处理和分析大量数据。这些应用通常需要大量的内存和计算资源来实现高效的数据处理。
**机器学习和深度学习：**训练大型机器学习和深度学习模型通常需要大量的计算资源，特别是使用 GPU 进行加速计算时。这些应用可能需要独占多个物理服务器以达到所需的计算能力。
**实时流处理：**实时流处理应用，需要实时处理大量数据流。这些应用通常需要大量的计算、内存和 I/O 资源来保证低延迟和高吞吐量。
**在线游戏和虚拟现实：**大型多人在线游戏和虚拟现实应用需要高性能的计算、内存和网络资源，以保证游戏的流畅性和实时性。这可能导致它们需要独占大量物理服务器资源。

以上只是从应用"类型"角度进行的分析，并不意味每个企业一旦要使用这些类型的应用，就必须部署在物理服务器上。具体资源消耗，与该种应用在特定企业运行环境下处理的数据量有关。

总结

我们列举并分析了三种在虚拟化环境中运行 Kubernetes 的场景，每个场景都可以同时获益于虚拟化技术带来的资源效率、弹性扩缩和安全隔离能力。

**资源效率：**多个应用所需的虚拟机和容器可以在同一组物理服务器上运行，共享硬件资源。这不仅降低了硬件成本，还减少了能源消耗和维护成本。采用成熟的虚拟化资源调度策略，可以对虚拟机的资源分配进行动态调整，实现资源负载在多台物理服务器上的平衡分布。
**弹性扩缩：**虚拟化技术能够根据业务需求快速创建、删除和移动虚拟机，实现敏捷的扩缩容。无论是虚拟化应用还是容器应用，在面临业务量突增、故障或灾难时，都可以通过虚拟化管理器将业务扩展到备用资源池。在业务高峰期、故障或灾难过后，系统可以自动缩容以回收资源。这些资源可作为多种应用的共享缓冲资源，提供更大的灵活性。
**安全隔离：**虚拟化技术可以在同一台物理服务器上创建多个独立的虚拟机，每个虚拟机都拥有自己的操作系统和应用程序。这样可以从内核级别确保安全威胁不会扩散、数据不会被越权访问。不同应用可以部署在由虚拟化网络技术构建的、彼此隔离的网络空间内，从而简化网络拓扑并防止安全威胁通过网络横向扩散。

想了解更多关于 Kubernetes 平台的管理运维知识，您可扫描下方二维码，一键获取电子书**《IT 基础架构团队的 Kubernetes 管理：从入门到评估》**。

为了帮助更多用户在虚拟化环境中构建安全、可靠、高性能的 Kubernetes 集群，SmartX 也正式发布了生产级 Kubernetes 构建与管理服务产品 SKS。通过预集成 Kubernetes 常用软件，并整合业界领先的 SmartX 超融合产品组件（虚拟化、分布式存储、网络与安全等），SKS 可帮助企业 IT 运维团队轻松部署和管理生产级 Kubernetes 集群，构建可同时承载虚拟化和容器应用的完整企业云基础架构。欲了解方案详情，请阅读：SmartX 发布 SKS 1.0 ，一站式构建生产级 K8s 集群。