Tool to check for and provide feedback on the use of K8s + cloud native best practices in networking applications and platforms cloud-native cnf k8s telecom testing testsuite
0.45.0 Latest release released

CNF Test Suite

| Main | | ------------------------------------------------------------------------------------------------------------------------------------------- | | Build Status |

The CNF Test Suite is a tool that validates telco application's (i.e. Cloud Native Network Functions - CNFs) 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.

Installation and Usage

To get the CNF Test Suite up and running, see the Installation Guide.

To give it a try immediately you can use these quick install steps

Prereqs: kubernetes cluster, wget, curl, helm 3.1.1 or greater on your system already.

  1. Install the latest test suite binary: source <(curl -s
  2. Run setup to prepare the cnf-testsuite: cnf-testsuite setup
  3. Pull down an example CNF configuration to try: curl -o cnf-testsuite.yml
  4. Initialize the test suite for using the CNF: cnf-testsuite cnf_setup cnf-config=./cnf-testsuite.yml
  5. Run all of application/workload tests: cnf-testsuite workload

More Usage docs

Check out the usage documentation for more info about invoking commands and logging.

Cloud Native Categories

The CNF Test Suite will inspect CNFs for the following characteristics:

  • Configuration - The CNF's configuration should be managed in a declarative manner, using ConfigMaps, Operators, or other declarative interfaces.
  • Compatibility, Installability & Upgradability - CNFs should work with any Certified Kubernetes product and any CNI-compatible network that meet their functionality requirements while using standard, in-band deployment tools such as Helm (version 3) charts.
  • Microservice - The CNF should be developed and delivered as a microservice.
  • 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.
  • Reliability, Resilience & Availability - CNFs should be reliable, resilient and available to failures inevitable in cloud environments. CNFs should be tested to ensure they are designed to deal with non-carrier-grade shared cloud HW/SW platforms.
  • Observability & Diagnostics - CNFs should externalize their internal states in a way that supports metrics, tracing, and logging.
  • Security - CNF containers should be isolated from one another and the host. CNFs are to be verified against any common CVE or other vulnerabilities.

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.

Communication and community meetings


CNF Test Suite Demo

Crystal in the Cloud: A cloud native journey at Crystal 1.0 Conference

Implementation overview

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.

Code of Conduct

The CNF Test Suite community follows the CNCF Code of Conduct.

License terms

The CNF Test Suite is available under the Apache 2 license.

  github: cncf/cnf-testsuite
  version: ~> 0.45.0
License MIT
Crystal >= 1.6.0


Dependencies 18

  • cluster_tools ~> 1.0.0
    {'github' => 'cnf-testsuite/cluster_tools', 'version' => '~> 1.0.0'}
  • commander ~> 0.4.0
    {'github' => 'mrrooijen/commander', 'version' => '~> 0.4.0'}
  • docker_client ~> 1.0.0
    {'github' => 'cnf-testsuite/docker_client', 'version' => '~> 1.0.0'}
  • find main
    {'branch' => 'main', 'github' => 'cnf-testsuite/find'}
  • git~cnf-testsuite ~> 1.0.0
    {'github' => 'cnf-testsuite/git', 'version' => '~> 1.0.0'}
  • halite ~> 0.12.0
    {'github' => 'icyleaf/halite', 'version' => '~> 0.12.0'}
  • helm ~> 1.0.1
    {'github' => 'cnf-testsuite/helm', 'version' => '~> 1.0.1'}
  • icr master
    {'branch' => 'master', 'github' => 'crystal-community/icr'}
  • k8s_kernel_introspection ~> 1.0.1
    {'github' => 'cnf-testsuite/k8s_kernel_introspection', 'version' => '~> 1.0.1'}
  • k8s_netstat ~> 1.0.0
    {'github' => 'cnf-testsuite/k8s_netstat', 'version' => '~> 1.0.0'}
  • kernel_introspection ~> 0.1.0
    {'github' => 'cnf-testsuite/kernel_introspection', 'version' => '~> 0.1.0'}
  • kubectl_client ~> 1.0.4
    {'github' => 'cnf-testsuite/kubectl_client', 'version' => '~> 1.0.4'}
  • protobuf
    {'github' => 'jeromegn/'}
  • release_manager main
    {'branch' => 'main', 'github' => 'cnf-testsuite/release_manager'}
  • retriable
    {'github' => 'Sija/'}
  • sam~vulk 4e3b271d31d7
    {'commit' => '4e3b271d31d7', 'github' => 'vulk/'}
  • tar main
    {'branch' => 'main', 'github' => 'cnf-testsuite/tar'}
  • totem ~> 0.7.0
    {'github' => 'icyleaf/totem', 'version' => '~> 0.7.0'}

Development Dependencies 1

  • ameba ~> 1.3.1
    {'github' => 'crystal-ameba/ameba', 'version' => '~> 1.3.1'}

Dependents 0

Last synced .
search fire star recently