Orientation

This reference page catalogs the practical integration of Large Language Models and related AI techniques into DevOps and infrastructure workflows. It matters when operational toil consumes disproportionate engineering time, when log and metric cardinality exceeds human-scale analysis capabilities, or when the cognitive load of translating intent into machine syntax—YAML, Terraform, PromQL, or shell scripts—becomes a bottleneck in delivery velocity. The following sections are organized by the specific operational goal the reader is trying to accomplish, providing concrete command patterns, configuration proxies, and the failure modes that manifest in production environments.

Generating Infrastructure Code from Natural Language

A common objective is reducing the friction between human intent and machine-consumable configuration. When a team needs to spin up a new service, an LLM can bridge the gap between a descriptive requirement and the required manifest or template.

Concrete workflow: Generating a Kubernetes Deployment

The reader possesses a natural language description of the desired state. The typical pattern involves constructing an HTTP request to an LLM endpoint, piping the output through a YAML parser or validator, and applying the result.

curl -s http://localhost:11434/api/chat \
  -d '{"model":"llama2","messages":[{"role":"user","content":"Create a minimal Kubernetes Deployment yaml for an nginx server with 3 replicas exposing port 80. Include a Service of type ClusterIP also on port 80. Output only the yaml."}]}'

The response, a raw YAML string, is typically fed directly into kubectl:


kubectl apply -f -

Alternatively, if the LLM output requires schema validation against a specific provider version, the reader may interpolate the output into a terraform validate or kubeconform check before application.

Sharp edges

  • API Version Drift: The model may generate a Deployment using a apps/v1beta1 or deprecated extensions/v1beta1 API version. If the cluster is running a newer control plane, kubectl apply will reject the manifest with an InvalidSpec error. The reader must pin the model's output or post-process it with a tool that enforces the cluster's minimal supported version.
  • Hallucinated Resources: The model may invent a custom resource definition (CRD) that does not exist in the cluster's inventory, or suggest a resource attribute (e.g., a specific imagePullPolicy) that conflicts with the image registry configuration.
  • Idempotency Breaks: If the generated manifest contains metadata.generation or status fields that the LLM populates with static values, subsequent kubectl apply runs may behave unexpectedly, as the controller may interpret these as drift detection signals.

Triaging Incidents and Analyzing Logs

When an alert fires, the immediate goal is often to reduce Mean Time to Resolution (MTTR) by identifying the root cause from scattered log entries and metrics.

Concrete workflow: Filtering and summarizing pod logs

Assume a pod is in a CrashLoopBackOff state. The reader first extracts the relevant pod name and then streams the recent logs, filtering for error patterns before sending a summary to the LLM for correlation.

POD_NAME=$(kubectl get pods -l app=my-service -o jsonpath='{.items[0].metadata.name}')
kubectl logs "$POD_NAME" --previous | grep "ERROR\|fatal\|panic" | tail -n 50

The filtered output—typically a block of text—is then constructed into a prompt for the LLM. The reader does not need to understand the internal parsing logic of the model; they only need to ensure the context window contains the relevant symptoms.

curl -s http://localhost:11434/api/chat \
  -d '{"model":"llama2","messages":[{"role":"user","content":"Based on these logs, what is the most likely cause of the CrashLoopBackOff state? Respond with a single sentence root cause analysis."}]}'

Sharp edges

  • Context Truncation: LLMs have finite context windows. If the pod has been running for days and generating terabytes of logs, kubectl logs may only return the last N lines. The AI may confidently assert a cause based on the visible tail, completely missing a subtle configuration change or resource exhaustion event that occurred three hours prior but was rotated out of the visible stream.
  • Confident Misattribution: The model may attribute a failure to a common pattern (e.g., "Out of memory") even when the actual cause is a network policy timeout or a storage provisioner deadlock. Because the model's output is formatted as natural language, the reader may accept the suggestion at face value without cross-referencing Prometheus metrics or kubectl describe pod output.
  • Data Leakage Risk: Pasting raw application logs—potentially containing PIDs, internal IP addresses, or session tokens—into a third-party API endpoint creates a data leakage vector. Readers must redact sensitive fields or run logs through a local, air-gapped inference server before submission.

Translating Natural Language to Query Languages

Infrastructure operators often need to query observability backends (Prometheus, Elasticsearch, etc.) but may not recall the exact syntax for a complex query.

Concrete workflow: NL to PromQL

A reader wants to know the CPU throttling rate across all pods in a namespace over the last hour. Rather than consulting documentation, they describe the intent.

curl -s http://localhost:11434/api/chat \
  -d '{"model":"llama2","messages":[{"role":"user","content":"Write a PromQL query that calculates the rate of container_cpu_cfs_throttled_seconds_total for all pods in the 'production' namespace over the last 60 minutes. Output only the query string."}]}'

The LLM returns a PromQL string, which the reader copies into their Grafana or Prometheus UI.

rate(container_cpu_cfs_throttled_seconds_total{namespace="production"}[1m])

Sharp edges

  • Label Mismatch: The model may generate a query using labels that exist in the reader's local test environment but are absent or named differently in production (e.g., using image_name instead of image). The query will return 0 or vector(0), leading the operator down a blind alley.
  • Function Semantics: The model may use a PromQL function incorrectly (e.g., applying sum over a rate that should be aggregated per-instance vector). The resulting graph will render, but the y-axis scale and numerical values will be mathematically meaningless, potentially masking a real spike or exaggerating a transient blip.
  • Query Complexity Limits: Some observability platforms impose limits on query complexity or series cardinality. An LLM-generated query that traverses too many high-cardinality label combinations (e.g., container_id across thousands of ephemeral pods) may trigger a timeout or a "query killed" error from the backend, leaving the operator with no data and no immediate explanation why the "simple" request failed.

This page was rewritten on 14 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.