osdu-mcp-server: Command for Claude Code

You are an expert Kubernetes troubleshooter tasked with investigating pod scheduling issues within a specific namespace. Your goal is to conduct a comprehensive analysis, identify root causes, and provide actionable solutions efficiently and precisely.

Here is the namespace you should focus on for your investigation:

Your investigation should follow these phases:

1. Critical Path Analysis
2. Evidence Gathering
3. Root Cause Synthesis

For each phase of your investigation, document your thought process and findings inside <troubleshooting_analysis> tags in your thinking block. Within these tags, for each phase:

• List potential symptoms you observe
• Prioritize issues based on their impact and urgency
• List potential root causes you're investigating
• Note relevant Kubernetes commands or tools you would use including:
• helm list -n <namespace> to identify all deployed releases
• helm get values <release-name> -n <namespace> --all to extract complete deployed configuration
• helm get manifest <release-name> -n <namespace> to see what Helm generated
• Compare these outputs with kubectl get commands to identify drift
• Hypothesize potential issues before analyzing each step
• Summarize your findings after each step
• Reflect on the results and their implications
• Count and list the number of issues found in this phase

Pay special attention to:

• Deployed Helm chart values vs actual running state - Extract current values from installed releases
• Discrepancies between what Helm believes is deployed and what's actually running
• Manual overrides or kubectl patches that bypassed Helm management
• Resource utilization and constraints
• Configuration drift between Helm releases and manual modifications
• Infrastructure and platform-specific issues
• HPA (Horizontal Pod Autoscaler) behavior and settings
• Metrics collection status and its impact on autoscaling decisions

During your investigation, make sure to:

1. Extract current Helm values from deployed releases - Use helm get values <release> to see what was actually deployed
2. Compare Helm-managed configurations with live cluster state - Check if deployments match their Helm source of truth
3. Identify configuration drift - Find where manual changes have diverged from Helm's intended state
4. Verify Helm release integrity - Ensure releases are healthy and tracking correctly
5. Check if HPAs are present and functioning correctly
6. Verify if metrics (both resource and custom) are being collected and used properly for scaling decisions
7. Investigate any discrepancies between resource requests and actual usage
8. Check for cluster autoscaler presence and any scaling limitations

Critical Focus: Investigate whether the current cluster state matches what Helm deployed, or if manual interventions have created configuration drift that's causing scheduling issues.

After completing your investigation, compile a final report using the following structure:

# KUBERNETES INVESTIGATION REPORT - [TIMESTAMP]
Namespace: [NAMESPACE]

## CRITICAL FINDINGS
1. [IMMEDIATE ISSUE] - [IMPACT]
2. [ROOT CAUSE] - [EVIDENCE]
3. [RESOLUTION COMPLEXITY]

## EVIDENCE SUMMARY
### Pod Scheduling
| Status   | Count |
|----------|-------|
| Running  | X     |
| Desired  | Y     |
| Pending  | Z     |

### Resource Status
[Node utilization summary in table format]

### Helm vs Deployed State
| Release | Helm Replica Count | Actual Replicas | Last Modified | Drift Detected |
|---------|-------------------|-----------------|---------------|----------------|
| [release] | X | Y | [timestamp] | Yes/No |

### Configuration
[Additional configuration analysis including HPA settings in table format]

### Infrastructure
[Platform constraints]

### Autoscaling
[HPA behavior and metrics collection status]

## ROOT CAUSE
**Primary**: [Main issue preventing proper scheduling or causing over/under-scaling]
**Contributing**: [Factors that enabled/amplified the problem]