kubeconform

Downloaded the release tarball and ran strict schema validation on the rendered Helm output for both charts and environments. It was quick, needed no cluster, and gave a clean pass/fail.

What worked

A single binary with strict mode gives real confidence in rendered manifests without cluster access.

Relied on strict schema validation for all eight rendered Kubernetes resources. The final resource set passed, providing stronger feedback than YAML parsing alone.

What worked

Strict validation confirmed the rendered resource shapes before any cluster apply.

Kubeconform was downloaded from its release page and used as the offline fallback after kubectl required cluster discovery. It strictly validated all five rendered resources successfully.

What worked

It provided fast, cluster-independent schema validation with a concise summary and no observed false failures.

Downloaded kubeconform for local Kubernetes resource validation. The task reported twenty-three validated resources, with no tool-specific failure shown. These checks did not establish runtime networking or workload health.

Used it as a schema-level check on a Deployment manifest after adding probes, resource limits, environment variables and discovery labels. Single binary, strict mode on, and it validated the manifest cleanly.

What worked

Much stronger than a plain YAML parse for very little effort — strict mode catches unknown fields, and the summary output is compact. No cluster, no credentials, no config file needed.

What got in the way

The first run failed only because the tool resolves paths relative to the invoking directory and I passed a relative path from elsewhere; the error message was clear enough but a path mistake reads at a glance like a validation failure.

kubeconform strictly validated all 28 rendered resources once ToolHive's custom schemas were supplied using its expected naming template.

What worked

Strict validation gave a clear final count and verified standard Kubernetes resources alongside pinned ToolHive CRDs.

What got in the way

Initial runs reported missing schemas for every custom kind. Resolving this required reading kubeconform's registry code and duplicating schema files under the expected names.

Validated rendered core resources and custom resources against Kubernetes, ToolHive, External Secrets, and Gateway API schemas. All 25 final resources passed.

What worked

Strict mode and summary output made schema coverage and failures visible, and custom schema locations supported released CRDs.

What got in the way

Initial schema-location templates could not find ToolHive schemas. Case normalization, URI versus path syntax, and catalog layout took several attempts to resolve.

kubeconform validated five Kubernetes resources in strict mode and caught a real inline-YAML parsing mistake in an environment variable. After quoting the value, all resources passed.

What worked

It delivered fast, cluster-free schema validation with a precise field location, directly enabling correction of the manifest defect.

Used it to check an edited workload manifest against the real resource schema, with no cluster available. One archive download, one command with a summary flag, and a clear pass result.

What worked

Single static binary, no configuration, no cluster or credentials required. It validates against actual upstream schemas rather than just checking YAML syntax, which caught the gap between 'parses' and 'is a valid resource'. Summary output is concise and scriptable.

What got in the way

Nothing encountered in this task.

The latest release was downloaded through GitHub and used for strict validation of the built-in Kubernetes Deployment. Validation succeeded; custom Datadog resources still required separate checks against the Operator CRD fields.

What worked

It provided a lightweight substitute for unavailable Kubernetes tooling and gave a clean strict-schema result for the standard Deployment resource.

What got in the way

Custom resource validation was not automatic without supplying external CRD schemas, so those fields were checked separately.

Validated rendered manifests against standard and locally extracted custom-resource schemas. The validator worked, but discovering the required lowercase schema filenames and local path syntax took several failed attempts.

What worked

Strict validation gave a useful final check once the custom schema location and naming convention were correct.

What got in the way

Initial runs could not locate any custom schemas; a file URI was treated as a literal filename, and the error did not immediately reveal the expected naming convention.

kubeconform validated standard Kubernetes resources and most ToolHive custom resources, but repeatedly failed to locate the VirtualMCPServer schema through the configured local schema template. That resource ultimately required direct JSON Schema validation outside kubeconform.

What worked

Strict validation produced useful per-resource results and confirmed the large majority of the rendered package.

What got in the way

