← All one-liners·#055·Infrastructure & Ops·llm cli·power

Evaluate Kubernetes Node Scaling with LLM

Pipes Kubernetes node resource utilization metrics into an LLM to analyze cluster provisioning and suggest instance type optimizations.

Setup
  • → kubectl configured with cluster access
  • → metrics-server installed in the Kubernetes cluster
  • → Simon Willison's 'llm' CLI installed
  • → OpenAI API key configured for 'llm'
Cost per run
Minimal API cost per query (~$0.01)
The one-liner
$ kubectl top nodes | llm -m gpt-4o "Analyze this node utilization. Are we over-provisioned or under-provisioned? Suggest instance type changes."
What each stage does
  1. [01] kubectlkubectl top nodes
    Fetches current CPU and memory utilization metrics for all nodes in the Kubernetes cluster.
  2. [02] bash|
    Pipes the tabular metrics output directly into the standard input of the LLM CLI.
  3. [03] llmllm -m gpt-4o
    Invokes the LLM CLI using the gpt-4o model to process the piped data.
  4. [04] llm"Analyze this node utilization..."
    The prompt instructing the LLM on how to interpret the metrics and what specific recommendations to provide.
Expected output (sample)
Based on the provided metrics:
- Node 1 (CPU: 12%, Mem: 45%) and Node 2 (CPU: 15%, Mem: 50%) show low CPU utilization.
- You are currently CPU over-provisioned.
Recommendation: Consider scaling down or switching to memory-optimized instances (e.g., AWS r6g.large instead of m6g.xlarge) to reduce costs while meeting memory demands.
Caveats & tips
  • Footgun: `kubectl top` only shows a point-in-time snapshot, which may not reflect peak load or daily traffic spikes.
  • Permission/Cost: Requires an active OpenAI API key which incurs usage costs, and cluster read permissions for node metrics.