如何部署运维 K8s？我们整理了 3 份 Gartner 报告，得到这些建议

在上一篇云原生系列文章中，我们分析了 Kubernetes 管理平台需要具备的 5 个核心能力，并结合 Gartner 报告给出了一些选型建议。为了帮助读者顺利实现 Kubernetes 部署运维，我们“深扒”了更多 Gartner 调研报告*，总结了从评估、计划、实施到团队管理等一系列完整的 K8s 实践建议，希望为有需求的读者提供参考。

* 本文内容基于 Gartner 报告进行翻译和调整，参考的报告请见文末“参考文章”列表。

评估：是否已做好在生产环境部署 K8s 的准备？

由于 Kubernetes 需要投入较大的学习成本，企业在生产环境部署 Kubernetes 之前，需要更实际地评估，是否有必要将一些业务放在容器化平台运行。IT 领导者需要深入考虑，是否具备合适的业务用例和组织能力来使用 Kubernetes。以下列举了一些不错的评估出发点：

图片来源：How to Run Containers and Kubernetes in Production（Gartner）

计划：结合应用架构与部署目标选择合适的部署模式与解决方案

在选择合适的部署模式与 Kubernetes 平台时，用户需要将承载的应用与部署目标结合起来考虑。目前，Kubernetes 有 4 种主要的部署模式：

• 公有云容器服务：用户使用公有云 IaaS 供应商提供的 Kubernetes 托管服务。这种模式可以有效降低管理复杂度和成本，提升应用上线速度。一些厂商也通过分布式云产品提供本地服务。

• 容器管理软件：用户使用打包的软件解决方案在本地和/或外部操作并管理 Kubernetes 集群。该解决方案不仅包含发行版 Kubernetes，也集成了一些管理功能，如安全、监控与存储，同时具备可保持混合与多云环境一致性的能力。

  ▶ 运维导向的管理软件：这些软件侧重于简化容器的操作管理，为 DevOps 工具链和应用程序基础架构软件提供更多的供应商中立性。
  ▶ 应用开发导向的管理软件：这些软件侧重于提供更全面的 DevOps 和微服务开发体验，为相邻中间件服务提供了 DevOps 工具链和应用程序基础架构软件。

• 基于 SaaS 的管理服务：用户使用以 SaaS 形式提供的 Kubernetes 多集群管理服务。该部署模式通常支持本地和多云环境，甚至也可支持公有云容器服务创建的集群。通常，基于 SaaS 的管理服务比基于软件的产品操作更简便、上线更快速。

图片来源：CTOs’ Guide to Containers and Kubernetes — Answering the Top 10 FAQs（Gartner）

除了上述模式，用户也可使用开源 Kubernetes 平台，这些方案可定制化程度更高。不过，考虑到实践的复杂性，Gartner 通常不建议采用这类部署方案。

在确定部署模式后，用户需要选择合适的 Kubernetes 供应商和产品。为了提升 Kubernetes 部署和运维的质量和效率，建议用户选择具备生产就绪能力、能对多环境与虚拟化统一支持、部署运维简单智能、具备集成的可视化分析界面和网络与安全高级管理功能的平台。具体的核心能力分析与选型要点，请参考：Kubernetes 管理平台需要具备哪些核心能力？ChatGPT 这样说。

在这些能力中，Gartner 建议用户重点评估平台可用性和自动化集群管理方面的能力：

• 平台可用性：不同的产品在容器化服务可用性方面可能会有所不同。通常来说，所有解决方案都内置了自动扩展机制，使得容器能在宕机后自动重启，保证业务能够在给定数量的容器中连续运行。为了避免中断，一些服务提供了可将底层容器分布在多个可用性区域中的配置能力。不过您还需要考虑合适的容器容灾备份方案，这样即使整个集群被禁用/无法访问，您也可以在其他位置/云集群上恢复应用状态和数据。此外，一些平台还提供了节点级自动替换与恢复功能，进一步提升架构可用性。

