testsuite v2.2.0

crystal kubernetes cloud-native cnf good-first-issue k8s best-practices conformance-tests cnfs

📞📱☎️📡🌐 Cloud Native Telecom Initiative (CNTi) Test Suite is a tool to check for and provide feedback on the use of K8s + cloud native best practices in networking applications and platforms

CNTi Test Suite

Check whether your network function is cloud native before your users find out.

The CNTi Test Suite installs your CNF on Kubernetes, runs its tests against it, and tells you exactly what to fix. It is an open source, vendor-neutral project of LF Networking's Cloud Native Telecom Initiative (CNTi), built on the cloud native principles for networking.

Broad coverage: security, configuration, resilience with chaos experiments, microservice design, compatibility, observability and state.
Results you can act on: every failure names the resource and the container, and says how to fix it.
Proven on real telecom workloads: validated every night against free5GC, a 5G core, and the OCUDU gNB.
Runs where you work: on your laptop with kind, on any cluster, or in CI with one GitHub Action step.

See it run

cnti-testsuite installs the CoreDNS example and runs four tests: three pass, one fails with the impacted resource and a remediation

A passing test shows what it checked. A failing one names the resource and the container, and says how to fix it. A test that could not measure says so instead of passing. Every run writes a results file, and can print it as JSON or turn it into a JUnit report for your CI.

Quick start

You need a Kubernetes cluster with at least two schedulable nodes (for example kind), kubectl pointed at it, and curl. setup installs Helm if it is missing.

source <(curl -s https://raw.githubusercontent.com/lfn-cnti/testsuite/main/curl_install.sh)
cnti-testsuite setup
curl -o cnti-testsuite.yaml https://raw.githubusercontent.com/lfn-cnti/testsuite/main/example-cnfs/coredns/cnti-testsuite.yaml
cnti-testsuite cnf_install --cnf-config ./cnti-testsuite.yaml
cnti-testsuite cert

cert runs the essential tests and takes about ten minutes for CoreDNS. cnti-testsuite workload runs all of them, chaos experiments included.

Next steps: the installation guide, the usage guide, and how to describe your own CNF in cnti-testsuite.yaml.

Use it in CI

The CNTi Test Suite GitHub Action creates a kind cluster, installs your CNF and runs the essential tests (cert) on every pull request:

- uses: lfn-cnti/testsuite-action@v1
  with:
    helm_chart_dir: charts/my-cnf

The job page gets a summary and an annotation for every failed test. With badge_branch set, the action also publishes a badge for your README, showing the result of your default branch:

![CNTi essential](https://github.com/<owner>/<repo>/raw/badges/cnti-badge.svg)

It looks like this, with the number of essential tests passed:

The badge is evidence the project produces itself from the essential test set; it is not a certification. GitLab-hosted projects get the same job and badge from the CNTi Test Suite CI/CD component.

What the suite checks

Category	What is checked
Security	privileges, capabilities, host access, root users, seccomp and other Pod Security Standards controls, resource limits, service account tokens, network policies, credentials in configuration
Configuration	labels, image tags, default namespace, hard-coded IP addresses, NodePorts and host ports, secrets, immutable ConfigMaps, alpha APIs, operators
Reliability, resilience and availability	liveness and readiness probes, and chaos experiments: pod deletion, network latency, corruption and duplication, memory, disk and I/O stress, DNS errors
Compatibility, installability and upgradability	Helm charts, scaling up and down, rolling updates and rollback, CNI independence, deprecated APIs
Microservice	image size, startup time, one process type, service discovery, signal handling, zombie reaping, init systems, shared databases
Observability and diagnostics	logs, Prometheus metrics, OpenMetrics, log routing, tracing
State	node drain, elastic and local volumes, database persistence

The test documentation explains every test: what it measures, why the practice matters, and how to fix a failure.

Reference workloads

free5GC, an open source 5G core, is the reference CNF of the suite. If a test and a real network function disagree, it shows us which of the two is right. See example-cnfs/free5gc, and the announcements by LF Networking and free5GC.
The OCUDU gNB, a 5G base station, runs in test mode without a radio. See example-cnfs/ocudu.

Both are validated every night. They need more of the host than CoreDNS (free5GC's UPF needs the gtp5g kernel module), so start with CoreDNS for a first try.

Documentation

Getting started

INSTALL.md: the release binary, the clusters the suite runs against, kind, EKS.
SOURCE_INSTALL.md: building from source for development.
FAQ.md: questions that come up when the suite is first run.

Using the suite

USAGE.md: every command and option, the results file and its schema, exit codes, the JUnit report, the evidence bundle, the MCP server, environment variables.
CNTI_TESTSUITE_YAML_USAGE.md: the cnti-testsuite.yaml that describes a CNF: charts, manifests, values, registries, per-test settings.
K8S_OPERATORS.md: CNFs deployed and managed by an operator.
docs/TEST_DOCUMENTATION.md: every test, with its rationale, sources and remediation.
docs/cnti-testsuite-results.schema.json: the results file, as a JSON Schema.

In CI