使用 CNF 测试套件测试云原生最佳实践

Joel Hans为CNCF撰写的社区帖子

电信行业是当今日益数字化的经济的支柱，但在发展以满足现代基础设施实践方面面临着艰巨的新挑战。电信是如何陷入这种境地的？由于事故或停机的风险非常严重，该行业几乎完全专注于将风险降至最低并最大限度地提高可靠性的系统设计。对于关键任务服务来说，无论是公共空中交通管制还是私人高速银行业务，这都非常棒，但它强调稳定性而不是生产力，并采用可能使其运营更具弹性和性能的新技术。

电信正在追赶云原生技术，下游效应开始显现。这些组织现在在企业和IT的实际选择方面落后于时代，这意味着他们不太可能招聘到他们需要的顶级工程人才。在竞争日益激烈的环境中，他们需要提高生产力，更快地将新的电话平台部署到市场，而不是在内部构建的旧定制解决方案中陷入困境。

为了实现从内部信任到行业信任工具的飞跃，电信组织需要有信心，他们有望正确发展其虚拟网络功能（VNF）基础架构，以使用Kubernetes实现云原生功能。这就是CNCF旨在提供帮助的地方。

进入用于电信的 CNF 测试套件

云原生网络功能 （CNF） 是以云原生方式实现或促进网络功能的应用程序，使用标准化原则开发，至少由一个微服务组成。

CNF测试套件（cncf/ cnf-testsuite）是一个开源测试套件，供电信公司确切地了解其CNF的云原生程度。它专为电信开发人员和网络运营商而设计，使用Kubernetes和其他云原生技术进行构建，以验证他们遵循云原生原则和最佳实践的程度，例如不可变基础架构，声明性API和"可重复的部署过程"。

CNCF将电信用户组（TUG）和云原生网络功能工作组（CNF WG）聚集在一起，实施CNF测试套件，该套件通过该套件的灵活测试和优化的执行时间，帮助电信开发人员和运营团队构建更快的反馈循环。由于它可以集成到任何 CI/CD 管道中，无论是在开发还是预生产检查中，或者作为单个 CNF 的独立测试运行，因此电信开发团队可以一目了然地了解其新部署如何与云原生生态系统保持一致，包括 CNCF 托管的项目、技术和概念。

这是对一个难题的有力回答：我们是如何原生云的？

CNF 测试套件利用 10 个 CNCF 托管的项目和多个开源工具。使用CoreDNS的修改版本作为示例CNF，供最终用户通过五个步骤熟悉测试套件，并在可观察性测试中使用Prometheus来检查CNF主动公开指标的最佳实践。它还打包了其他上游工具，如OPA Gatekeeper，Helm linter和Promtool，以使安装，配置和版本控制可重复。CNF Test Suite 团队也感谢 Kyverno 在安全测试、LitmusChaos 弹性测试和 Kubescope 安全策略方面的贡献。

CNF 测试套件的最小安装只需要一个正在运行的 Kubernetes 集群、kubectl、curl 和 helm，甚至支持在气隙机器或可能需要自托管映像存储库的机器上运行 CNF 测试。安装后，您可以使用示例 CNF 或自带 - 您只需提供 .yml 文件并运行 “cnf-testsuite all” 即可运行所有可用的测试。甚至还有一个快速的五步过程，可以在不到15分钟的时间内部署套件并获得建议。

CNF 测试套件涵盖的内容及其原因

在 2022 年初，CNF 测试套件可以运行大约 60 个工作负载测试，这些测试分为 7 个不同的类别。

兼容性、可安装性和可升级性：CNF 应与任何经过认证的 Kubernetes 产品和任何满足其功能要求的 CNI 兼容网络配合使用，同时使用标准的带内部署工具，如 Helm（版本 3）图表。CNF 测试套件检查 CNF 是否可以使用 “kubectl” 进行水平和垂直缩放，以确保它可以利用 Kubernetes 的内置功能。

微服务：CNF 应作为微服务进行开发和交付，以提高敏捷性，或缩短部署之间所需的开发时间。敏捷组织可以更频繁地部署新功能，或者允许多个团队根据其功能领域安全地部署补丁，例如修复安全漏洞，而无需先与其他团队同步。