• 自动化集群管理：尽可能自动化集群生命周期管理，使用不可变（immutable）的方式来定义集群抽象类，以实现特定集群实例的按需部署。使用一个管理平台来控制多个 Kubernetes 集群的生命周期和运行，并在多个集群之间自动分发 Kubernetes 资源定义、策略和身份。根据对要部署在该集群上的应用程序组合的评估，确定每个集群的规模和基础架构。确定每个应用程序要使用的 Kubernetes 对象的类型和数量，以及应用程序所属的可用性风险域。

此外，容器管理服务的兼容性（尤其是用户需要的第三方工具）与成本也是重要的考量因素。多数情况下，公有云服务商主要向用户收取 IaaS 费用，以相对较低的价格提供托管容器服务。不过，如果用户不使用无服务器数据平台，管理员需要自己规划和配置运行容器的工作节点，如果处理得不好，可能会导致利用率低下，反而带来不必要的高额成本。容器管理软件厂商通常按内核、CPU、节点或集群收费。一些供应商可能会根据部署的应用程序或容器映像的数量提供相应的定价模型。因此，在购买产品前，请先确认好厂商的定价结构。

实施：安全、监控、存储、网络、工具链层面的最佳实践建议

安全和管理最佳实践

企业对待安全问题不能后知后觉，而是要采用“开发—安全—运维一体化”（DevSecOps）的方式，将安全管理嵌入整个集群生命周期中，包括应用程序的构建、部署和运行阶段。

Gartner 建议：

• 提供一个经过筛选的基础镜像目录（a curated catalog of base images），并制定策略来规定目录的使用权责。

• 集成图像扫描和签名流程来防范漏洞，将其作为企业持续集成/持续交付（CI/CD）进程的一部分，以便在软件开发生命周期的构建和运行阶段扫描软件。确保安全组件能够对开源组件、库及框架进行识别和扫描。

• 按照互联网安全中心（CIS）公布的 Kubernetes 安全基准来强化配置。

• 建立强制性访问控制，确保职责分离，并制定保密管理策略。诸如安全套接字层（SSL）密钥或数据库凭据之类的敏感信息，应由编排器或第三方管理服务进行加密，并在运行时进行配置。

• 部署相关的安全产品来提供批准列表、行为监控和异常检测，以防范恶意活动。

• 对代码和组件实施有力的版本控制，并对开发人员和质量保证（QA）团队进行安全编码实践培训。

监控和可视化最佳实践

开发人员通常更关注应用容器的功能层面，而不是监控容器的运维要求。一直以来，监控工具始终侧重于主机级指标，如 CPU 利用率、内存利用率、每秒输入输出（I/O）、延迟和网络带宽。它们对于运营团队的确重要，但因为缺乏容器级或服务级的细节信息，这些指标本身并不能反映应用程序的全貌。因此，开发人员应专注于为应用程序添加仪表盘或可视化指标，以实现较强的数据可视性。这就需要部署相应的工具来执行进一步的日志记录、指标采集和分布式追踪。 

Gartner 建议：

• 关注容器和服务（跨容器）级别的监控，让监控对象从物理主机扩大到“应用”。

• 优先考虑能与您选择的 Kubernetes 发行版供应商深度整合的（可视化）工具及厂商。

• 选择符合以下条件的工具：具备自动化服务发现能力、可执行丰富的应用程序监控功能、可执行分布式追踪、可与 Prometheus 集成，并能使用分析和/或机器学习实时提供行动建议。

存储最佳实践

随着容器日益广泛地应用于有状态工作负载，客户需要考虑主机以外的数据持久性以及如何保护这些数据。如果您的主要用例是旧有应用程序或无状态用例的“原样搬迁”，那么您的存储需求可能没什么变化。但是，如果该应用程序将进行重大重构，或者它将成为一个以微服务为导向的全新有状态应用程序，那么基础架构和运维（I&O）主管就需要一个容器原生存储平台，来最大限度地提升该工作负载的可用性、敏捷性及性能。

Gartner 建议：

• 选择满足下列条件的存储解决方案：符合微服务架构原则、遵循容器原生数据服务的要求、不受限于特定硬件、API 驱动、具有分布式架构，并且支持本地、边缘和公有云部署。