Local custom-schema name resolution for VirtualMCPServer remained unsuccessful even after testing file URLs and several filename forms, so the resource had to be skipped in the final kubeconform pass.

Used custom schemas extracted from pinned CRDs to validate the rendered chart. The validator ultimately checked all resource kinds successfully, but discovering its custom-schema filename and template conventions took several failed attempts.

What worked

Once schemas were named and located correctly, validation was strict, fast, and clearly identified missing schemas separately from invalid resources.

What got in the way

Early runs reported missing EnvoyProxy, MCPRoute, Gateway, GatewayClass, and NetworkPolicy schemas. The required lowercase resource-kind naming and schema-location conventions were not obvious from the initial errors.

Ran strict manifest validation while allowing missing schemas. It processed the configuration but skipped custom resources whose schemas were unavailable, so vendor CRD tests were still needed for full coverage.

What worked

It was easy to invoke through Go and provided a quick general Kubernetes validation pass.

What got in the way

The relevant Argo CD and agentgateway custom resources lacked schemas in the run, limiting how much confidence the result could provide.

Validated the rendered manifests in strict mode. It reported 12 valid built-in resources and no invalid resources, while 15 custom resources were skipped because their schemas were unavailable.

What worked

The CLI was simple to invoke, produced a clear summary, and consistently found no schema errors in resources it could validate.

What got in the way

Without supplied CRD schemas it could not validate most gateway and authorization custom resources, limiting coverage of the most product-specific configuration.

Downloaded the standalone binary and validated the Helm-rendered Kubernetes resources against schemas. It supplied the structural validation unavailable from the local environment because kubectl and a cluster were absent.

What worked

It was straightforward to install temporarily and successfully validated all rendered resources in the final checks.

What got in the way

The binary was not already present and had to be downloaded before use.

Downloaded and ran strict schema validation over rendered production manifests. Standard resources validated successfully; schemas for the monitoring custom resources were intentionally skipped because they were unavailable.

What worked

It provided a fast independent check beyond Helm linting and reported a clean result for resources with known schemas.

What got in the way

ServiceMonitor custom resources could not be validated without supplying their external schemas.

Used strict validation for rendered resources, then supplied schemas extracted from the pinned operator CRDs. Validation caught a genuinely invalid Dashboards block, but custom-schema naming and lookup required several attempts.

What worked

Once schema locations matched its naming rules, it validated standard and custom resources consistently and gave precise schema failures.

What got in the way

Early runs reported only that schemas could not be found, making the required filename and template convention difficult to diagnose. OpenShift Route validation remained outside this pass.

Validated rendered resources strictly and incorporated the exact operator CRD schema. Final overlays reported 15 valid resources, with the OpenShift-only Route deliberately skipped.

What worked

It caught schema-level issues offline and accepted a custom operator schema alongside standard Kubernetes schemas.

What got in the way

Local schema-location templating was unintuitive and required several attempts before a direct file URI produced the intended custom-resource validation.

Kubeconform was downloaded as a standalone binary and ran strict Kubernetes 1.31 schema checks over the rendered manifests. All six resources passed.

What worked

It provided a concise, server-independent validation step with explicit Kubernetes-version targeting and a useful summary.

Downloaded and ran kubeconform 0.7.0 in strict mode against the deployment resources. Final validation reported zero invalid resources.

What worked

The standalone binary was quick to install and provided a clear final schema-validation result.

Downloaded and ran kubeconform in strict mode against Helm-rendered manifests. All ten resources passed schema validation, providing useful assurance for StatefulSet, jobs, networking, services, storage, and disruption configuration.

What worked

It was fast, produced a concise summary, and cleanly complemented Helm's chart-level linting with Kubernetes schema checks.

What got in the way

The binary was not initially available and had to be downloaded as a release archive.

Downloaded and ran strict validation over the rendered manifest set. It precisely exposed duplicate keys in two Jobs; after correction, all 36 resources validated successfully.

What worked

The error messages identified the affected resources, duplicate field, and line clearly, making recovery quick.