KubePatternFind the smells hiding between your resources

Every manifest is valid on its own. The defect shows up only in the relation: an unused definition, a dangling reference, a missing companion. KubePattern finds them across any Kubernetes CRD, with patterns you write as YAML.

Get Started

Explore Patterns

GitHub

$ kubectl get smells -A

NAMESEVERITYPHASESINCETARGETcnpg-cluster-without-scheduledbackup-9c1e…HIGHPending4mCluster/pg-orderskrateo-navmenuitem-page-missing-31ab…HIGHActive1dNavMenuItem/billingcrossplane-function-not-used-7c3e…MEDIUMActive3dFunction/function-kcleso-secretstore-not-used-d04f…MEDIUMActive6dSecretStore/vault-devcertmanager-clusterissuer-not-used-e2b8…LOWActive9dClusterIssuer/ca-legacy

Illustrative output. Pending smells have not yet held for the pattern's for duration.

Relations, not single resources

Finds what a per-resource check cannot see. KubePattern rebuilds a graph of your live cluster and looks at how resources refer to each other.

Works with any CRD

Kinds are resolved at run time through API discovery, so custom resources unknown at build time are analysed by the same engine.

Pattern-as-Code

A smell is a small declarative pattern, with a target, its dependencies, and the relations that must not hold. No expression language to learn.

Stateful findings

Smells keep their identity and first observation. A minimum duration holds a finding Pending until it has persisted, so transient states stay quiet.

Kubernetes-native

Patterns and Smells are custom resources. Query them with kubectl, protect them with RBAC, and ship them with GitOps like everything else.

Runs as a CronJob

Hourly by default, reading only the kinds your patterns name. Nothing keeps running between scans, and nothing of yours is ever deleted.

How it works

One scan, four steps

KubePattern is a Go analyzer that runs inside your cluster. Each scan reads your patterns, fetches what they need, and writes back one Smell per defect it finds.

1
Read the patterns
Patterns are custom resources in your cluster. A linter checks each one first: a malformed pattern is logged and skipped, never run.
2
Fetch only what they need
Kinds are resolved at run time through API discovery, so custom resources unknown at build time work. Only the kinds a pattern names are listed.
3
Build the graph
Resources become the vertices of a graph, built once per run. Each relationship in a pattern is a query over it.
4
Write the smells
Every target that matches becomes a Smell, with a stable identity and a first observation. Fixed smells disappear on the next run.

Pattern-as-Code

A smell is a few lines of YAML

A pattern describes the defect, not the rule. Name the resource it is about, the resources that give it context, and the relation that makes it a smell.

The target is fixed. A smell may come from several resources, but it is always reported on one, so it is never ambiguous.
Absence is a first-class idea. An orphan or a dangling reference is written as matchNone: no instance of the dependency relates to the target.
Findings are resources too. Each Smell has a stable name, a severity, a message and the exact target.

Read the Pattern reference

PatternSmell

yaml

apiVersion: kubepattern.dev/v1
kind: Pattern
metadata:
  name: cnpg-cluster-without-scheduledbackup
spec:
  displayName: PostgreSQL Cluster Without Scheduled Backup
  category: Reliability
  severity: HIGH
  for: 10m
  message: "Cluster {{target.metadata.name}} has no ScheduledBackup."
  target:
    kind: Cluster
    apiVersion: postgresql.cnpg.io/v1
    plural: clusters
  dependencies:
    - id: schedule
      kind: ScheduledBackup
      apiVersion: postgresql.cnpg.io/v1
      plural: scheduledbackups
  relationships:
    matchNone:
      - with: schedule
        type: custom
        criteria:
          - targetPath: "metadata.name"
            dependencyPath: "spec.cluster.name"
            operator: EQUALS
          - targetPath: "metadata.namespace"
            dependencyPath: "metadata.namespace"
            operator: EQUALS

yaml

apiVersion: kubepattern.dev/v1
kind: Smell
metadata:
  name: cnpg-cluster-without-scheduledbackup-9c1e4d2a-5b7f-4c1e-8a3d-2f6b0e91c7a4
  namespace: orders
  labels:
    kubepattern.dev/phase: Pending
spec:
  name: cnpg-cluster-without-scheduledbackup
  category: Reliability
  severity: HIGH
  phase: Pending
  since: "2026-10-11T09:00:04Z"
  suppress: false
  message: "Cluster pg-orders has no ScheduledBackup."
  target:
    apiVersion: postgresql.cnpg.io/v1
    kind: Cluster
    name: pg-orders
    namespace: orders
    uid: 9c1e4d2a-5b7f-4c1e-8a3d-2f6b0e91c7a4

What it finds

Four families of relational smell

Each family is a relation that is missing, or one that should not be there. The same engine finds them in GitOps tools, operators, control planes and platform portals, with no code changes.

Unused / orphan. A definition exists, but nothing refers to it, such as a ClusterIssuer that no Certificate uses.
Dangling reference. A resource points at something that does not exist, such as a Composition for a kind that no XRD defines.
Missing companion. A resource lacks the sibling that should accompany it, such as a PostgreSQL Cluster with no ScheduledBackup.
Misconfiguration. A relation exists that should not, such as a Pooler named like a Cluster in the same namespace.

See how a pattern describes them

Built for GitOps timing

Quiet about transient states

A GitOps tool that re-creates a referrer makes a healthy resource look unused for a few minutes. Give a pattern a minimum duration and the finding stays Pending until the condition has persisted.

First observation is kept. Each Smell records spec.since and keeps its identity across runs.
Fixed means gone. When the condition stops holding, the Smell is deleted and the clock starts again.
Your call survives. Suppress a false positive once and the suppression holds on later runs.

How the lifecycle works

Hourly CronJob · pattern with for: 90m

A transient state

A GitOps tool deletes and re-creates the only referrer of a resource. For a few minutes the resource looks unused.

Row	Run 1	Run 2	Run 3	Run 4	Run 5
Condition holds	No	Yes	No	No	No
Smell	No smell	Pending	Deleted	No smell	No smell

Never becomes Active. Nobody is paged for a blip.

A real smell

Nothing refers to the resource, and nothing is going to.

Row	Run 1	Run 2	Run 3	Run 4	Run 5
Condition holds	No	Yes	Yes	Yes	Yes
Smell	No smell	Pending	Pending	Active	Active

Becomes Active at run 4, the first run at least 90 minutes after the first observation.

Run your first scan in a minute

Install the chart, apply a pattern, and read the results with kubectl get smells -A.

bash

helm upgrade --install kubepattern \
  oci://ghcr.io/kubepattern/charts/kubepattern \
  --version <VERSION> --namespace kubepattern-system --create-namespace

Read the guide Star on GitHub

KubePatternFind the smells hiding between your resources

Relations, not single resources

Works with any CRD

Pattern-as-Code

Stateful findings

Kubernetes-native

Runs as a CronJob

One scan, four steps ​

Read the patterns

Fetch only what they need

Build the graph

Write the smells

A smell is a few lines of YAML ​

Four families of relational smell ​

Quiet about transient states ​

A transient state

A real smell

Run your first scan in a minute ​

One scan, four steps

A smell is a few lines of YAML

Four families of relational smell

Quiet about transient states

Run your first scan in a minute