AI Coding Agents
Infrastructure
Kubernetes manifest validation before rollout
September 26, 2026 - 2 minute read
Kubernetes manifest validation has to cover more than YAML syntax. A coding agent can produce a well-formed Deployment that names an unavailable API version, conflicts with an admission policy, or takes ownership of fields managed by another controller. The useful review target is the object the cluster would accept, not just the file in the pull request.
The Kubernetes API concepts describe server-side dry run as normal admission processing without persistence. That makes it a stronger validation step than a local parser when a change is meant for a known cluster.
Scope Kubernetes manifest validation
Give the agent the manifest paths, target Kubernetes version, namespaces, overlays, and policy sources. Include the exact render command for Helm, Kustomize, or another generator. Reviewing templates without their rendered output misses values, patches, and environment-specific names.
Keep the task bounded to the reported deployment problem. The agent may correct a selector, resource request, probe, or deprecated API version. It should not reorganize unrelated charts or normalize every manifest in the repository. A focused diff lets a reviewer connect each field change to a requirement.
Factory's Droid Exec can run a scoped repository task in CI and return a nonzero exit code when validation fails. The pipeline should still own credentials and cluster selection rather than exposing broad Kubernetes configuration access to the task.
Run Kubernetes manifest validation with the API server
Render the final manifests, then submit them with server-side dry run against a non-production control plane that matches the target version and admission configuration. Capture validation errors as artifacts. This checks schema handling, defaults, mutating admission, and validating admission without storing the object.
Follow that with server-side apply dry run when field ownership matters. Kubernetes Server-Side Apply tracks which manager owns each field. A conflict can reveal that the proposed change would overwrite a value maintained by an operator or another deployment system.
Dry run cannot prove that an image starts, a dependency is reachable, or a rollout is safe under load. Run policy checks, image verification, and workload tests as separate gates. Keep each result visible so a passing schema check does not hide a failed runtime assumption.
Keep Kubernetes manifest validation evidence reviewable
The pull request should include the render command, target cluster version, changed object names, server-side validation result, and any ownership conflicts. Show the diff between the previously rendered object and the proposed object. Generated output should be reproducible from files in the branch.
Factory's automated code review can inspect the change for correctness and security issues. Repository-specific review guidelines can direct it to check selectors, probes, resource limits, and security contexts. Deterministic cluster and policy checks remain required because they reflect the actual target configuration.
Require a human decision for rollout timing, namespace scope, and production credentials. The coding agent can prepare evidence and fix a bounded defect. The deployment controller and reviewers should decide when accepted configuration reaches a live cluster.
