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

发布于2022年3月24日

社区帖子：Joel Hans for 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测试套件团队还感谢Kyverno在安全测试方面的贡献，LitmusChaos在弹性测试方面的贡献，以及Kubescope在安全策略方面的贡献。

CNF测试套件的最小安装只需要一个正在运行的Kubernetes集群、kubectl、curl和helem，甚至支持在air-gapped机器或那些可能需要自我托管镜像库的机器上运行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对公共云环境不可避免的故障或协调器层面的问题具有弹性，例如当pods被意外删除或计算资源耗尽时会发生什么。这些测试确保CNF在非运营商级别的共享云硬件/软件平台上满足电信行业的可靠性标准。

可观察性和诊断性。每一块生产性的云原生基础设施都必须通过指标、追踪和日志来观察其内部状态。CNF测试套件寻找与Fluentd、Jaeger、Promtool、Prometheus和OpenMetrics的兼容性，这些测试套件帮助DevOps或SRE团队维护、调试和收集有关其生产环境健康状况的见解，这些环境必须被版本化，在源控制中维护，并仅通过部署管道进行更改。

安全性。云原生安全需要操作系统、容器运行时、协调、应用和云平台层面的专家的关注。虽然其中有许多不属于CNF测试套件的范围，但它仍然验证了容器是否相互隔离，是否与主机隔离，是否允许权限升级，是否有明确的资源限制，以及是否针对常见的CVE进行了验证。

配置。团队应该以声明的方式管理CNF的配置--使用ConfigMaps、Operators或其他声明性接口来设计期望的结果，而不是如何实现上述结果。声明性配置不需要被执行就能被理解，这使得它比命令性配置或甚至是维护得最好的`kubectl'命令序列更不容易出错。

在每个类别中部署了许多测试后，CNF测试套件为每个类别（或一个类别，如果你在CLI中选择）输出灵活的评分和补救建议，为你提供实用的下一步改进你的CNF，以更好地遵循云原生最佳实践。这是一个强大的、仍在增长的解决方案，可供电信业以可控、可观察的方式拥抱云原生，并得到CNCF旗下所有专业技术的验证。

CNF测试套件的下一步是什么？

测试套件计划将继续与电信用户组（TUG）和云原生网络功能工作组（CNF WG）密切合作，收集基于现实世界使用案例的反馈，并不断发展该项目。随着CNF工作组为云原生电信公司发布更多的推荐实践，CNF测试套件团队将增加更多的测试来验证每一项。

事实上，2022年2月25日发布的v0.26.0包括六个新的工作负载测试、错误修复以及围绕平台测试的改进文档。如果你想参与并塑造CNF测试套件的未来，已经有几种方法可以提供反馈或贡献代码、文档或CNF的例子。

• 访问GitHub上的CNF测试套件
• 在Slack上继续对话（#cnf-testuit-dev）
• 参加每周四15:15 UTC的CNF测试套件贡献者电话会议
• 参加每周一16:00 UTC的CNF工作组会议。

展望未来。CNF认证项目

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

对电信业的好处是显而易见的。

• 供应商得到验证 ，证明他们的云原生应用和架构遵守了云原生最佳实践。
• 他们的客户得到验证，他们所采购的云原生服务或网络实际上是云原生的。

他们都得到了更好的可靠性，减少了风险，并降低了资本/运营成本。

我们计划支持任何在认证的Kubernetes环境中运行的产品，以确保企业建立的CNF与任何主要的公共云供应商或企业内部环境兼容。我们还没有公布认证要求，但它们将类似于k8s-conformance流程，你可以通过pull request提交结果，并通过电子邮件收到关于认证过程的更新。

随着CNF认证项目的发展，TUG和CNF-WG都将与大量使用测试套件的组织接触，以进行改进并保持最新的云原生最佳实践。我们很高兴看到电信业如何通过采用更多的云原生原则，如松散耦合系统和不变性，并通过CNF测试套件收集他们努力工作的证明。这就是我们如何确保一个复杂而重要的行业朝着最好的技术基础设施迈出正确的下一步--而不牺牲一寸的可靠性。

要利用CNF测试套件采取下一步行动，并为即将到来的CNF认证计划做好准备，请 安排 一次个性化的CNF测试套件演示，或 参加2022年5月16日KubeCon + CloudNativeCon Europe的同场活动--云原生电信日。