Step 1: Confirm the scope
Determine whether the spike affects one Pod, one node, one service or the whole environment. Compare the timing of the spike with the deployment timestamp.
kubectl top pods -A kubectl top nodes kubectl get pods -A -o wide
Step 2: Compare before and after
Check the release diff: application code, configuration, environment variables, replica count, resource requests/limits and dependency changes. A new loop, expensive query or high request rate can all appear as CPU pressure.
Step 3: Check Kubernetes behavior
- Look for CrashLoopBackOff or frequent restarts.
- Check HPA behavior and replica counts.
- Compare CPU requests and limits with actual consumption.
- Check whether traffic increased at the same time.
Step 4: Decide whether to mitigate or roll back
If the release is strongly correlated and the service is degraded, follow the incident process. A rollback may be appropriate when it is the safest way to restore service while the root cause is investigated.
Step 5: Investigate the root cause
Use application logs, metrics, traces where available and profiling tools appropriate to the runtime. The goal is to identify what code path or workload behavior is consuming CPU, not simply to increase the node size.