Main |
---|
The CNF Test Suite is a tool that makes it possible to validate telco applications, aka Cloud Native Network Functions (CNFs), and the underlying Telecom platforms adherence to Cloud native principles and best practices.
This Test Suite initiative works closely with the CNF WG which determines requirements for the CNF Test Suite program.
To get the CNF Test Suite up and running, see the Installation Guide.
Prereqs: kubernetes cluster, wget, curl, helm 3.1.1 or greater on your system already.
- Install the latest test suite binary:
source <(curl -s https://raw.githubusercontent.com/cncf/cnf-testsuite/main/curl_install.sh)
- Run
setup
to prepare the cnf-testsuite:cnf-testsuite setup
- Pull down an example CNF configuration to try:
curl -o cnf-testsuite.yml https://raw.githubusercontent.com/cncf/cnf-testsuite/main/example-cnfs/coredns/cnf-testsuite.yml
- Initialize the test suite for using the CNF:
cnf-testsuite cnf_setup cnf-config=./cnf-testsuite.yml
- Run all of application/workload tests:
cnf-testsuite workload
Check out the usage documentation for more info about invoking commands and logging.
The CNF Test Suite will inspect CNFs for the following characteristics:
- Compatibility - CNFs should work with any Certified Kubernetes product and any CNI-compatible network that meet their functionality requirements.
- State - The CNF's state should be stored in a custom resource definition or a separate database (e.g. etcd) rather than requiring local storage. The CNF should also be resilient to node failure.
- Security - CNF containers should be isolated from one another and the host.
- Microservice - The CNF should be developed and delivered as a microservice.
- Scalability - CNFs should support horizontal scaling (across multiple machines) and vertical scaling (between sizes of machines).
- Configuration and Lifecycle - The CNF's configuration and lifecycle should be managed in a declarative manner, using ConfigMaps, Operators, or other declarative interfaces.
- Observability - CNFs should externalize their internal states in a way that supports metrics, tracing, and logging.
- Installable and Upgradeable - CNFs should use standard, in-band deployment tools such as Helm (version 3) charts.
- Hardware Resources and Scheduling - The CNF container should access all hardware and schedule to specific worker nodes by using a device plugin.
- Resilience - CNFs should be resilient to failures inevitable in cloud environments. CNF Resilience should be tested to ensure CNFs are designed to deal with non-carrier-grade shared cloud HW/SW platforms.
See the Test Categories Documentation for a complete overview of the tests.
Welcome! We gladly accept contributions on new tests, example CNFs, updates to documentation, enhancements, bug reports, and more.
-
Join the conversation on CNCF's Slack channels
-
Join the weekly developer meetings
- Meetings every Thursday at 14:15 - 15:00 UTC
- Meeting minutes are here
-
Join the weekly CNF Working Group meetings
- Meetings on Mondays at 16:00 - 17:00 UTC
- Meeting minutes are here
-
Join the monthly Telecom User Group meetings
- Meetings on the 1st Mondays of the month
- Meeting minutes are here
-
Request an Intro to the CNF Test Suite here
CNF Test Suite Demo
Crystal in the Cloud: A cloud native journey at Crystal 1.0 Conference
The CNF Test Suite leverages upstream tools such as OPA Gatekeeper, Helm linter, and Promtool for testing CNFs. The upstream tool installation, configuration, and versioning has been made repeatable.
The test framework and tests (using the upstream tools) are written in the human-readable, compiled language, Crystal. Common capabilities like dependencies between tests and categories are supported.
Setup of vanilla upstream K8s on Equinix Metal is done with the CNF Testbed platform tool chain, which includes k8s-infra, Kubespray. To add support for other providers, please submit a Pull Request to the CNF Testbed repo.
The CNF Test Suite community follows the CNCF Code of Conduct.
The CNF Test Suite is available under the Apache 2 license.