Feature Request: Cross-Cluster Event Aggregation (karmada-event-aggregator)

[Kevinz857]

Summary

Request for a new component karmada-event-aggregator to aggregate Kubernetes events from member clusters and expose them through Karmada control plane, similar to how karmada-metrics-adapter works for metrics.

Motivation

Currently, Karmada provides excellent multi-cluster resource management and metrics aggregation capabilities. However, there's no built-in mechanism to aggregate events from member clusters, which creates challenges for:

1. Application Monitoring: Business applications using client-go Informers to watch Pod events (evictions, restarts, failures) cannot see events from member clusters through Karmada's kubeconfig
2. Operational Visibility: Operators lose visibility into application-level events happening in member clusters
3. Code Migration: Existing applications with event-based logic require significant changes to work with multi-cluster setups

Current Workarounds and Limitations

Current State:

• Karmada only exposes federation-level events (scheduling, binding, sync operations)
• Member cluster events (Pod evictions, container restarts, etc.) are not accessible through Karmada control plane
• Business code needs to maintain separate connections to each member cluster

Existing Workarounds:

1. Multi-cluster client code: Requires significant application changes
2. Search API: Available but requires code modifications and is not optimized for event streaming
3. Direct member cluster access: Breaks the unified control plane abstraction

Proposed Solution

Implement karmada-event-aggregator following the same architectural pattern as karmada-metrics-adapter:

Architecture Components:

1. EventProvider: Aggregates events from member clusters using MultiClusterInformerManager
2. APIService Registration: Exposes events through standard Kubernetes Event API (/api/v1/events)
3. Cross-cluster Event Correlation: Adds cluster source annotations to events
4. Event Filtering: Configurable filters to avoid overwhelming the system

Key Features:

• Zero Business Code Changes: Existing client-go Informer code works unchanged
• Unified Event View: Single API endpoint for events across all member clusters
• Cluster Source Tracking: Events annotated with originating cluster information
• Performance Optimized: Built-in filtering and caching mechanisms

Implementation Plan

Phase 1: Core Functionality

• Implement EventProvider using existing MultiClusterInformerManager
• Create event aggregation logic with cluster source annotations
• Implement APIService for /api/v1/events endpoint
• Basic RBAC and deployment manifests

Phase 2: Production Features

• Event filtering and rate limiting
• Integration with karmadactl addons enable karmada-event-aggregator
• Comprehensive testing and documentation
• Performance optimization for high-volume environments

Phase 3: Advanced Features

• Event correlation across clusters
• Custom event processing pipelines
• Integration with observability tools

API Design

The aggregated events should be accessible through standard Kubernetes Event API:

  # List events in namespace across all clusters
  kubectl get events -n my-namespace

  # Watch events with client-go Informer (no code changes needed)
  informer := factory.Core().V1().Events().Informer()
  informer.AddEventHandler(eventHandler)

  Events would include cluster source information:
  apiVersion: v1
  kind: Event
  metadata:
    name: pod-evicted
    namespace: my-namespace
    annotations:
      resource.karmada.io/query-from-cluster: "member-cluster-1"
  involvedObject:
    name: my-pod
    namespace: my-namespace
  reason: Evicted
  message: "Pod evicted due to resource pressure"

Benefits

1. Seamless Migration: Existing applications work without code changes
2. Unified Operations: Single point for monitoring events across clusters
3. Consistent Architecture: Follows established Karmada patterns
4. Enhanced Observability: Better visibility into multi-cluster application behavior

Use Cases

• Application Health Monitoring: Monitor Pod events for restart patterns and failures
• Resource Management: Track eviction events for capacity planning
• Troubleshooting: Centralized event logs for debugging distributed applications
• Alerting Systems: Event-driven alerting across multiple clusters
• Compliance: Audit trails for events across the entire federation

Related Work

• Similar to karmada-metrics-adapter for metrics aggregation
• Complements existing search API functionality
• Builds on proven MultiClusterInformerManager infrastructure

Additional Context

This feature would complete Karmada's observability story by providing:

• ✅ Resource Management (existing)
• ✅ Metrics Aggregation (karmada-metrics-adapter)
• ❌ Event Aggregation (this proposal)

The implementation can leverage existing Karmada infrastructure and follow established patterns, making it a natural extension of current capabilities.

---

Would you like me to adjust any part of this issue description or add additional technical details?

[RainbowMango]

Firstly, thank you very much for this elaborate proposal, impressive!

Before diving into the discussion of the proposal, I hope you try some features of Karmada, which are designed for scenarios like yours.

For the Events, I'd like to recommend the Karmada search, which is a component that caches resources grabbed from member clusters and exposes them in a Kubernetes-native way. See Use Karmada-search to experience multi-cloud search for more details.

Looking forward to any feedback~

[RainbowMango]

/close Please feel free to leave comments here if you have any further questions.

[karmada-bot]

@RainbowMango: Closing this issue.

In response to this:

/close Please feel free to leave comments here if you have any further questions.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.