• 彻底评估存储产品的性能和稳定性，确保该产品能够与您的 Kubernetes 产品相集成，并支持容器存储接口（CSI）。

网络最佳实践

敏捷性和可移植性是开发人员最关心的问题，他们希望自己的应用程序在整个软件开发生命周期内均可移植。这种移植可能会跨越本地和公有云基础架构。传统企业网络模型是由 IT 部门创建网络环境来支持每个项目的开发、测试、质量保证和生产，此种模型在 Kubernetes 环境中未必有效。

而且，容器网络会跨越多个分层，包括通过容器运行时进行“Overlay”通信的主机内和主机间网络所依托的物理交换和路由基础架构。此外可能还需要一个服务网格来为微服务的部署提供服务间的通信管理。网络解决方案需与 Kubernetes 的基元及策略引擎紧密集成。IT 主管应努力实现高度的网络自动化，并为开发人员提供合适的工具和充分的灵活性。

Gartner 建议：

• 确定您的 Kubernetes 产品或当前网络供应商的解决方案是否支持 Kubernetes 网络。如果不支持或无法充分支持，则应选择一个集成了容器网络接口（CNI）的网络覆盖和策略执行引擎。

• 确保所选的 Kubernetes 产品能够提供入口控制器支持，以实现集群内各个主机的负载平衡。培训网络工程师在 Linux 网络和网络自动化工具方面的能力，从而填补技能空白并提升业务敏捷性。

将 Kubernetes 与开发运维工具链相集成

要想构建高度自动化、无缝的应用程序交付流水线，企业和机构需要使用其他自动化工具来完善容器编排，此类工具包括代码库、CI/CD 通道、GitOps 和基础设施即代码（IaC）产品等等。I&O 团队应当部署基础架构自动化工具，以实现自动化、精简化的基础架构配置和管理，从而应对容器化工作负载的动态性质。容器还存在“蔓延”的可能性，虚拟机部署中就存在类似的情形；因此，I&O 团队必须有相应的工具和流程来管理容器的生命周期并实现其成本效益。

开发团队可以将开发运维工具链与基于 Kubernetes 的容器编排工具相集成，从而在类生产环境中构建和测试应用程序。不同环境之间的这种一致性能提升生产的可靠性，并增进开发与运营团队之间的协作。

Gartner 建议：

• 使用基础架构自动化工具，围绕基础架构配置和管理对 I&O 任务进行自动化。

• 使用容器感知配置管理系统对容器映像的生命周期进行管理，容器映像的构建和分层往往以私有或公共存储库中的现有映像为基础。

• 将 Kubernetes 平台与 CI/CD 工具相集成——如果您已采购此类工具来实现容器映像的自动化构建、测试和生产部署，那么两者的集成就更显重要。

• 如果您在高效管理大规模 Kubernetes 资源方面遇到困难，则应评估资源管理和成本优化工具。

团队管理：组建平台运维（Platform Ops）团队持续化管理并扩展 DevOps 业务

您可能会发现，在云原生环境下，“开发团队编写代码、QA 团队测试软件应用程序，再将其移交给运维团队进行日常管理”的传统运维模式已不再适用。由于平台本身也是一个动态的、不断发展的“产品”，随着业务的不断扩展，企业需要创建一个协作的“平台运维”团队来替代孤立的 IT 运维团队。这个团队中，成员应同时具备软件工程和 IT 运维的技能，以 Kubernetes 最佳运维实践为目标，持续构建一个自动化、可扩展和弹性的（resilient）标准化平台。

欲了解如何组建平台运维团队，请阅读：接管 K8s 部署运维，基础架构团队是否做好准备？| SmartX 趋势分享。

参考文章：

1. How to Run Containers and Kubernetes in Production

https://www.gartner.com/document/4018502

2. CTOs’ Guide to Containers and Kubernetes — Answering the Top 10 FAQs

https://www.gartner.com/document/4015168

3. Quick Answer: How to Operationalize a Container Management Solution

https://www.gartner.com/document/4013256

推荐阅读：

点击阅读原文，体验 SmartX 云原生存储产品 IOMesh 免费社区版。