浙江质监站网址,查企业免费查询,手机常用网站,大连网站建设收费在《虚拟化 vs. 裸金属#xff1a;K8s 部署环境架构与特性对比》文章中#xff0c;我们从架构和特性的角度#xff0c;对比了在虚拟化和裸金属环境部署 Kubernetes 的优劣势#xff0c;并在文末列举了两者更适合的应用场景。本文#xff0c;我们将聚焦以虚拟化环境支持 K8…在《虚拟化 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 集群。
