Top 10 CNCF Projects You Are Not Using But Should Be in 2026

The CNCF landscape in 2026 has grown to over 200 projects. Most engineering teams are familiar with Kubernetes, Prometheus, Helm, Argo CD, and a handful of other headline tools. The conversation typically stops there — not because the rest of the landscape is unimportant, but because navigating 200 projects to find the ones that solve real problems you have is genuinely difficult without a guide.

This list is that guide. Each of the ten projects below was selected because it solves a specific, real problem that engineering teams are currently working around with more cumbersome approaches — and because most teams have not yet discovered that the CNCF ecosystem already has the right tool for the job. None of these are experimental. All have CNCF Graduated or Incubating status, real production deployments, and active maintenance. You are probably already experiencing the problems they solve.

WHAT WAS EXCLUDED

We deliberately excluded the tools that everyone already knows: Kubernetes, Prometheus, Helm, Argo CD, Envoy, etcd, containerd, Flux, Jaeger, and similar widely adopted projects. Every tool on this list was selected specifically because it has significant adoption gap relative to the value it delivers.

The 10 Projects

#1 OpenCost — Kubernetes cost visibility at the workload level — for free

CNCF Status

Sandbox (Incubating track — 2026)

Install

helm install opencost opencost/opencost -n opencost — create-namespace

What It Solves

You know your AWS bill is $80K/month. You cannot tell which team, service, or namespace is responsible for which portion. OpenCost provides per-pod, per-service, per-namespace, per-label cost allocation using actual cloud provider pricing data — exposing cost via Prometheus metrics and a Grafana dashboard.

Why It Changes Behaviour

Engineering teams that can see their own service costs self-correct. Teams that see a $4,200/month line item for an idle overnight batch worker fix it. OpenCost makes cloud waste visible at the team level, which is where behaviour change actually happens.

How It Works

Reads Kubernetes resource requests and usage from the metrics API plus cloud instance pricing from provider APIs, computes per-workload cost continuously, exposes as Prometheus metrics

Free Tier

OpenCost is fully free for most use cases. Kubecost Enterprise adds multi-cloud, advanced allocation, and team governance features.

2026 Status

# OpenCost Prometheus metrics (key ones):
# container_cpu_allocation        - CPU cost per container/hr
# container_memory_allocation_bytes - Memory cost per container/hr

# API: cost breakdown by namespace for last 7 days
curl http://opencost.opencost.svc:9090/allocation \
  -G -d window=7d -d aggregate=namespace -d accumulate=true

# Grafana query: top 10 most expensive services this month
# topk(10, sum(container_cpu_allocation) by (pod))
#   * ON(pod) group_left(namespace, label_team)
#   kube_pod_labels

#2 SPIFFE and SPIRE — Cryptographic workload identity — the zero-trust foundation

CNCF Status

Both Graduated

What It Solves

Services authenticating to other services via shared API keys, static tokens, or network-level trust. SPIFFE provides every workload a cryptographic identity certificate proving I am payments-api in namespace production — without human-provisioned credentials. SPIRE is the production implementation.

How It Works

SPIRE Agent runs as a DaemonSet on every node; attests each workload’s identity using Kubernetes service account context; issues short-lived X.509 SVIDs (SPIFFE Verifiable Identity Documents) that expire and auto-renew

Key Integration

Vault + SPIRE: services authenticate to Vault using their SVID instead of a stored token — no static credentials, automatic rotation, cryptographically verified workload identity

Regulatory Drivers

EU DORA (Digital Operational Resilience Act) requires demonstrable workload identity in financial services; EU Cyber Resilience Act mandates software supply chain attestation — SPIFFE provides the identity layer for both

2026 Status

SPIFFE v1.0 spec stable; SPIRE v1.10 Graduated; Istio and Cilium both support SPIFFE as identity backend

#3 Hubble — Real-time Kubernetes network observability built into Cilium

CNCF Status

Part of CNCF Graduated Cilium

Enable

helm upgrade cilium cilium/cilium — set hubble.relay.enabled=true — set hubble.ui.enabled=true

What It Solves

Which services are talking to which other services right now? Without Hubble, answering this requires log analysis, tcpdump sessions, or maintaining hand-drawn architecture diagrams. Hubble captures every network flow through Cilium and exposes it via a real-time UI, CLI, and Prometheus metrics.

