Skip to content

0.3.0

Choose a tag to compare

View all tags
@asamoorerh asamoorerh released this 05 Feb 20:54
· 52 commits to main since this release
0.3.0
b407f7d
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Introducing MetricSource: Declarative Resource Collection

ClusterPulse now supports MetricSource, a new custom resource that lets you declaratively collect, extract, and aggregate data from any Kubernetes resource across all connected clusters.

What's changing

Previously, ClusterPulse collected a fixed set of built-in resources — nodes, pods, deployments, services, operators — with no ability to customize what was gathered or how it was processed. Built-in collection continues to work and is not being removed in this release, but new monitoring use cases should use MetricSource.

MetricSource replaces the need for hardcoded collectors by letting you define:

  • What to collect — any resource kind, including custom CRDs (Certificates, NetworkPolicies, your own application resources)
  • What to extract — specific fields via JSONPath, with type-aware parsing for quantities, timestamps, and more
  • What to compute — derived values from extracted fields using expressions
  • What to aggregate — cluster-wide summaries (count, sum, avg, min, max, percentile, distinct) with filtering and grouping

What you need to do

No immediate migration is required. Built-in collection of nodes, pods, operators, and cluster metrics remains active.

To start using MetricSource:

  1. Create a MetricSource resource defining the Kubernetes resource to collect and the fields to extract
  2. Grant access via MonitorAccessPolicy using the resourceTypeName from your MetricSource's rbac section
  3. Query collected data through the new /api/v1/custom-types endpoints

Important: The frontend will NOT be released as default for MetricSource as it is a breaking change. To see MetricSource integrated with the frontend, you must add this to the ClusterPulse CRD:

spec:
frontend:
image: 'quay.io/clusterpulse/ui:v0.3.0'

Eventually, the old method will be deprecated. Until then, it is optional.

New API endpoints

Endpoint Description
GET /api/v1/custom-types List available custom resource types
GET /api/v1/custom-types/clusters Resource counts and aggregations across clusters
GET /api/v1/clusters/{cluster}/custom/{type} Collected resources for a specific cluster

RBAC integration

MetricSource integrates with the existing policy system. Custom resource types use implicit deny — users only see types explicitly granted in their MonitorAccessPolicy. Aggregations can be automatically recalculated to reflect only the resources a user is permitted to see.

What's next

In a future release, built-in resource collection will be migrated to MetricSource definitions, providing a single, consistent collection model. Recommend adopting MetricSource now for any new monitoring requirements to ease that transition.

For details, see:

Assets 2
Loading