Kubernetes

When should I use this?

• You run AutoObserve in production or design-partner environments on Kubernetes.
• You need deployment, rollout, and pod restart context in investigations.
• You already collect Kubernetes-aware OpenTelemetry telemetry.

Requirements

• Kubernetes cluster with deploy permissionsRequired
• Helm or operator install path (design-partner guided today)Required
• OpenTelemetry pipelines exporting cluster-scoped attributesRequired

Steps

1. Deploy to your cluster

# Design-partner installs use guided Helm values — see Helm guide for commands
# helm upgrade --install autoobserve autoobserve/autoobserve -f values.yaml

Design Partners receive guided cluster setup against real workloads. See Deploy with Helm for the chart-based install path.

2. Understand what AutoObserve correlates

AutoObserve treats Kubernetes as first-class runtime context:

• Deployments, rollouts, and image changes
• Pod restarts, OOMKills, and scheduling events
• Service topology and dependency edges
• Resource saturation (CPU, memory, connection pools) when exposed via telemetry

3. Validate against the canonical demo

In the checkout latency demo, Kubernetes restarts appear as evidence alongside the deployment that changed the connection pool — supporting the causal chain without replacing your cluster tools.

Did it work?

• AutoObserve pods running in target namespace
• Kubernetes events and deploy signals visible in investigations
• Ready to connect OpenTelemetry

Troubleshooting