Service Map

Auto-generated, real-time service dependency map showing which pods communicate with which other pods, with success and error rates per connection — derived from actual traffic, not annotations

NetworkPolicy Builder

Use Hubble to observe real traffic patterns before writing NetworkPolicy rules — build your allow-list from actual observed flows rather than guessing which services need to talk

Incident Use Case

When checkout-service stops working, hubble observe — pod checkout-service — last 5m shows exactly which downstream connections are failing and whether they are being blocked by a NetworkPolicy or a service crash

#4 Argo Rollouts — Progressive delivery automation — canary and blue-green built into Kubernetes

CNCF Status

Incubating — part of the Argo Project

Install

kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

What It Solves

Standard Kubernetes Deployments roll out new versions without any automated analysis of whether the new version is actually working. Engineers rely on manual monitoring during rollouts. Argo Rollouts automates the analysis, promotion, and rollback decisions.

How It Works

Rollout resources replace Deployments; define a canary or blue-green strategy with analysis templates that query Prometheus/Datadog/CloudWatch; rollout promotes automatically if metrics pass, rolls back automatically if they fail

Why Teams Miss It

Most teams know Argo CD (deployment) but miss that Argo Rollouts is a separate project solving progressive delivery — one of the most impactful deployment safety improvements available with minimal operational overhead

2026 Status

# Argo Rollout: canary deployment with automated analysis
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: payments-api
spec:
  strategy:
    canary:
      steps:
      - setWeight: 10   # Shift 10% of traffic
      - pause: { duration: 5m }
      - analysis:
          templates:
          - templateName: success-rate
      - setWeight: 50
      - pause: { duration: 5m }
      - setWeight: 100
---
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
  - name: error-rate
    interval: 60s
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{status=~"5.."}[5m]))
          / sum(rate(http_requests_total[5m]))
    successCondition: result[0] < 0.01

#5 Score — Platform-agnostic workload specification for IDPs

CNCF Status

Sandbox

What It Solves

Every service in your cluster has a values.yaml with dozens of environment-specific overrides. Developers copy-paste configuration, make mistakes, and environments drift. Score lets developers describe what a workload needs in abstract terms; the platform resolves those needs into environment-specific Kubernetes/Helm/Docker Compose configuration.

How It Works

score.yaml defines the workload abstractly — a container, a database dependency, an environment variable. score-helm generates Helm values; score-compose generates Docker Compose. Same developer-facing spec, platform-managed environment resolution.

Developer Experience

Developers declare I need a PostgreSQL database rather than specifying connection strings, hostnames, and credentials per environment. The platform resolves the right connection details for dev/staging/production automatically.

Adoption

Humanitec’s Platform Orchestrator uses Score as its workload definition format; growing adoption in Backstage-based IDP golden paths

2026 Status

v0.16 stable; CNCF Sandbox; the most developer-friendly IaC approach for platform teams building self-service infrastructure

#6 Flagger — Progressive delivery for service meshes and ingress controllers

CNCF Status

Incubating — part of the Flux ecosystem

Install

helm install flagger flagger/flagger — namespace flagger-system

What It Solves

Same problem as Argo Rollouts — automated progressive delivery — but with a different integration model. Flagger works directly with your service mesh or ingress controller (Istio, Linkerd, NGINX, AWS ALB) to manage traffic shifting, rather than replacing Kubernetes Deployments.

When to Choose Flagger Over Argo Rollouts

Teams already running Istio or Linkerd who want to leverage the mesh traffic management capabilities they already have; teams not using Argo CD who want GitOps-neutral progressive delivery

Canary Analysis

Queries Prometheus, Datadog, CloudWatch, or any metrics provider to evaluate success criteria during rollout — same analytical sophistication as Argo Rollouts with a different integration model

2026 Status

v1.40 stable; CNCF Incubating; 5k+ GitHub stars; widely used in Flux-based GitOps deployments

#7 OpenTelemetry (The Overlooked Features) — The observability standard most teams use partially

CNCF Status

Graduated — the second largest CNCF project by contributor count after Kubernetes

Why It Is On This List

