Expected Behavior
The Service analyzer should report a Warning Event only when the Event's involvedObject identifies the Service being analyzed. The identity must include the object kind, namespace, and name.
A healthy team-a/api Service must not inherit a Warning Event for a same-name Pod, or for a same-name Service in team-b, during cluster-wide analysis.
Current Behavior
ServiceAnalyzer lists Events with involvedObject.name=<endpoint name> but uses the analysis namespace (a.Namespace) and does not constrain the involved object kind. When analysis runs cluster-wide, a.Namespace is empty, so Events from every namespace can be considered. A same-name Pod or Service can therefore add its Warning message to an unrelated Service result.
This creates false positives and can hide the actual source of a warning: the analyzer presents an Event for another Kubernetes object as if it came from the Service.
Steps to Reproduce
-
Create a Service named api in default with a ready Endpoint, so the Service itself has no endpoint failure.
-
Create an unrelated Pod named api in the same namespace and make it emit a Warning Event, for example by using an invalid image. The Event should have:
involvedObject:
kind: Pod
namespace: default
name: api
type: Warning
message: unrelated Pod warning
-
Run the Service analyzer with k8sgpt analyze --filter Service.
-
Observe that the analyzer reports the Service with the Pod's Warning Event, even though the Service has a ready Endpoint.
The same behavior occurs during cluster-wide analysis when team-a/api is healthy but a Warning Event for team-b/api exists.
The repository's fake client reproduces both cases deterministically on origin/main (05247a8):
TestServiceAnalyzerIgnoresEventsForOtherKinds returns Service default/api has event unrelated Pod warning.TestServiceAnalyzerScopesEventsToEndpointNamespace returns Service team-a/api has event unrelated Service warning.
Environment
- k8sgpt version: main (
05247a8)
- Kubernetes version: core/v1 Event and namespace-scoped Event-list semantics; not version-specific
- AI Backend/Provider: n/a
- OS/Platform: macOS / client-go fake client
Additional Context
The relevant code is in pkg/analyzer/service.go:117-130. Kubernetes defines Event.involvedObject as the object the Event is about, and Event field selectors support involvedObject.kind, involvedObject.namespace, and involvedObject.name:
A focused fix can scope the Event list to ep.Namespace and require event.InvolvedObject.Kind == "Service" before adding a failure. In an isolated temporary worktree, that two-part change made both new regression cases pass, the existing Service analyzer tests pass, go test ./... -count=1, go vet ./pkg/analyzer/, and git diff --check pass.
This Issue is limited to Event-to-Service identity. It does not change the shared util.FetchLatestEvent helper or the Pod, Job, PVC, and StatefulSet analyzers; those callers can be audited separately.
No matching open Issue or PR was found for Service analyzer, involvedObject, FetchLatestEvent, service.go, or this behavior. Closed Issue #1671 / PR #1672 concern a different Service analyzer panic caused by a nil Endpoint TargetRef.
I am willing to submit a focused PR after maintainer confirmation.
Expected Behavior
The Service analyzer should report a Warning Event only when the Event's
involvedObjectidentifies the Service being analyzed. The identity must include the object kind, namespace, and name.A healthy
team-a/apiService must not inherit a Warning Event for a same-name Pod, or for a same-name Service inteam-b, during cluster-wide analysis.Current Behavior
ServiceAnalyzerlists Events withinvolvedObject.name=<endpoint name>but uses the analysis namespace (a.Namespace) and does not constrain the involved object kind. When analysis runs cluster-wide,a.Namespaceis empty, so Events from every namespace can be considered. A same-name Pod or Service can therefore add its Warning message to an unrelated Service result.This creates false positives and can hide the actual source of a warning: the analyzer presents an Event for another Kubernetes object as if it came from the Service.
Steps to Reproduce
Create a Service named
apiindefaultwith a ready Endpoint, so the Service itself has no endpoint failure.Create an unrelated Pod named
apiin the same namespace and make it emit a Warning Event, for example by using an invalid image. The Event should have:Run the Service analyzer with
k8sgpt analyze --filter Service.Observe that the analyzer reports the Service with the Pod's Warning Event, even though the Service has a ready Endpoint.
The same behavior occurs during cluster-wide analysis when
team-a/apiis healthy but a Warning Event forteam-b/apiexists.The repository's fake client reproduces both cases deterministically on
origin/main(05247a8):TestServiceAnalyzerIgnoresEventsForOtherKindsreturnsService default/api has event unrelated Pod warning.TestServiceAnalyzerScopesEventsToEndpointNamespacereturnsService team-a/api has event unrelated Service warning.Environment
05247a8)Additional Context
The relevant code is in
pkg/analyzer/service.go:117-130. Kubernetes definesEvent.involvedObjectas the object the Event is about, and Event field selectors supportinvolvedObject.kind,involvedObject.namespace, andinvolvedObject.name:A focused fix can scope the Event list to
ep.Namespaceand requireevent.InvolvedObject.Kind == "Service"before adding a failure. In an isolated temporary worktree, that two-part change made both new regression cases pass, the existing Service analyzer tests pass,go test ./... -count=1,go vet ./pkg/analyzer/, andgit diff --checkpass.This Issue is limited to Event-to-Service identity. It does not change the shared
util.FetchLatestEventhelper or the Pod, Job, PVC, and StatefulSet analyzers; those callers can be audited separately.No matching open Issue or PR was found for
Service analyzer,involvedObject,FetchLatestEvent,service.go, or this behavior. Closed Issue #1671 / PR #1672 concern a different Service analyzer panic caused by a nil EndpointTargetRef.I am willing to submit a focused PR after maintainer confirmation.