I've tried all the major assistants for generating K8s YAML. Most are useless for anything beyond a basic nginx pod. They hallucinate API versions, mess up indentation, and can't handle complex multi-resource manifests.
What's your actual experience? I need something that gets Ingress, NetworkPolicies, and ServiceAccount bindings correct on the first try. Not just a skeleton. Which model and version gave you production-ready configs?
show me the logs
Your frustration with hallucinated API versions is spot-on. I've found Claude 3.5 Sonnet to be the most consistent for multi-resource definitions, but only after I built a custom system prompt with my cluster's specific constraints. It still requires guardrails.
For NetworkPolicies and Ingress, I've had better results generating a Kustomize base or a Helm template stub, rather than a flat YAML file. The assistants are better at structuring the *logic* (selectors, rules) than producing the final, static manifests. I feed it my existing SecurityContextConstraints and let it mirror the patterns.
What's your target Kubernetes version? The API deprecations between 1.24 and 1.27 are where most models fall apart without explicit version locking.
infrastructure is code
I've been down this exact rabbit hole. You're right about the API version hallucinations - I wasted a whole afternoon once because a model generated a v1beta1 Ingress for a cluster running 1.22+. Not fun.
My current workflow uses GPT-4 Turbo with a very specific starter prompt. I don't ask for a full manifest. I ask it to generate a "snippet" for each specific resource type, one at a time, and I explicitly state the Kubernetes version in the first line. For example: "Generate a NetworkPolicy snippet for Kubernetes 1.27+ that allows only internal pod-to-pod traffic on port 8080." This forces it to scope down and pull the correct API. Then I assemble the pieces in my own template.
Even then, I always run it through `kubeval` and a dry-run with `--server-side`. The real trick is providing the model with an actual, working YAML example from your own repo as a reference pattern first. It's much better at mimicking a structure than inventing one from scratch.
test everything twice
> The real trick is providing the model with an actual, working YAML example from your own repo as a reference pattern first.
This is such a solid tip. I've had almost identical success with this "reference pattern" method, but I extend it one step further. I keep a snippets library of validated, version-locked resource definitions in a separate markdown file. Before I ask the model for anything new, I paste in the relevant snippet as the "golden example" and ask it to mirror the style and structure for my new requirements.
It cuts down on the back-and-forth dramatically. Have you found that older, stable models sometimes perform better than the latest GPT for this specific task? I sometimes get more predictable results from a model that's been trained on a corpus with older, well-established examples, versus a newer model that's trying to be too clever.
Keeping a "golden example" snippet library just to get an AI to output correct YAML feels like an admission of defeat. You're describing a linter.
Older models are less likely to invent new API fields, sure. But the real problem is asking a language model to do a job that's fundamentally about precision, not language. You're already doing the validation work yourself with kubeval and dry-runs. At that point, the AI is just a more cumbersome autocomplete for copying your own snippets.
Keep it simple
> I keep a snippets library of validated, version-locked resource definitions in a separate markdown file.
I get the appeal, I really do. But you've just traded one kind of overhead for another. Now you're maintaining a shadow documentation repo to prop up a tool that can't remember its own outputs.
There's a free alternative that actually gets this right, and it's not an AI model. Have you tried using `kubectl explain` with a shell alias or a fuzzy finder? It pulls definitions directly from your cluster's API. Zero hallucinations, perfect version compliance. Pair that with a straightforward YAML templating tool, and you've got a deterministic system that doesn't need you to feed it its own homework first.
FOSS advocate