状态：云原生基础结构应该是不可变的、与环境无关的，并且能够灵活应对节点故障，这意味着可以正确管理配置、持久性数据和状态。CNF 的配置应该是无状态的，存储在自定义资源定义中，或者存储在本地存储的单独数据库中，任何持久性数据都由 StatefulSets 管理。单独的有状态和无状态信息使基础架构易于重现、一致、一次性，并始终以可重复的方式部署。

可靠性、弹性和可用性：电信基础设施的可靠性与标准 IT 相同，需要高度安全可靠，并支持超低延迟。云原生最佳实践尝试通过依赖具有更高可维护性（平均恢复时间 （MTTR））的冗余子组件来减少平均故障间隔时间 （MTBF），然后通过混沌工程和自我修复配置测试这些假设。测试套件使用一种混沌测试来确保 CNF 能够灵活应对公有云环境不可避免的故障或业务流程协调器级别的问题，例如当 Pod 被意外删除或计算资源耗尽时会发生什么。这些测试可确保 CNF 在非运营商级共享云硬件/软件平台上符合电信行业的可靠性标准。

可观察性和诊断：生产云原生基础架构的每个部分都必须通过指标、跟踪和日志记录使其内部状态可观察。CNF 测试套件寻求与 Fluentd、Jaeger、Promtool、Prometheus 和 OpenMetrics 的兼容性，这有助于 DevOps 或 SRE 团队维护、调试和收集有关其生产环境运行状况的见解，这些环境必须进行版本控制、在源代码管理中维护，并且只能通过部署管道进行更改。

安全性：云原生安全性需要操作系统、容器运行时、编排、应用程序和云平台级别的专家的关注。虽然其中许多不属于 CNF 测试套件的范围，但它仍然会验证容器是否彼此隔离，是否允许权限提升，是否定义了资源限制，以及是否针对常见 CVE 进行了验证。

配置：团队应以声明性方式（使用 ConfigMaps、运算符或其他声明性接口）管理 CNF 的配置，以设计所需的结果，而不是如何实现所述结果。声明性配置不必执行即可被理解，这使得它比命令式配置甚至维护最良好的"kubectl"命令序列更不容易出错。

在每个类别中部署大量测试后，CNF 测试套件会为每个类别（或一个类别，如果您在 CLI 中选择该类别）输出灵活的评分和补救建议，从而为您提供改进 CNF 以更好地遵循云原生最佳实践的实用后续步骤。对于电信行业来说，这是一个功能强大且仍在增长的解决方案，能够以一种可控、可观察的方式接受云原生，并由 CNCF 旗下的所有专业知识进行验证。

展望未来：CNF 认证计划

CNF 测试套件只是即将到来的云原生网络功能 （CNF） 认证计划中激动人心的第一步。我们期待使 CNF 测试套件成为网络设备提供商和 CNF 开发团队的事实工具，以证明（然后认证）他们在新产品和服务中采用云原生最佳实践。

电信行业的胜利是显而易见的：

• 提供商可以验证其云原生应用程序和架构是否符合云原生最佳实践。
• 他们的客户可以验证他们正在采购的云原生服务或网络实际上是云原生的。

它们都获得了更好的可靠性，降低了风险，并降低了资本/运营成本。

我们计划支持在经过认证的 Kubernetes 环境中运行的任何产品，以确保组织构建与任何主要公共云提供商或本地环境兼容的 CNF。我们尚未发布认证要求，但它们将类似于 k8s 符合性流程，您可以通过拉取请求提交结果，并通过电子邮件接收认证流程的更新。

随着 CNF 认证计划的发展，TUG 和 CNF-WG 都将与大量使用测试套件的组织合作，以进行改进并及时了解最新的云原生最佳实践。我们很高兴看到电信行业如何通过采用更多的云原生原则（如松散耦合系统和不可变性）来发展，并通过CNF测试套件收集其辛勤工作的证据。这就是我们如何确保一个复杂而重要的行业朝着基础设施提供的最佳技术迈出正确的下一步，同时又不牺牲一英寸的可靠性。

总结

以上是生活随笔为你收集整理的使用 CNF 测试套件测试云原生最佳实践的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。