Despite massive adoption, most teams run OTel incompletely: they use the Collector but not the logs SDK, or traces but not metrics, or OTel for one service while maintaining separate Prometheus scrapers elsewhere. The under-utilised capability is OTel Logs with trace correlation.

OTel Logs + TraceID Correlation

When OTel Logs are emitted via the OTel SDK, every log entry includes the TraceID of the request that generated it. In your logging tool, click a log entry and jump directly to the full distributed trace. This single correlation eliminates the find the right trace from a log message investigation step that routinely consumes 10–15 minutes per incident.

OTel Collector as Unified Pipeline

Replace separate log shippers (Fluentd/Fluent Bit), metric exporters (various), and trace agents with a single OTel Collector deployment. Reduces DaemonSet count, standardises telemetry format, simplifies SIEM integration.

2026 Status

v1.35 stable; OTLP is the universal telemetry protocol for 2026 — every major observability vendor accepts it natively

#8 KubeArmor — Container-aware LSM security using AppArmor and SELinux

CNCF Status

Sandbox

What It Solves

AppArmor and SELinux are powerful Linux security mechanisms but require per-application profiles that are complex to generate and manage in dynamic Kubernetes environments. KubeArmor provides a Kubernetes-native interface to define and enforce these profiles automatically.

How It Differs From Falco and Tetragon

KubeArmor specialises in container-to-host access control: preventing containers from accessing the host filesystem paths, network interfaces, and process namespace beyond what their normal behaviour requires. Complements Falco and Tetragon rather than replacing them.

Zero-Day Protection Pattern

KubeArmor learns the normal behaviour profile of an application. When a zero-day exploit enables unexpected file system or network access, KubeArmor blocks it — the container can only do what its profile allows, regardless of how the exploitation was achieved.

2026 Status

v1.5 stable; CNCF Sandbox; strong adoption in Korean and EU financial services; growing alongside Falco in layered runtime security stacks

#9 Notary Project — Secure artifact signing and distribution chain verification

CNCF Status

Graduated

What It Solves

Container image signing (Sigstore/Cosign) ensures images have not been tampered with. The Notary Project’s TUF (The Update Framework) adds metadata about valid version ranges, protecting against rollback attacks where an attacker serves an older, vulnerable but validly-signed image.

notation CLI

The practical interface: notation sign myimage attaches a TUF-anchored signature; notation verify validates the full signing chain. Integrates with OCI-compliant registries including GHCR, ECR, and Harbor.

Full Supply Chain Stack

Sigstore (signing) + SBOM (content inventory) + TUF/Notary (distribution trust) = the complete supply chain security stack required by EU Cyber Resilience Act and US EO 14028 in 2026

2026 Status

v1.2 stable; CNCF Graduated; growing integration with Kyverno image verification policies

#10 Crossplane — Cloud resources as Kubernetes CRDs — IaC without leaving kubectl

CNCF Status

Incubating

Install

helm install crossplane crossplane-stable/crossplane — namespace crossplane-system — create-namespace

What It Solves

Platform teams building self-service developer infrastructure portals need a way to let teams provision databases, storage buckets, and message queues without raw cloud console or Terraform access. Crossplane extends Kubernetes CRDs to represent cloud resources — teams provision infrastructure with kubectl, the same tool they use for workloads.

Composition Layer

Composite Resources enable platform teams to build abstractions: developers request a production-database without knowing which RDS instance type, subnet group, or parameter group is appropriate. The platform encodes that knowledge in a Composition.

GitOps Native

Cloud infrastructure is now a Kubernetes resource — it can be managed by Argo CD or Flux with the same GitOps workflow as application deployments. Infrastructure changes have a Git history, PR review process, and automated reconciliation.

2026 Status

v1.18 stable; CNCF Incubating; rapidly growing in platform engineering teams building self-service infrastructure portals on top of Backstage or Port

Implementation Priority: Where to Start

START WITH OPENCOST

Install OpenCost today. It takes under an hour, requires no application changes, and delivers immediate insight that typically motivates multiple optimisation efforts: idle worker removal, rightsizing, KEDA scale-to-zero adoption. The cost visibility OpenCost provides also makes the business case for platform engineering investments self-evident — teams that can see their cloud costs are more receptive to platform changes that reduce them. It is the highest-leverage single tool on this list for any team that does not already have workload-level cost attribution.