《SmartX：2024年IT基础架构团队的Kubernetes管理-从入门到评估报告（55页）.pdf》由会员分享，可在线阅读，更多相关《SmartX：2024年IT基础架构团队的Kubernetes管理-从入门到评估报告（55页）.pdf（55页珍藏版）》请在本站上搜索。 1、IT 基础架构团队的Kubernetes 管理概念从到评估越来越多的企业开始采围绕 Kubernetes 的云原开发式。通常，Kubernetes 的部署运维主要由开发团队或平台团队负责完成，基础架构团队仅负责提供服务器、络和存储等设备和持。不过，不少企业发现，由于 Kubernetes 与承载的应之间完全解耦的特性，它常适合作为种 Infrastructure as a Service(IaaS)，既可以在公有云上提供，也可以在企业私有云上作为新代的基础架构，为现代化应提供可靠的基础设施。因此，伴随着这种定位的转变，Kubernetes 的建设和运维也将更多地交由基础架构团队负责。对于 IT2、 基础架构团队，接管 Kubernetes 平台的管理运维，疑是项不的挑战。为此，我们将为您提供接管 Kubernetes 平台所需的核信息，如选型评估要点、部署运维建议、基于虚拟化还是裸属部署等等。2024 年 1 更新录基础架构团队为何要接管 Kubernetes 部署运维？基础架构团队接管 Kubernetes 部署运维的可性如何选择 Kubernetes 管理平台？如何部署运维 Kubernetes？来 Gartner 的建议Kubernetes 部署，选择虚拟化还是裸属？适合在虚拟化环境中部署 Kubernetes 的三个场景虚拟化 vs.裸属：持 Kubernetes 性能对测试资3、源推荐基础架构团队为何要接管 Kubernetes 部署运维？K8s 部署运维占了开发员量的时间精作为现代化应的载体，容器和 Kubernetes 最开始被认为是“新型 Platform as a Service(PaaS)平台的基础”，由开发团队或平台团队负责规划和建设，包括预热期的学习、调研、技术储备、试环境搭建及维护、制定技术体系、法及具组合（包括针对裸属的具软件）。然，作为种新兴的技术，Kubernetes 学习成本较，部分开发员除了进前期的规划，还需要在使 Kubernetes 进应开发的同时，承担 Kubernetes 集群的基础管理和维护作，例如多次、重复搭建相似的 Kubern4、etes 集群：使 kubeadm 初始化集群。在服务器上安装操作系统并连接到交换机。在服务器上安装最新版本的容器运时。在服务器上安装 kubeadm、kubelet、kubectl。安装和配置络插件 CNI。这些步骤完成后，只是部署了个 Kubernetes 节点，要使之成为集群，还需要：设置节点为管理节点。创建其他 Kubernetes 节点。将其他节点加集群，设置为管理节点或作节点。验证所有节点是否正常运。配置安全访问。配置容器存储。这种常运维不仅会占开发员量的时间精，还会拖延新应的开发和上线速度，与企业选择使 Kubernetes 以加快开发速度、提服务效率的初衷相违背。由于基础架构团5、队拥有从硬件设施到操作系统的全套技能和经验，在上述过程中可以优化部署流程、引批量配置脚本，快速完成从硬件安装、连接到部署 Kubernetes 环境的全过程，且这个过程还可以不断复制，不断提部署的效率和质量。基础架构团队接管具有天然优势Gartner 在CTOs Guide to Containers and Kubernetes Answering the Top 10 FAQs报告中，建议企业将 Kubernetes 部署运维等作移交给其他团队，帮助开发团队专注于软件开发作。具体职责与作内容包括：团队职责作内容软件开发开发员编程、软件设计、实现与测试源代码管理平台平台程与运营确定平台具平台6、安装、配置和管理动化容器基础设施供应维护基本映像DevOps 流线和常运维操作动化的集成为开发员启助服务功能容量规划、作负载隔离可靠性程（如站点可靠性程师）有关平台和应程序的安全性、监控和性能应弹性（resiliency）调试与记录产问题事件管理与响应搭建与发布程选择与管理 CI/CD 部署流程开发模板以快速构建新的服务和功能指导开发团队量化流程效率和开发员产，并创建可视化界基础架构团队为何要接管 Kubernetes 部署运维？不难看出，Gartner 在“平台团队”中列举的部分职责，与传统基础架构团队负责的基本致。且由于基础架构程师习惯于同时监控、保障多个应/系统/环境，综合管理能更强，在7、运维 Kubernetes 平台时具备天然的优势。同时，基础架构程师可以灵活利专业知识，例如在与络和存储设施的对接，进步发挥 Kubernetes 作为 IaaS 的优势。根据 Juju 2022 年发布的Kubernetes and Cloud Native Operations Report，近半的企业在使 Kubernetes 和容器时遭遇了技术员短缺的问题，也有些企业反映了企业 IT 结构、与原系统不兼容、络和存储要求未得到解决、常运维效率较低等问题。将基础架构团队引 Kubernetes 运维管理，或许可以从更多度优化 Kubernetes 和企业整体 IT 系统。基础架构团队为何要8、接管 Kubernetes 部署运维？基础架构团队接管 Kubernetes 部署运维的可性挑战：Kubernetes 部署运维与传统基础架构的不同之处由于缺乏容器与 Kubernetes 相关技术知识，以及 Kubernetes 身操作需要学习等原因，基础架构团队经常被误认为难以主导 Kubernetes 的运维管理。CNCF 的篇博客How to Overcome the Day 2 Kubernetes Skills Gap列举了 Kubernetes 部署运维与传统基础架构的些不同之处：在配置存储资源的时候，运维员不仅需要理解“persistent volumes”和“persiste9、nt volume claims”等 Kubernetes 特有的概念，还需要清楚地知道 Kubernetes 如何连接和编排存储。在络层，运维员需要理解 DNS 如何在 Kubernetes 集群中运，以及如何使 CNI 将集群与中央络连接起来。此外，了解络策略如何运作、他们对于安全和架构弹性（resiliency）的影响，以及企业需要使哪种络，也常重要。在安全，运维员需要保证容器镜像没有弱点，保证配置尽可能安全，并防以 root 权限运应程序。且，原 Kubernetes 只持命令模式（Kubectl），虽然开发员使起来效率较，但对于更熟悉图形界，且需要效监控、管理多个环境的运维员来说，全10、盘接 Kubernetes 的部署和运维将意味着更加繁重的作量。机会：借助管理具，掌握基础 Kubernetes 知识即可快速上随着云原技术的不断成熟，市上出现了很多可以辅助基础架构程师，对 Kubernetes 进运维管理的商 Kubernetes 管理软件/平台。这些软件/平台为运维员提供了丰富的管理具（如安全、监控和存储的集成）、简单易操作的运维系统、图形化界，以及对多种运维环境的全管理持，运维员仅需掌握基本的容器/Kubernetes 知识，即可快速上 Kubernetes 运维管理等作。具体优势和价值包括：Kubernetes 集群命周期的动化管理：动化完成 Kubernetes 集11、群创建、删除、更新、扩缩容等原本流程繁琐的重复性操作，提升整体运维效率。插件的统管理：持多种插件扩展 Kubernetes 功能服务，满企业特殊需求。平台数据的可视化展示：Kubernetes 集群的监控指标将被实时采集，通过统的可视化界集中展示监控、告警、志管理、分析等功能，便于运维员监控和管理。不同环境的致性（consistency）持：统 Kubernetes 集群的配置和软硬件部署，以持集群在不同环境下的分发、扩容和升级。更多级服务：些软件/平台还提供些级服务，如性能持久化存储和络安全服务，进步提升基础架构的可靠性。正是基于 Kubernetes 管理软件/平台，前有越来越多的基础架构12、团队在掌握容器与 Kubernetes 相关知识和能后，开始负责 Kubernetes 的运维管理，将 Kubernetes 与物理环境、虚拟化环境进统规划和管理，满企业快速发展的需求。点击链接，阅读原：接管 K8s 部署运维，基础架构团队是否做好准备？基础架构团队接管 Kubernetes 部署运维的可性如何选择 Kubernetes 管理平台？Kubernetes 运维管理有哪些挑战？虽然 Kubernetes 对资源扩展和应程序的部署、管理、监控、迁移、恢复等的持，已经降低了容器管理的复杂度，但采 DIY 的式搭建和运维 Kubernetes 依旧具有挑战性。1.动管理集群命周期费时费户13、在使 Kubernetes 时可能需要频繁扩展/删除集群，这不仅要求户熟知节点、Pod 等相关概念和作原理，还需要执系列步骤来调整和配置节点。这个过程劳神费，且旦出现配置错误，可能会导致服务不可，徒增运维负担。且，随着集群规模的逐渐扩展，想要动操作每个集群完成 Kubernetes 版本或安全更新，并保证升级过程不会影响业务效稳定运，也不是件容易的事情。Kubernetes 更新速度快，每 4 个就会发布个新版本（次版本），每 1 个会发布个新的补丁版本（若遇到严重 bug，更新节奏会更快）。同时，Kubernetes 社区仅为最新的三个版本提供 1 年的维护持（1.18 及更早的版本持时为 14、9 个），这就要求户尽量保持产环境的版本在社区维护范围内，以及时弥补漏洞并获取最新的功能特性。这系列持续、频繁的升级操作，若没有动化具辅助，将耗费运维员量时间和精，也很容易出错。2.可视化具集成程度低，不便于监控集群整体健康状态Kubernetes 优秀的容器编排能提了集群的可扩展性和应在多环境间的可移植性，但同时也使得应间的关系和资源开销变得更加复杂。为了更好地监测应和基础设施的运状态、对集群进跨平台管理，运维员需要实时、准确地了解从基础架构到应组件间各层级的数据流和资源使情况。虽然 Kubernetes 官提供了 Kubernetes Dashboard 和多种第三可视化具，来持户查看容器15、、Pod、服务和集群级别的资源使信息，但这些监视功能分散，需要调/安装，缺乏统的可视化管理界。同时，些级的可视化信息，如 Pods 中的容器志、事件和存储分析，很难在原 Kubernetes 上进关联和可视化查询。3.复杂的容器环境更考验安全策略的制定相传统架构，Kubernetes 在安全的运维管理更加复杂：运维员需要制定全的安全策略，包括如何为不同员开发者、运维员、承包商、合作商、户等划定相应的访问权限，以及如何保障络、镜像、节点，甚是操作的安全。虽然 Kubernetes 提供了些络与安全管理功能，如 RBAC（基于的访问控制）机制和 Network Policy，运维员仍然需要花费量时16、间学习相关概念（如和绑定）和操作式。同时，由于 Kubernetes 持容器在多种环境运，户需要设置更严格的应程序络隔离、身份验证和授权规则，以减少攻击，并对数据传输进保护。Kubernetes 各代版本也会存在定的安全漏洞，如允许攻击者伪造命令输出来获得控制和访问权限。为了避免遭遇这些漏洞，运维员需要及时更新补丁和新版本，这就出现了前所说的运维复杂的问题。4.多环境特性提了致性管理的要求在整个应开发、测试、产流程中，运维员需要保证在不同的环境中，应程序的资源配置、部署流程、问题响应机制是致的。这可能需要运维员动定义资源清单，并根据环境调整环境变量、配置件、命名空间等，不仅需要多次操作，还可能17、出现配置错误，拉低部署的可靠性。同时，不少企业只将部分业务放在 Kubernetes 上，其他应放在虚拟化环境/其他平台上运，构成混合的业务运体系。运维员在进管理时，不仅需要掌握不同平台的操作式，且难以对多平台上的集群资源配置、安全策略等进统管理。5.业务快速增带来性能和管理瓶颈随着业务的不断增，Kubernetes 上的应数量可能会出现爆发式的增，容易引发资源争抢，导致性能下降、控制器难以及时感知数据变化等系列问题。这不仅对持 Kubernetes 的络和存储设备具有较的性能和资源管理要求，还要求运维员能够对资源占和性能变化数据做出及时的反馈。这就回到了上“可视化”的问题。Kubernete18、s 管理平台需要具备的 5 个核能为了有效解决 Kubernetes 动运维管理复杂、动化程度低、功能分散等主要问题，运维员应该选择款简单、智能、运维友好并持多环境统管理的 Kubernetes 管理平台，帮助运维员完成耗时费的低价值作、提升容器环境安全与运效率。基于以上分析，我们归纳了 Kubernetes 管理平台需要具备的 5 个核能：产就绪、多环境与虚拟化的统持、简单智能的部署运维、集成的可视化分析界，和络与安全级管理功能。如何选择 Kubernetes 管理平台？核能具体要求价值产就绪-能提产质量与效率 简化操作流程（如通过模板快速创建集群）持动化管理（如动化创建、扩缩容、更新、升级19、、删除集群）提供性能持（如持性能持久化存储）-能保证产稳定性与连续性 强的扩展能（包括插件和节点数量的灵活扩展）升级/扩缩容不影响集群性能与稳定性（如持多种 Kubernetes 版本和动滚动升级策略）提供可保障（如持虚拟 IP、负载均衡、异常节点动隔离、容灾备份功能等）加快应开发与交付速度，推进业务持续发展多环境与虚拟化的统持态持（如兼容多种主流服务器、硬件、虚拟化、OS 等）信创持满对容器、虚拟化、云等所有户使环境的统管理提升业务敏态与灵活性简单智能的部署运维持声明式管理简化管理模式（如需介即可快速完成 k8s 节点批量管理、带多种插件持、持键管理插件）提供智能功能（如定义模板与插件、集群20、动化部署配置）开源持（如集成 Kubernetes 社区成熟的开源项）降低运维压，节约运维成本集成的可视化分析界直观的 UI集成所有可视化和数据分析功能的界提供实时、全的可观测性功能（如运监控、告警、志、事件跟踪、存储分析）保障集群健康运，提升运维体验络与安全的级管理在容器络上通过微分段技术持零信任访问原则可协同调度容器和虚拟化络安全策略实现虚拟化络和容器络的可视化分析和统管理保障数据安全，降低络安全运维难度如何选择 Kubernetes 管理平台？Gartner 选型建议：选择与您的应架构和部署标致的 Kubernetes 管理平台我们附上 Gartner 在Market Guide for21、 Container Management和How to Run Containers and Kubernetes in Production中给出的 Kubernetes 管理平台选型建议，进步帮助您选择符合企业发展标的产品：根据您的技术采情况、业务需求、技术化等确定和/或验证要将哪些业务案例部署在 Kubernetes 上。评估您现有的战略合作伙伴供应商的产品，他们的产品或许就可以满您的要求。明确您是否需要混合云和/或多云解决案。如果需要，您是否愿意购买提供云服务功能的软件？如果您不需要混合和/或多云解决案，您可以考虑采云平台提供的原容器管理服务。您需要个更主的产品还是赋予应程序开发员更22、多控制权的产品？选择符合您要求的解决案。您的公司内部有专业技术员吗？如果没有，您可以选择公有云或托管产品*。*需要注意的是，虽然基于公有云或托管云的 Kubernetes 平台在运维管理上具备定优势，但对数据安全、商锁定、规模扩展带来的资消耗较为敏感的企业，更适合采私有云案。选型时，请对 Kubernetes 管理平台的产品技术和您及供应商的市场条件同时进评估。点击链接，阅读原：选型 K8s 管理平台需关注哪些核能？【附 Gartner 选型建议】如何选择 Kubernetes 管理平台？如何部署运维 Kubernetes？来 Gartner 的建议评估：是否已做好在产环境部署 K8s 的准备23、？由于 Kubernetes 需要投较的学习成本，企业在产环境部署 Kubernetes 之前，需要更实际地评估，是否有必要将些业务放在容器化平台运。IT 领导者需要深考虑，是否具备合适的业务例和组织能来使 Kubernetes。以下列举了些不错的评估出发点。在选择合适的部署模式与 Kubernetes 平台时，户需要将承载的应与部署标结合起来考虑。前，Kubernetes 有 4 种主要的部署模式。l 公有云容器服务：户使公有云 IaaS 供应商提供的 Kubernetes 托管服务。这种模式可以有效降低管理复杂度和成本，提升应上线速度。些商也通过分布式云产品提供本地服务。l 容器管理软件：24、户使打包的软件解决案在本地和/或外部操作并管理 Kubernetes 集群。该解决案不仅包含发版 Kubernetes，也集成了些管理功能，如安全、监控与存储，同时具备可保持混合与多云环境致性的能。运维导向的管理软件：这些软件侧重于简化容器的操作管理，为 DevOps 具链和应程序基础架构软件提供更多的供应商中性。应开发导向的管理软件：这些软件侧重于提供更全的 DevOps 和微服务开发体验，为相邻中间件服务提供了 DevOps 具链和应程序基础架构软件。l 基于 SaaS 的管理服务：户使以 SaaS 形式提供的 Kubernetes 多集群管理服务。该部署模式通常持本地和多云环境，甚也可持25、公有云容器服务创建的集群。通常，基于 SaaS 的管理服务基于软件的产品操作更简便、上线更快速。计划：结合应架构与部署标选择合适的部署模式与解决案如何部署运维 Kubernetes？来 Gartner 的建议除了上述模式，户也可使开源 Kubernetes 平台，这些案可定制化程度更。不过，考虑到实践的复杂性，Gartner 通常不建议采这类部署案。在确定部署模式后，户需要选择合适的 Kubernetes 供应商和产品。为了提升 Kubernetes 部署和运维的质量和效率，建议户选择具备产就绪能、能对多环境与虚拟化统持、部署运维简单智能、具备集成的可视化分析界和络与安全级管理功能的平台。具体26、的核能分析与选型要点，可参考上章节如何选择 Kubernetes 管理平台。在这些能中，Gartner 建议户重点评估平台可性和动化集群管理的能：平台可性：不同的产品在容器化服务可性可能会有所不同。通常来说，所有解决案都内置了动扩展机制，使得容器能在宕机后动重启，保证业务能够在给定数量的容器中连续运。为了避免中断，些服务提供了可将底层容器分布在多个可性区域中的配置能。不过您还需要考虑合适的容器容灾备份案，这样即使整个集群被禁/法访问，您也可以在其他位置/云集群上恢复应状态和数据。此外，些平台还提供了节点级动替换与恢复功能，进步提升架构可性。动化集群管理：尽可能动化集群命周期管理，使不可变（im27、mutable）的式来定义集群抽象类，以实现特定集群实例的按需部署。使个管理平台来控制多个 Kubernetes 集群的命周期和运，并在多个集群之间动分发 Kubernetes 资源定义、策略和身份。根据对要部署在该集群上的应程序组合的评估，确定每个集群的规模和基础架构。确定每个应程序要使的 Kubernetes 对象的类型和数量，以及应程序所属的可性险域。此外，容器管理服务的兼容性（尤其是户需要的第三具）与成本也是重要的考量因素。多数情况下，公有云服务商主要向户收取 IaaS 费，以相对较低的价格提供托管容器服务。不过，如果户不使服务器数据平台，管理员需要规划和配置运容器的作节点，如果处理得28、不好，可能会导致利率低下，反带来不必要的额成本。容器管理软件商通常按内核、CPU、节点或集群收费。些供应商可能会根据部署的应程序或容器映像的数量提供相应的定价模型。因此，在购买产品前，请先确认好商的定价结构。如何部署运维 Kubernetes？来 Gartner 的建议实施：安全、监控、存储、络、具链层的最佳实践建议安全和管理最佳实践企业对待安全问题不能后知后觉，是要采“开发安全运维体化”（DevSecOps）的式，将安全管理嵌整个集群命周期中，包括应程序的构建、部署和运阶段。Gartner 建议：提供个经过筛选的基础镜像录（a curated catalog of base images），29、并制定策略来规定录的使权责。集成图像扫描和签名流程来防范漏洞，将其作为企业持续集成/持续交付（CI/CD）进程的部分，以便在软件开发命周期的构建和运阶段扫描软件。确保安全组件能够对开源组件、库及框架进识别和扫描。按照互联安全中（CIS）公布的 Kubernetes 安全基准来强化配置。建强制性访问控制，确保职责分离，并制定保密管理策略。诸如安全套接字层（SSL）密钥或数据库凭据之类的敏感信息，应由编排器或第三管理服务进加密，并在运时进配置。部署相关的安全产品来提供批准列表、为监控和异常检测，以防范恶意活动。对代码和组件实施有的版本控制，并对开发员和质量保证（QA）团队进安全编码实践培训。监控和30、可视化最佳实践开发员通常更关注应容器的功能层，不是监控容器的运维要求。直以来，监控具始终侧重于主机级指标，如 CPU 利率、内存利率、每秒输输出（I/O）、延迟和络带宽。它们对于运营团队的确重要，但因为缺乏容器级或服务级的细节信息，这些指标本身并不能反映应程序的全貌。因此，开发员应专注于为应程序添加仪表盘或可视化指标，以实现较强的数据可视性。这就需要部署相应的具来执进步的志记录、指标采集和分布式追踪。Gartner 建议：关注容器和服务（跨容器）级别的监控，让监控对象从物理主机扩到“应”。优先考虑能与您选择的 Kubernetes 发版供应商深度整合的（可视化）具及商。选择符合以下条件的具：具31、备动化服务发现能、可执丰富的应程序监控功能、可执分布式追踪、可与 Prometheus 集成，并能使分析和/或机器学习实时提供动建议。如何部署运维 Kubernetes？来 Gartner 的建议存储最佳实践随着容器益泛地应于有状态作负载，客户需要考虑主机以外的数据持久性以及如何保护这些数据。如果您的主要例是旧有应程序或状态例的“原样搬迁”，那么您的存储需求可能没什么变化。但是，如果该应程序将进重重构，或者它将成为个以微服务为导向的全新有状态应程序，那么基础架构和运维（I&O）主管就需要个容器原存储平台，来最限度地提升该作负载的可性、敏捷性及性能。Gartner 建议：选择满下列条件的存储解决32、案：符合微服务架构原则、遵循容器原数据服务的要求、不受限于特定硬件、API 驱动、具有分布式架构，并且持本地、边缘和公有云部署。彻底评估存储产品的性能和稳定性，确保该产品能够与您的 Kubernetes 产品相集成，并持容器存储接（CSI）。络最佳实践敏捷性和可移植性是开发员最关的问题，他们希望的应程序在整个软件开发命周期内均可移植。这种移植可能会跨越本地和公有云基础架构。传统企业络模型是由 IT 部创建络环境来持每个项的开发、测试、质量保证和产，此种模型在 Kubernetes 环境中未必有效。且，容器络会跨越多个分层，包括通过容器运时进“Overlay”通信的主机内和主机间络所依托的物理交33、换和路由基础架构。此外可能还需要个服务格来为微服务的部署提供服务间的通信管理。络解决案需与 Kubernetes 的基元及策略引擎紧密集成。IT 主管应努实现度的络动化，并为开发员提供合适的具和充分的灵活性。Gartner 建议：确定您的 Kubernetes 产品或当前络供应商的解决案是否持 Kubernetes 络。如果不持或法充分持，则应选择个集成了容器络接（CNI）的络覆盖和策略执引擎。确保所选的 Kubernetes 产品能够提供控制器持，以实现集群内各个主机的负载平衡。培训络程师在 Linux 络和络动化具的能，从填补技能空并提升业务敏捷性。如何部署运维 Kubernetes？来 34、Gartner 的建议将 Kubernetes 与开发运维具链相集成要想构建度动化、缝的应程序交付流线，企业和机构需要使其他动化具来完善容器编排，此类具包括代码库、CI/CD 通道、GitOps 和基础设施即代码（IaC）产品等等。I&O 团队应当部署基础架构动化具，以实现动化、精简化的基础架构配置和管理，从应对容器化作负载的动态性质。容器还存在“蔓延”的可能性，虚拟机部署中就存在类似的情形；因此，I&O 团队必须有相应的具和流程来管理容器的命周期并实现其成本效益。开发团队可以将开发运维具链与基于 Kubernetes 的容器编排具相集成，从在类产环境中构建和测试应程序。不同环境之间的这种致性35、能提升产的可靠性，并增进开发与运营团队之间的协作。Gartner 建议：使基础架构动化具，围绕基础架构配置和管理对 I&O 任务进动化。使容器感知配置管理系统对容器映像的命周期进管理，容器映像的构建和分层往往以私有或公共存储库中的现有映像为基础。将 Kubernetes 平台与 CI/CD 具相集成如果您已采购此类具来实现容器映像的动化构建、测试和产部署，那么两者的集成就更显重要。如果您在效管理规模 Kubernetes 资源遇到困难，则应评估资源管理和成本优化具。团队管理：组建平台运维（Platform Ops）团队持续化管理并扩展 DevOps 业务您可能会发现，在云原环境下，“开发团队编36、写代码、QA 团队测试软件应程序，再将其移交给运维团队进常管理”的传统运维模式已不再适。由于平台本身也是个动态的、不断发展的“产品”，随着业务的不断扩展，企业需要创建个协作的“平台运维”团队来替代孤的 IT 运维团队。这个团队中，成员应同时具备软件程和 IT 运维的技能，以 Kubernetes 最佳运维实践为标，持续构建个动化、可扩展和弹性的（resilient）标准化平台。关于 Kubernetes 平台运维团队的更多内容，参第和第章节基础架构团队为何要接管 K8s 部署运维？、基础架构团队接管 K8s 部署运维的可性。点击链接，阅读原：如何部署运维 K8s？我们整理了 3 份 Gartn37、er 报告，得到这些建议如何部署运维 Kubernetes？来 Gartner 的建议Kubernetes 部署，选择虚拟化还是裸属？不少户都感到困惑的是，由于部分应此前都部署在虚拟化或超融合环境，在进容器化转型后，企业应该继续沿原有架构，还是有必要替换成“更契合容器”的裸属服务器。在虚拟化（含超融合）和裸属环境运 K8s 有何区别？两者更适合持哪些应和使场景？企业应如何进选择？我们将详细对虚拟化和裸属运 K8s 的架构，并从性能、可性、扩展能、资源投等 13 个度，全解析两者对 K8s 的持能，为户选择 K8s 部署环境提供参考。架构对从图中可以看出，将 K8s 部署在虚拟化与裸属环境，最区38、别在于有虚拟化层：虚拟化环境采多台虚拟机持 K8s 集群，裸属环境下 K8s 直接跑在物理服务器上。这样的架构差异具体体现在以下。操作系统在虚拟化环境中，主机安装 Host OS 持虚拟机运，虚拟机安装 Node OS 持 K8s 集群运。在同个虚拟化集群上，可以通过不同的虚拟机持不同的操作系统版本、K8s 版本和应程序版本。裸属服务器操作系统需要户选配，该操作系统直接作为 Node OS 持 K8s 集群，台裸属服务器只可持种操作系统，该操作系统为该服务器上运的所有应程序所共。资源访问式虚拟化架构使虚拟化层来管理和分配物理资源。台物理服务器被分割成多个虚拟服务器，每个虚拟服务器可以运不同的应39、程序，多个虚拟机在同组物理服务器上可共享资源，并可动态地请求和释放资源。裸属架构将物理资源直接暴露给应程序，应程序可以需经过虚拟化层的处理，直接访问和管理这些资源。由于单个物理服务器仅承载个 K8s 节点，物理服务器的所有资源均可供该节点使。基于裸属服务器的 K8s 集群资源分配通常是静态的，个集群中的资源不能供给其他集群的应使，可能导致资源闲置。通过架构层的对可以看出，相虚拟化架构，裸属持 K8s 层级更少，但不能笼统地理解为“使裸属部署 K8s 更简单”：缺少虚拟化层在资源访问管理有利有弊，同时虚拟化环境对物理硬件和操作系统的兼容性持更加灵活，这些都需要运维员在前期部署时，结合 K8s 应40、场景进重点评估。差异维度虚拟化架构部署 K8s裸属架构部署 K8s操作系统区分 Host OS 与 Node OS，不同虚拟机可持不同的 Node OS，应程序可使不同操作系统需安装裸属服务器持的操作系统（同时作为 Node OS），台裸属服务器只可持种 Node OS，应程序共同操作系统资源访问式单个物理服务器承载多个 K8s 节点，使虚拟化层来管理和分配物理资源，多个虚拟机在同组物理服务器上可共享资源单个物理服务器仅承载个 K8s 节点，应程序直接访问物理资源Kubernetes 部署，选择虚拟化还是裸属？功能特性对基于架构上的差异，我们将对虚拟化和裸属环境在性能、可靠性、可性、敏捷性、扩41、展能等的能，并针对些重点特性展开深讨论。功能特性虚拟化架构部署 K8s裸属架构部署 K8s性能虚拟化存在定的性能损失（调优配置可减少性能差距）虚拟化层额外开销可靠性物理服务器故障可能影响多台虚拟机（可通过设置虚拟机放置组策略避免同个 K8s 集群的节点同时受影响）物理服务器故障仅影响单节点可性虚拟化层可机制+K8s 可机制，可性更好基本依靠 K8s 可机制敏捷性可快速创建或销毁虚拟机、调整 K8s 集群和节点数量新增 K8s 节点和集群耗时更久（数时-数天）扩展能通过动态分配资源实现灵活扩展但可能导致资源超分，引发性能下降硬件资源直接访问，可扩容但硬件资源扩展不够灵活资源利率多个虚拟机在同组物42、理服务器上共享资源，资源利率更资源分配通常是静态的，可能出现资源闲置软硬件兼容性硬件-虚拟化-Node OS 之间的兼容性由虚拟化/超融合商保障硬件-Node OS 之间的兼容性由 OS 保障同个虚拟化集群可持不同的操作系统版本、Kubernetes 版本和应程序版本每个 K8s 集群只能使唯确定的 Kubernetes 版本Kubernetes 部署，选择虚拟化还是裸属？功能特性虚拟化架构部署 K8s裸属架构部署 K8s安全性各个节点的资源隔离，也可通过加强虚拟机间的隔离进步降低安全险容器内的应程序被攻击者侵后，可能通过共享内核影响其他容器或宿主系统运维难度具备动化的虚拟机管理具，K8s 节43、点部署和运维相对更容易需要更多的动配置和管理，缺少成熟的 K8s 平台运维具成本与资源投费包含硬件、虚拟化、（OS）、K8s 平台、（容器云平台）等费包含硬件、（OS）、K8s 平台、（容器云平台）等如果有基于虚拟化的应，需要独采购满相关需求。数据合规性不同 K8s 集群使的虚拟机可能共享相同的物理资源，可能存在数据合规性问题K8s 集群直接访问独的硬件资源，能更好地保证数据隔离户控制权私有云虚拟化/超融合：硬件设备、操作系统、络、K8s 集群硬件设备、操作系统、K8s 集群供应商依赖可能存在供应商锁定问题，不同虚拟化供应商间存在兼容性问题Kubernetes 是开源产品，较少受供应商影响态系44、统成熟的态系统，丰富的第三具、技术持和社区资源态系统较为年轻，但在不断发展。量新兴态产品的出现，也给最终户的选择带来了困扰。Kubernetes 部署，选择虚拟化还是裸属？性能虚拟化和裸属运 K8s 在性能上的差距是很多户关注的重点。虚拟化技术需要在宿主操作系统和虚拟机间进资源调度，造成定的性能损失，裸属服务器则没有这种损失。但这并不意味着，虚拟化环境难以持性能要求、数据量的容器应。为虚拟机分配够的资源并正确配置 CPU、内存和 I/O 调度策略，可以缩与裸属服务器上运 Kubernetes 的性能差距。可靠性在虚拟化环境中，单个物理服务器上可能运多个虚拟机。因此，当物理服务器出现故障时，可能45、会影响到多个虚拟机实例。不过，户可以通过设置虚拟机放置组策略，将 K8s 集群使的不同的虚拟机分布在不同的物理服务器上，避免单点故障问题。另外，虽然裸属服务器上单个物理服务器仅承载个 K8s 节点，物理服务器故障的影响范围可能会更，但这也取决于 K8s 集群的设计和部署式。可性裸属服务器般依靠 K8s 身提供的可机制，如：动检测并重新启动或重新调度失败的 Pod，根据负载需求动态增加或减少 Pod 实例数量。内置的负载均衡功能，可以将流量分发到不同的 Pod 实例。滚动更新和动回滚。虚拟化服务器在具备以上 K8s 可的同时，还可以利虚拟化技术实现动态资源调度（DRS）、主动迁移、动失败恢复（H46、A）等数据保护功能，进步增强了 K8s 集群基础架构的可性。敏捷性在虚拟化环境中，单个物理服务器上可能运多个虚拟机。因此，当物理服务器出现故障时，可能会影响到多个虚拟机实例。不过，户可以通过设置虚拟机放置组策略，将 K8s 集群使的不同的虚拟机分布在不同的物理服务器上，避免单点故障问题。另外，虽然裸属服务器上单个物理服务器仅承载个 K8s 节点，物理服务器故障的影响范围可能会更，但这也取决于 K8s 集群的设计和部署式。Kubernetes 部署，选择虚拟化还是裸属？扩展能虚拟化和裸属均可为 K8s 提供弹性扩展持。在虚拟机上部署 K8s 集群时，可以较为灵活地将 K8s 节点虚拟机迁移具有充47、硬件资源（如 CPU、内存和磁盘空间）的宿主机上。在裸属服务器上部署 K8s，由于集群可以直接访问硬件资源，因此在单 K8s 集群内部进资源请求和限制、负载均衡、资源配额等作都很便。不过需要注意的是，两者的扩展能均存在定的限制。在虚拟化环境中，多个虚拟机共享宿主机资源，可能导致资源超分，虽然扩展更为敏捷，但需要户注意扩展与系统性能之间的平衡。在裸属环境中调整硬件资源或软件版本，则不如虚拟机灵活，因为这通常需要对物理设备进动操作（如增加服务器数量或内存、硬盘数量、重装操作系统）。另外，裸属环境法提供虚拟化环境中的弹性资源超分能，因此在资源利率可能不如虚拟化环境。资源利率虚拟化环境在处理多种不同类48、型的作负载时，资源利率要于裸属服务器，因为允许多个虚拟机在同组物理服务器上共享资源，虚拟机在需要时可动态地请求和释放资源，可以实现对物理资源的更有效利。裸属 K8s 虽然可以直接访问独的硬件资源，但其资源分配通常是静态的，不同集群之间进资源共享的难度，可能导致资源闲置。安全性在虚拟化环境中运 K8s，可以实现对各个节点的资源隔离，包括 CPU、内存、磁盘和络资源。这提供了更强的安全性。虚拟机之间的隔离可以防潜在的攻击者在成功侵个节点后轻易地获得对其他节点的访问权限。这可以降低安全险，保护关键数据和应程序。裸属 K8s 环境使操作系统的内核功能（如 Linux 的 Cgroups 和 Names49、paces）来为应程序提供隔离。容器之间共享同个内核，但每个容器都有的件系统、络栈和进程空间。这种隔离式相对较弱，如果容器内的应程序被攻击者成功侵，攻击者可能更容易突破容器的隔离层并影响其他容器或宿主系统。不过，通过配置安全策略、使增强型隔离技术（如 SELinux 和 AppArmor），可以降低这种险；但这也使得运维作更加复杂。Kubernetes 部署，选择虚拟化还是裸属？成本与资源投由于不具备虚拟化，采裸属架构部署 K8s 时，企业只需承担裸属服务器硬费、OS 费、K8s 平台费、容器云平台费等，节省了虚拟化的成本。不过，由于单个物理服务器仅承载个 K8s 节点，裸属 K8s 的投成本50、与服务器数量和规格有直接联系。裸属服务器售价较，且不持按量按需购买，当需要为不同途的应建设不同配置的 K8s 集群时，不同集群法共裸属服务器，这种场景将增加服务器的数量，导致成本上升。对于只需要建设个专 K8s 集群的场景，与在裸属服务器上直接部署 K8s 相，基于虚拟化环境的 K8s 集群的投成本可能会更，因为可能需要为这个集群专购买虚拟化软件和管理具，并学习使法。在需要同时部署多个 K8s 集群的场景，虽然在虚拟机上部署 K8s 需要增加些虚拟化费，但个虚拟化集群可以同时服务于多个 K8s 集群，总投可能并不会于完全基于裸属服务器的案。对于户同时需要虚拟化和容器化应的情况，基于虚拟化构建 51、K8s 会分别构建独的资源池具备明显的成本优势。Kubernetes 部署，选择虚拟化还是裸属？虚拟化环境部署 K8s裸属环境部署 K8s适合的场景资源投有限运维员有限难以预估未来资源使情况已使虚拟化/超融合承载产应需要快速部署和灵活扩缩 K8s 集群需要动化流程来执量重复操作需要为“多租户”提供各的 K8s 运环境需要在有限资源内同时持虚拟化和容器化应可投资源充专业运维员充未使虚拟化/超融合运消耗量资源、需要独享硬件资源的应，如性能计算(HPC)应、机器学习和深度学习、在线游戏和虚拟现实等对数据主权、数据保护有严格的合规要求，每种应需独占硬件环境总结：结合企业需求与使场景选择合适的部署环境从52、上的对可以看到，虚拟化和裸属对 K8s 的持能在不同各有千秋。总体，虚拟化环境对资源的整合和利率更，具有更强的横向扩展能、集群命周期管理能、可功能和内核/存储/络独性，在提升运维效率的同时保护数据安全。裸属环境由于减少了虚拟化层开销，在性能与成本投更具优势。企业的云化转型不是个蹴就的过程，K8s 最合适的部署环境也不存在个绝对的答案是沿虚拟化/超融合，还是整体转向裸属/部署在混合环境/分阶段进调整，这些都需要结合企业的实际情况、发展阶段和部署的应需求综合考虑。另外值得提的是，Gartner 在Market Guide for Container Management市场报告中指出，虽然些企业已53、使裸属运容器，但加该列的企业数量增缓慢，主要原因依旧是现阶段缺少裸属部署运维的持具。相反，同时持虚拟化和容器的部署案，如持在 K8s 平台部署虚拟机，或将 K8s 与虚拟化环境集成，这样的案正在成为主流。点击链接，阅读原：虚拟化 vs.裸属：K8s 部署环境架构与特性对Kubernetes 部署，选择虚拟化还是裸属？适合在虚拟化环境中部署 Kubernetes 的三个场景这章中，我们将聚焦以虚拟化环境持 K8s 的适场景，并针对其中 3 个典型场景展开深讨论。重点内容 Gartner 等分析机构在报告中表示，虚拟化（以及超融合）作为种常成熟的技术，承载了部分户的 Kubernetes 集群和容54、器化应。得益于虚拟化技术在资源效率、弹性扩展和安全隔离的优势，以下三种场景常适合基于虚拟化部署 Kubernetes：需要快速部署和灵活伸缩 Kubernetes 集群。需要为“多租户”提供各的 Kubernetes 运环境。需要在有限资源内同时持虚拟化和容器化应。对于“性能”需求的应，户应结合应需求场景和部署条件，综合判断所需的基础架构，评估“理论性能”的同时，更关注“实际使效率”。分析机构：以虚拟化持 Kubernetes 成为多数户选择为了应对不断变化的市场需求和技术挑战，云原应已经成为了许多企业户的选解决案。云原是种构建和运应的法，它充分利云计算的优势，提供度可扩展、弹性和动化的应部署55、；容器作为云原的核组件，为应的打包、运和管理提供了轻量级、效的解决案。云原应选应通过容器化技术进改造，并运在容器中。对于正迈向云原的企业户，他们的容器化应最适合运在哪种类型的 IT 基础设施上呢？得益于容器化技术实现了应程序与底层硬件解耦，这些应能够在多种环境中进部署。Gartner 在 2023 年 5 更新的服务器虚拟化市场指导中，总结了各类应负载在服务器上的承载形态，包括：直接运在裸属服务器的 Host OS 上、运在虚拟化服务器中的 Guest OS 上、运在裸属服务器的容器中、运在虚拟化服务器的容器中，以及虚拟化和容器化的混合运环境。其中，虚拟化环境或虚拟化-容器化混合环境成为最多数56、户的选择。Gartner 在市场指导指出：“容器在虚拟机内部运。到前为，这种模式在企业内部环境中已经成为容器部署的最常模式。”虽然在私有云中的容器化部署呈增趋势，但是 Gartner 分析师认为虚拟化与容器化将在较时期内共存：“尽管（向公有）云迁移的趋势和容器采率不断提，2027 年仍有 70%的数据中 x86 作负载将继续使基于 Hypervisor 的虚拟化（2020 年约 80%）”。适合在虚拟化环境中部署 Kubernetes 的三个场景除了上述 Gartner 的分析，我们还可以参考来 Juju 的Kubernetes 和云原运维报告 2022。该报告汇集了来全球范围内 1300 余57、位受访户的数据，调查涉及混合云和多云环境的运维、Kubernetes、虚拟机、裸机等多内容。这份报告中的项调查内容是：“您在哪些环境中运 Kubernetes 集群？”（这个问题允许多选，因为每个户的 IT 系统中，都可能存在两种或两种以上的基础设施环境并存的情况。）通过对反馈数据的统计（下图），我们可以看到：全球范围内有 58%的受访者使“公有云提供的 Kubernetes 环境”注，毫悬念地占据榜；基于“私有云部署 Kubernetes”的受访者例为 37%。如果对选择了“私有云部署”的调查结果（37%）进细分，我们可以看到其中部分（23%）是在私有云的虚拟机上部署 Kubernetes，58、在裸属服务器上部署 Kubernetes 的例仅为 8%。注：实际上，公有云上的 Kubernetes 服务绝多数是部署在公有云的虚拟机（云主机）上。适合在虚拟化环境中部署 Kubernetes 的三个场景以上 Gartner 的分析和 Juju 的调查数据表明，虚拟化作为种常成熟的技术，承载了部分户的 Kubernetes 集群和容器化应。这是因为虚拟化技术的泛使，另还得益于，虚拟化环境能够在许多 Kubernetes 产使场景下发挥独特的优势。下，我们将结合具体场景，解读虚拟化，以及基于拟化的超融合架构，在资源效率、弹性扩展和安全隔离，为 Kubernetes 带来的价值。适合在虚拟化环境59、中部署 Kubernetes 的三个场景基于容器的云原应与基础环境解耦基于虚拟化部署 Kubernetes 的适场景分析1.需要快速部署和灵活伸缩 Kubernetes 集群场景在需要快速构建的 Kubernetes 集群时，虚拟化（包括传统虚拟化和超融合）作为基础设施是常适的式。众所周知，虚拟机的创建和变更速度远远快过物理服务器。在以下这些场景中，“敏捷地构建 Kubernetes 集群”是最重要的需求：a)在企业内部，出于试、演示、测试的，户可能频繁地（以“周”或“”为周期）创建和删除 Kubernetes 集群；b)在集群使过程中，可能频繁地（以“周”或“”为周期）需要根据业务量的增快速60、增加集群资源，在业务量降低时释放 Kubernetes 集群的资源以持其他应；c)故障和灾难发时，如果原有 Kubernetes 集群法快速恢复，需要快速地（以“分钟”或“时”为单位）搭建临时替代的集群，并在原有基础设施恢复后删除临时的集群。难点通常在物理服务器上部署 Kubernetes 集群所需的时间以“周”为单位；期运维裸属服务器上 Kubernetes 集群的熟练程师，借助动化具，可以将这个时间单位缩短为“天”。尽管这对前两种场景来说尚可接受，但仍法满第三个场景的需求。此外，由于操作环节繁多且重复性，有必要通过动化和标准化提操作效率和准确性，从解放 IT 运维员，使他们能够更专注于系统61、整体优化，实现更质量的服务和交付。在实际的企业 IT 环境中，不同品牌和型号的裸属服务器在硬件配置、固件和 BIOS、远程管理具、驱动程序和操作系统持、络和存储配置、硬件兼容性和供应商持等存在差异。这可能导致动化流程中需针对这些差异进特定配置，从削弱管理流程的动化和标准化，延裸属服务器达到产就绪状态所需的时间。在裸属服务器上启基于 Type-1 Hypervisor 的虚拟化过程中，也需要针对这些差异进特殊配置。然，在 Hypervisor 部署完成后，虚拟服务器的创建、删除和变更就不再涉及这些因素，通常可以在数分钟内完成虚拟机的命周期管理。因此，基于虚拟机快速创建、删除和变更 Kuberne62、tes 集群，可以实现分钟级的敏捷性。适合在虚拟化环境中部署 Kubernetes 的三个场景在裸属服务器上安装 Kubernetes 的过程对于以上场景 2）和场景 3），也有可供选择的其他法：预先置备些基于裸属服务器的 Kubernetes 节点/集群，作为产系统的热备份或冷备份；当有扩容需求或发故障、灾难时，利容器的可迁移特性，将业务迁移到预先准备好的备节点/集群上这确实是部分户在采的案。与基于虚拟机的动态Kubernetes 集群扩缩容和灾备案相，基于裸属的扩缩容和灾备式将要求更的成本，这是因为：备 Kubernetes 节点/集群的主要配置（Kubernetes 版本、络插件、存储插63、件、负载均衡插件、Ingress Controller 等）必须和主集群致，因此组备节点/集群资源只能专属于某个特定的主集群，这种特点在以下场景中会成为企业 IT 的负担：如果户有多个不同配置的主 Kubernetes 集群，就要为每个主集群准备专的备节点/集群，不能共享备资源，成本更资源利率低；为避免应在主备 Kubernetes 集群间法迁移的问题，需要对企业内部所有 Kubernetes 集群的配置进统。然，这对基础架构和 Kubernetes 集群的运维提出了更要求，可能导致难以对 Kubernetes 集群进整体变更。这种情况下，些需要个性化配置的新应可能难以快速上线，从削弱了云原应64、的敏捷性优势；备 Kubernetes 节点/集群资源在正常情况下只能闲置，不能作其他业务的裸属服务器或虚拟化服务器。适合在虚拟化环境中部署 Kubernetes 的三个场景虚拟化环境的价值以上三个不，如果使虚拟机作为 Kubernetes 的运基础，就能很好地解决：多个备集群：可以在套硬件设备上，通过虚拟化创建并维护多个不同配置的备 Kubernetes 集群，以满不同应和作负载的需求；动态资源分配和资源共享：在没有承担临时扩容或灾备作负载的情况下，多个备虚拟化 Kubernetes 集群均可以保持较低的资源占平，此时有较多资源可以为其他虚拟化、容器化应提供运环境；可以随时对备集群规模进快速65、扩展以临时承载业务，并在业务回切到主集群后对备集群进快速缩减，从提资源利效率、减少闲置资源的浪费。适合在虚拟化环境中部署 Kubernetes 的三个场景2.需要为“多租户”提供各的 Kubernetes 运环境场景“多租户”就是指在套基础架构资源池上，允许多个户或者团队（我们统称之为“租户”）共享资源，但互不扰。持“多租户”为何如此重要？在企业内部，各个业务项和部可能采不同的技术栈和应架构，这要求 IT 基础架构管理员为他们提供定制化的 Kubernetes 集群。通过部署多个集群，可以针对各业务线的资源、性能、安全性和可性需求提供合适的解决案。例如：针对不同业务项和部开发的各式容器化应，可66、能需运于具有不同环境参数、插件和服务的平台，以适应各种业务场景和技术需求。来不同第三软件供应商（ISV）的容器化应，可能需要在具有不同版本和络配置的 Kubernetes 集群上运。企业内不同部间需要保护敏感数据和应，防数据泄露，以及避免安全威胁在各部应之间横向传播。不同“租户”的应之间需要隔离 内核层：Kubernetes 所管理的容器，是轻量级的虚拟化技术，它使操作系统的内核功能（如 Linux 的 Cgroups 和 Namespaces）来为应程序提供隔离。容器之间共享同个内核，但每个容器都有的件系统、络栈和进程空间。这种隔离式相对较弱，这使得潜在的安全险更。如果容器内的应程序被攻击者67、成功侵，攻击者可能更容易突破容器的隔离层，并影响其他容器或宿主系统。当然，通过配置安全策略和使增强型隔离技术（如 SELinux 和 AppArmor），可以降低这种险。这些容器安全技术和法还在不断改进中，还不能消除使者的种种顾虑；且，部署新型容器安全技术，也增加了容器运环境和系统的复杂度。与共享操作系统内核的容器化技术相，虚拟机提供成熟的硬件级别的隔离，通过模拟硬件资源来为每个虚拟机实例提供完整的操作系统环境。这种严格的隔离有助于确保：个虚拟机上容器出现的问题不会影响到其他虚拟机，个 Kubernetes 集群上出现的问题，也不会扩散到其他 Kubernetes 集群。络层：同个 Kuber68、netes 集群中的所有容器通常使同样的络案和地址空间，很难实现差异化配置。Kubernetes 原的络隔离法只有络策略（NetworkPolicy），这些策略的编写和维护的作量常。如果采为 Pod 配置多卡并且混合使多种 CNI 的式，可能导致复杂性急剧增加，络配置很容易出现问题或冲突，通常不推荐。虚拟化集群上的虚拟络技术可以使不同 Kubernetes 集群的络完全隔离，并提供基于虚拟络的路由、负载均衡和安全功能。对于络和安全有差异化需求的不同应，可以由不同的虚拟络进承载，不会在同个 Kubernetes 集群内部引常复杂的络、服务和安全插件及相应配置。适合在虚拟化环境中部署 Kubern69、etes 的三个场景难点在多租户场景下，要提供不同的 Kubernetes 集群并在它们之间实现隔离，以确保业务安全，不同使者可能常关注从内核层和络层对 Kubernetes 集群上的应进隔离的式和效果：虚拟化环境的价值为满这些安全隔离的需求，构建并维护多个基于虚拟机的 Kubernetes 集群成为种常合适的法。将单型 Kubernetes 集群拆分成多个型集群，除了可以满上述内核层和络层的隔离需求外，还具备以下优点和价值：更好的扩展性和弹性：随着业务的发展，可能需要对集群进扩展以满不断增的资源需求。部署多个 Kubernetes 集群可以更好地实现集群的弹性扩展和收缩，使 IT 基础架构管70、理员能够灵活地为不同的业务项和部分配资源；更低的总体成本：可以节省硬件、能源和维护成本，从降低整体的运营成本；更便于运维管理：通过部署多个 Kubernetes 集群，IT 基础架构管理员可以更好地监控和管理每个集群的运状况。这有助于及时发现潜在问题，确保应的正常运，并降低故障恢复时间。适合在虚拟化环境中部署 Kubernetes 的三个场景由此可，对于有“多租户”类型需求的企业户来说，如果单个“租户”对资源的要求没有超出总体硬件资源的 50%，所有“租户”的资源需求峰值没有超出硬件资源的总和，那么基于虚拟化技术在同组硬件设备上构建多个不同的 Kubernetes 集群就是种更加可、更加效的式71、。有种情况是例外：某些业和应场景可能需要遵循常强的合规要求，例如数据主权、数据保护等。在这种情况下，多种应、多个部之间即便通过虚拟机层的隔离，也不符合业特定的数据隔离和保护的要求，只有为每种应创建基于独硬件的运环境，才能符合相应的合规要求。3.需要在有限资源内同时持虚拟化和容器化应场景 由于各种现实条件的制约，很多企业户必须在有限的硬件资源上同时持虚拟化和容器化应。如：由于预算有限，短期内法添置新服务器硬件；由于机房空间有限，法容纳更多硬件；由于最终使者所处地理位置分散，需要将硬件分布在不同站点（右图）。分/边缘站点应的混合部署、统管理难点在这些场景中，可能不满为虚拟化应和容器化应单独组建集群72、的硬件条件；或者由于分/边缘站点上的虚拟化和容器化应可能对资源总量需求并不，单独分配硬件资源反进步加剧了资源闲置和管理复杂度的问题。适合在虚拟化环境中部署 Kubernetes 的三个场景虚拟化环境的价值在成熟的虚拟化平台上建设 Kubernetes 集群，实现虚拟化与容器化应的混合部署，是应对以上场景的种最佳式。这种式的优势和价值在于：虚拟化技术成熟：基于 Type-1 Hypervisor 的虚拟化技术已经相当成熟，具有较好的性能、隔离性和安全性，乎所有产级应都已经被证明可以部署在虚拟化环境中。完善的管理体系：虚拟化平台具有完善的管理具和软件，可以对异构集群、异地集群进管理，且很多企业户已73、经有了丰富的虚拟化管理经验。良好的兼容性：通过虚拟机提供的 GuestOS 可以完美地模拟硬件的运环境，Kubernetes 集群运在虚拟机完全不必担兼容问题。灵活的资源分配：虚拟化技术可以更灵活地分配计算、内存和存储资源，并在共享资源的同时实现有效的隔离，有助于实现资源的最优利。更的资源效率：虚拟化技术对资源的动态使可以确保资源在多个不同途的虚拟机之间更加均衡地分配，从提整体资源利率。关于虚拟化管理开销对容器应性能的影响当谈论在虚拟化环境中运容器化应时，我们必然会临与虚拟化管理相关的开销问题。许多户选择在裸属服务器上运 Kubernetes 和容器化应，主要原因在于：基于 Hyperviso74、r 的虚拟化式在裸属服务器上增加了层额外的处理开销，他们担这会降低容器的运性能。这种担忧并完全没有依据，但具体的性能差异受多种因素影响，如虚拟化技术、资源分配策略以及应程序类型。在实际应场景中，我们需要根据具体需求和性能指标来权衡虚拟化带来的安全性、效率提升和性能损失。就像赛与轿的区别：F1 赛只需要考虑在专业赛道内的速度和操控性，家 MPV 需要考虑舒适性、安全性、成本等因素，将部分“性能”让步给“综合体验”；同时，实际的道路环境会出现交通管制和拥堵，这时赛和轿在实际到达时间上可能不会有很差别。由于 MPV 可以同时搭载多个乘客和多种货物，其综合运输效率也会于 F1 赛。适合在虚拟化环境中部75、署 Kubernetes 的三个场景因此，“性能”容器化应需要什么样的运环境，应当放到特定的应需求场景中进讨论。如果应具备以下特点，它就常适合在专属的裸属环境下运：1.运状态时间恒定的应，如果其资源消耗基线超过单台物理服务器资源的 50%，这种应适合独享硬件资源的模式；2.运状态时间恒定的应，如果同时具备：不会出现性能突发导致的扩容、集群内部资源和机制可以满灾难恢复的要求、版本更新间隔（例如超过 6 个甚 1 年）这三个特点，那么这类应在完成次运环境配置后，可以时间保持不变，因此可能不需要虚拟化的便利性和灵活性；3.运状态随时间波动的应，其峰值资源消耗超过单台物理服务器资源的 50%，可能难以76、通过虚拟化与其他应共享资源因为应本身的资源消耗，再加上虚拟化管理机制对资源的消耗，可能导致调度机制复杂且频繁，将降低系统整体的稳定性和可靠性，抵消了虚拟化带来的资源利率提升；4.需要使 GPU 资源的应虽然现在的技术允许将 GPU 直通给虚拟机上的 GuestOS，也可以通过 GPU 虚拟化技术将单个 GPU 硬件的能在集群范围内共享，但对于要求很处理性能的应来说，这些法可能仍法满需求。在这种情况下，裸属环境能更充分地发挥 GPU 的性能。在常的应中，以下这些应通常会消耗量资源：性能计算(HPC)应：这些应通常需要执量的计算任务，例如天预报、量学模拟、物信息学分析等。为了确保计算速度和准确性，77、HPC 应通常需要独占量服务器资源。数据处理和分析：数据应，需要处理和分析量数据。这些应通常需要量的内存和计算资源来实现效的数据处理。机器学习和深度学习：训练型机器学习和深度学习模型通常需要量的计算资源，特别是使 GPU 进加速计算时。这些应可能需要独占多个物理服务器以达到所需的计算能。实时流处理：实时流处理应，需要实时处理量数据流。这些应通常需要量的计算、内存和 I/O 资源来保证低延迟和吞吐量。在线游戏和虚拟现实：型多在线游戏和虚拟现实应需要性能的计算、内存和络资源，以保证游戏的流畅性和实时性。这可能导致它们需要独占量物理服务器资源。适合在虚拟化环境中部署 Kubernetes 的三个场景78、以上只是从应“类型”度进的分析，并不意味每个企业旦要使这些类型的应，就必须部署在裸属服务器上。具体资源消耗，与该种应在特定企业运环境下处理的数据量有关。总结我们列举并分析了三种在虚拟化环境中运 Kubernetes 的场景，每个场景都可以同时获益于虚拟化技术带来的资源效率、弹性扩缩和安全隔离能。资源效率：多个应所需的虚拟机和容器可以在同组物理服务器上运，共享硬件资源。这不仅降低了硬件成本，还减少了能源消耗和维护成本。采成熟的虚拟化资源调度策略，可以对虚拟机的资源分配进动态调整，实现资源负载在多台物理服务器上的平衡分布。弹性扩缩：虚拟化技术能够根据业务需求快速创建、删除和移动虚拟机，实现敏捷的扩79、缩容。论是虚拟化应还是容器应，在临业务量突增、故障或灾难时，都可以通过虚拟化管理器将业务扩展到备资源池。在业务峰期、故障或灾难过后，系统可以动缩容以回收资源。这些资源可作为多种应的共享缓冲资源，提供更的灵活性。安全隔离：虚拟化技术可以在同台物理服务器上创建多个独的虚拟机，每个虚拟机都拥有的操作系统和应程序。这样可以从内核级别确保安全威胁不会扩散、数据不会被越权访问。不同应可以部署在由虚拟化络技术构建的、彼此隔离的络空间内，从简化络拓扑并防安全威胁通过络横向扩散。点击链接，阅读原：适合在虚拟化环境中部署 Kubernetes 的三个场景虚拟化 vs.裸属：持 Kubernetes 性能对测试前两80、章中，我们从功能特性和应场景的度，对了虚拟化环境和裸属环境部署 Kubernetes 的区别和优劣势。在性能，虽然普遍认为裸属持 Kubernetes 性能更佳，但对于两个环境的具体表现和性能差距并没有明确的数据参考，甚有不少户认为“虚拟化上的 Kubernetes 不能满产需求”。为了让户直观感受两个环境对 Kubernetes 的持能，我们分别测试了基于裸属与 SMTX Kubernetes Service（SKS）运有状态应和状态应的性能表现。综合结果显示，SKS（虚拟机 Kubernetes）可以达到裸机 Kubernetes 性能的 82%-96%，满绝部分场景下产容器应的性能需求。81、测试标在 Kubernetes 版本、相关的调优参数、应的资源配置均保持致的情况下，对测试超融合（虚拟化环境）上部署 Kubernetes 集群与裸属服务器部署 Kubernetes 集群的基础性能、有状态应性能和状态应性能。其中，有状态应选择 MySQL、Redis 和 Kafka，状态应选择 Nginx 和微服务测试 Online Boutique。在这次测试中，我们使了配置相同（包括 CPU、内存、本地盘和络）的裸属服务器。这些服务器被于部署两种 Kubernetes 集群：种是通过 SmartX 超融合（内置原虚拟化 ELF）部署的 SKS Kubernetes 集群（包含 1 个 C82、ontrol Plane 和 1 个 Worker），另种是直接运在个裸属上的 Kubernetes 集群。SKS Kubernetes 集群使了超融合集群身的分布式存储，裸属上的 Kubernetes 集群则通过 CSI 使了分离部署的分布式存储集群的资源。这个分布式存储集群的配置（CPU/内存/本地盘/络）与超融合集群保持致。为了便表述，下中两种测试环境分别简称为“SKS”和“裸属 Kubernetes”。测试环境配置软件环境软件类别版本CloudTower3.4.1SMTX OS(不分层+RDMA+Boost)5.1.1SMTX OS（SmartX 超融合软件）SKS 环境（基于超融合部83、署）虚拟化 vs.裸属：持 Kubernetes 性能对测试软件类别版本SKS1.1.0Kubernetes1.24.17操作系统rocky-8.7（1*CP:4C8G+1*worker 40C142G）containerd1.6.22calico3.26.1CSIELF-CSI 0.9.9SKS裸属环境虚拟化 vs.裸属：持 Kubernetes 性能对测试软件类别版本Kubernetes1.24.17操作系统rocky-8.7（1*CP 64C192G）containerd1.6.22calico3.26.1CSIZBS-CSI 2.7.0硬件环境裸属服务器配置下表。硬件类别型号CPU2*84、32 cores Intel(R)Xeon(R)Gold 6226R CPU 2.90GHz 内存192 GB数据盘Intel D7-P5600 1.6TB NVMe SSD*4管理络1GE*1存储络25GE Mellanox MT27710 Family ConnectX-4 Lx*1利 FIO 对两个环境进压测试，结果显示，得益于 SMTX ELF CSI 具备超融合系统中 I/O 本地化的性能优势，SKS 相裸属 Kubernetes 性能更佳。虚拟化 vs.裸属：持 Kubernetes 性能对测试测试过程与结果基础性能测试虚拟化 vs.裸属：持 Kubernetes 性能对测试虚拟化85、 vs.裸属：持 Kubernetes 性能对测试有状态应测试MySQL软件列表软件版本资源限定mysql8.0.3532C 128Gsysbench1.0.206C 4G测试结果 ReadWrite虚拟化 vs.裸属：持 Kubernetes 性能对测试 连续 1 时压测虚拟化 vs.裸属：持 Kubernetes 性能对测试Redis参数设定 10,000,000 requests 200 parallel clients Mixed 模式数据持久化模式（AOF、RDB）测试结果虚拟化 vs.裸属：持 Kubernetes 性能对测试Kafka参数设定 6 Partition 3 Repl86、ication num-records 10,000,000测试结果软件列表Nginx状态应测试软件版本资源限定nginx1.25.34C 2Glocust2.15.1Master 4C 2G/Worker 1C 2G 虚拟化 vs.裸属：持 Kubernetes 性能对测试测试结果可以看到，20000 以下的户并发场景下，SKS 与裸属 Kubernetes 性能相差于 1%。虚拟化 vs.裸属：持 Kubernetes 性能对测试时间运后，25000 户并发场景下，SKS 与裸属 Kubernetes 性能相差在 12%左右。虚拟化 vs.裸属：持 Kubernetes 性能对测试微服务测87、试 Online BoutiqueOnline Boutique 是个云优先的微服务演示应程序，由 11 层微服务应程序组成。该应程序是个基于络的电商务应程序，户可以在其中浏览商品、将其添加到购物并购买。软件列表软件组件版本资源限定locust2.15.1master/worker 2C2G online boutique0.8.1adservice（告服务）0.8.11C1Gcartservice（购物服务）0.8.12C2Gcheckoutservice（结账服务）0.8.11C1Gcurrencyservice（货币服务）0.8.12C1Gemailservice（电邮件服务）0.8.188、1C1Gfrontend（前端）0.8.16C2Gpaymentservice（付服务）0.8.11C1Gproductcatalogservice（产品录服务）0.8.13C1Grecommendationservice（推荐服务）0.8.12C1Gredis-cart(购物)alpine1C1Gshippingservice（运输服务）0.8.11C1G虚拟化 vs.裸属：持 Kubernetes 性能对测试可以看到，5000 以下的户并发场景下，SKS 与裸属 Kubernetes 性能相差于 4%，后随着户数量提升，最差距在 20%左右。测试结果虚拟化 vs.裸属：持 Kubernet89、es 性能对测试测试结论综合以上测试结果，可以看到，在 SKS 上运的有状态和状态应的整体性能平，可达到裸属 Kubernetes 的 82%-96%，在些常规业务压的场景下，SKS 与裸属 Kubernetes 乎可以提供相同的性能，满绝多数业务场景的性能需求。具体来说：SKS 可以很好地撑处于早期和起步阶段的中型企业户的容器化应。SKS 可以很好地撑所有场景中的研发测试集群上的容器化应。虽然各类企业应对性能的需求不尽相同，但基于 SKS 在以上测试场景的表现，我们认为 SKS 可满部分常规应场景的性能需求（除应对性能要求常严格，或同时在线户数可达到较平）。SKS 在下版本也会增加对裸属部署90、环境的持能，以满不同户和应的性能需求。另外值得注意的是，此次测试时 SKS 基于 SmartX 超融合部署，并开启了 Boost 模式进加速，其他的虚拟化案可能法达到相同的性能平。虚拟化 vs.裸属：持 Kubernetes 性能对测试此外，正如适合在虚拟化环境中部署 Kubernetes 的三个场景中提到，虽然虚拟化和裸属持 Kubernetes 在性能上有所差距，但由于虚拟化在资源效率、弹性扩缩、安全隔离、简易运维等的优势，Gartner 预计直到 2027 年依旧会有 70%的数据中 x86 作负载部署在虚拟化环境，为容器化应提供敏捷持。基于虚拟化/超融合建设 Kubernetes 的优91、势资源推荐产品站式构建产级 Kubernetes 集群SmartX 已发布产级 Kubernetes 构建与管理服务产品 SKS。SKS 通过预集成 Kubernetes 常插件，并整合业界领先的 SmartX 超融合产品组件（虚拟化、分布式存储、络与安全等），帮助企业 IT 运维团队轻松部署和管理产级 Kubernetes 集群，构建可承载虚拟化和容器应的完整企业云基础架构。SKS 不仅具备虚拟化环境运 K8s 在效率、扩展和安全的优势，还通过内置的 SmartX 产级分布式存储 CSI 插件，为有状态应提供性能持。SMTX Kubernetes 服务技术书SMTX Kubernetes 服92、务户指南档SMTX Kubernetes 服务-站式构建产级 Kubernetes 集群SMTX Kubernetes Service 1.0 介绍SMTX Kubernetes Service 1.0 操作演示视频Kubernetes 管理场景合集Copyright 2024 北京志凌海纳科技有限公司(SmartX);保留所有权利。本档和本包含的信息受国际公约下的版权和知识产权的管辖。版权所有。未经 SmartX 事先书许可,不得以任何式,包含但不限于电、机械或光学式对本档的任何部分进复制,存储在检索系统中或以任何形式传播。所有 SmartX 公司名称、产品名称和服务名称仅于识别的,可能是其各所有者的注册商标、商标或服务标记。所有信息都未获得该所有的参与、授权或背书。SmartX 会定期发布产品的新版本。因此,对于当前使的某些版本,本档中介绍的些功能可能不受持。有关产品功能的最新信息,请参阅相关产品的发说明。如果您的 SmartX 产品未提供本档所述的功能,请联系 SmartX 以获取硬件升级或软件更新。您的建议有助于我们提升档内容的准确性或组织结构。将您对本档的意发送到 来帮助我们持续改进本档。