Skip to main content

Kubernetes Pattern Detection API Documentation

API version v1.0.0

Overview

The Kubernetes Pattern Detection API allows you to write rules to identify Patterns within the Kubernetes Cluster that might be suitable to improve performance, compliance, modularity, observability, security, and reliability.

API Specification

Pattern Schema Version

  • Version: kubepattern.it/v1
  • Format: YAML

Pattern Definition Structure

Root Level Properties

PropertyTypeRequiredDescription
versionstringYesVersion of the pattern schema (kubepattern.it/v1)
kindenumYesMust be Pattern
metadataobjectYesPattern metadata information
specobjectYesPattern specification

metadata

PropertyTypeRequiredDescription
namestringYesName of the pattern (es: my-pattern)
displayNamestringYesName of the pattern (es: My Pattern)
patternTypeenumYesType: STRUCTURAL, BEHAVIORAL, FUNCTIONAL, ...
severityenumYesSeverity level: CRITICAL, WARNING, INFO
categoryenumYesCategory: BestPractice, Security, Reliability, Performance, CostOptimization
docUrlstringNoURL to pattern documentation
gitUrlstringNoURL to Git repository containing pattern rules
descriptionstringNoBrief description of the pattern

spec

PropertyTypeRequiredDescription
messagestringYesMessage displayed when pattern is matched
topologyenumYesTopology: LEADER_FOLLOWER, SINGLE
resourcesarrayYesArray of resource definitions (minimum 1 required)
relationshipsarrayNoArray of relationship definitions between resources

spec.resources

Each resource in the resources array must contain:

PropertyTypeRequiredDescription
resourcestringYesKubernetes resource kind (e.g., "Pod", "Service", "Deployment")
idstringYesUnique identifier for the resource within the pattern (es: main-container)
leaderboolean(Requeired Single)Specify if resource is leader or not.
filtersobjectNoFiltering conditions for this resource

spec.resources.filters

PropertyTypeRequiredDescription
matchAllarrayNoAll conditions must be met
matchAnyarrayNoAt least one condition must be met
matchNonearrayNoNone of these conditions must be met

spec.resources.filters.matchAll/Any/None[*]

Each condition within filter arrays contains:

PropertyTypeRequiredDescription
keystringYesJSONPath or key to match against
operatorenumYesComparison operator (es: EQUALS, CONTAINS, EXISTS)
valuesarrayConditionalValues to match against (not required for Exists/NotExists)

spec.actors

This is an array of resourceIds, the one that cooperate in the pattern.

info

Actors must contain at least one resource for SINGLE Topology and at least two for LEADER_FOLLOWER Topology

spec.relationships

Each relationship in the relationships array contains:

PropertyTypeRequiredDescription
typeenumYesRelationship type (see Supported Relationship Types)
descriptionstringNoHuman-readable description of the relationship
weightfloatNoweight of relationship in confidence score
requiredbooleanYesWhether this relationship is mandatory for pattern matching
sharedbooleanYesSpecify if this relationship must or must no be shared
resourceIdsarrayYesArray of resource IDs that participate in this relationship

spec.commonRelationships

Each relationship in the commonRelationships array contains:

PropertyTypeRequiredDescription
typeenumYesRelationship type (see Supported Relationship Types)
descriptionstringNoHuman-readable description of the relationship
weightfloatNoweight of relationship in confidence score
requiredbooleanYesWhether this relationship is mandatory for pattern matching
sharedbooleanYesSpecify if this relationship must or must no be shared
resourceIdsarrayYesArray of resource IDs that participate in this relationship

Supported Relationship Types

TipoDescrizione / Esempio
OWNSDeployment -> ReplicaSet
MANAGESReplicaSet -> Pod
MOUNTSPod -> Volume
EXPOSESService -> Pod
USES_CONFIGRiferimento a ConfigMap/Secret
SAME_NETWORKNetwork policies
IS_NAMESPACE_OFNamespace -> Generic Resource
USES_SAPod -> ServiceAccount
HAS_AFFINITY_TOPod -> Pod

Supported Operators

OperatorDescription
EQUALSExact match
NOT_EQUALSNot equal to
GREATER_THANGreater than
GREATER_OR_EQUALGreater than or equal to
LESS_THANLess than
LESS_OR_EQUALLess than or equal to
EXISTSKey exists
NOT_EXISTSKey does not exist
IS_EMPTYIs empty

JSONPath Key Syntax

The key property supports JSONPath-like syntax for accessing Kubernetes resource properties:

Examples:

  • metadata.namespace - Access resource namespace
  • metadata.labels['app'] - Access specific label
  • metadata.ownerReferences[*].uid - Access owner reference UIDs
  • spec.containers[*].name - Access all container names
  • spec.template.spec.containers[*].image - Access container images in pod template
  • spec.volumes[*].name - Access volume names
  • spec.nodeName - Access assigned node
  • spec.hostNetwork - Access host network setting

Pattern Analysis Logic

Execution Flow

Leader Resource Logic

Here is that explanation formatted in English and Markdown.


Relationships vs. Common Relationships

In the context of resource graph analysis, relationships describe how entities are interconnected. Here is a key distinction:

Relationships

A Relationship refers to a direct edge (link) between two resources. It describes a specific, often one-to-one or one-to-many, interaction or dependency.

  • Concept: Resource A -- Relationship --> Resource B.
  • Example: A Deployment manages a ReplicaSet.
    • Deployment -- MANAGES --> ReplicaSet
  • Use Case: Useful for filtering resources based on their direct neighbors in the cluster.
    • Example Query: "Find all ReplicaSet resources managed by this Deployment."

Common Relationships

A Common Relationship describes a scenario where two or more source resources share the exact same relationship to a single, common destination resource.

  • Concept: Multiple resources converging on a shared resource.
  • Example: Two different Pods both mount the exact same Volume. The Volume is the common resource.
    • Pod A --MOUNTS--> Volume X <--MOUNTS-- Pod B
  • Use Case: Useful for filtering or scoring resources based on the common context and interactions they have.
    • Example Query: "Find all Pods that mount the same Volume as Pod A."

Example Usage

Simple Sidecar Pattern

{
"version": "kubepattern.it/v1",
"kind": "Pattern",
"metadata": {
"name": "sidecar",
"displayName": "Sidecar",
"patternType": "STRUCTURAL",
"severity": "INFO",
"category": "architecture",
"gitUrl": "https://github.com/GabrieleGroppo/kubepattern-registry/tree/main/doc/sidecar-pattern.md",
"docUrl": "https://github.com/GabrieleGroppo/kubepattern-registry/tree/main/doc/sidecar-pattern.json",
"description": "Identifies pods that should implement the sidecar pattern but are incorrectly separated into different pods. The sidecar pattern places helper containers alongside the main application container in the same pod to share lifecycle, network, and storage resources. Common use cases include logging, monitoring, configuration management, and service mesh proxies."
},
"spec": {
"message": "Pod '{{main-app.name}}' in namespace '{{main-app.namespace}}' appears to be separated from its sidecar pod '{{sidecar.name}}' in namespace '{{sidecar.namespace}}'. These pods share volumes and likely have a common lifecycle, suggesting they should be combined into a single pod with multiple containers. This would improve resource sharing, deployment atomicity, and reduce network overhead.",
"topology": "LEADER_FOLLOWER",
"resources": [
{
"resource": "Pod",
"id": "main-app",
"leader": true,
"filters": {
"matchAll": [
{
"key": ".spec.volumes",
"operator": "EXISTS",
"values": []
}
],
"matchNone": [
{
"key": ".metadata.namespace",
"operator": "EQUALS",
"values": [
"kube-system",
"kube-public",
"kube-node-lease",
"krateo-system"
]
}
],
"matchAny": [
{
"key": ".metadata.name",
"operator": "EQUALS",
"values": [
"application",
"frontend",
"backend",
"api",
"web",
"service"
]
},
{
"key": ".metadata.labels.app",
"operator": "EQUALS",
"values": [
"frontend",
"backend",
"application"
]
},
{
"key": ".metadata.labels.tier",
"operator": "EQUALS",
"values": [
"web",
"api",
"frontend",
"backend"
]
}
]
}
},
{
"resource": "Pod",
"id": "sidecar",
"filters": {
"matchAll": [
{
"key": ".spec.volumes",
"operator": "EXISTS",
"values": []
}
],
"matchNone": [
{
"key": ".metadata.namespace",
"operator": "EQUALS",
"values": [
"kube-system",
"kube-public",
"kube-node-lease"
]
}
],
"matchAny": [
{
"key": ".metadata.name",
"operator": "EQUALS",
"values": [
"logging",
"logger",
"log",
"log-collector",
"log-shipper",
"fluentd",
"filebeat",
"logstash"
]
},
{
"key": ".metadata.labels.app",
"operator": "EQUALS",
"values": [
"logging",
"logger",
"log-collector"
]
},
{
"key": ".metadata.labels.component",
"operator": "EQUALS",
"values": [
"log-collector",
"log-shipper",
"logging",
"monitoring",
"metrics"
]
}
]
}
}
],
"actors": [
"main-app",
"sidecar"
],
"commonRelationships": [
{
"id": "shared-volume-mount",
"type": "MOUNTS",
"description": "Both pods mount volumes with the same name or emptyDir type, indicating they are intended to share storage. In a proper sidecar pattern, these containers should share the same pod-level volume.",
"weight": 0.6,
"required": true,
"shared": true,
"resourceIds": [
"main-app",
"sidecar"
]
}
],
"relationships": [

]
}
}