Kubernetes for infrastructure as code
Infrastructure as code is about declaring desired state and applying it through pipelines, and the hardest part to verify is whether an applied change produced the runtime you intended. This native Kubernetes and OpenShift server is our third pick of four because it answers that question directly: it reads the live cluster so an agent can confirm what an IaC change actually did.
It ranks third because it sits at the verification end, not the authoring or gating end, of an IaC workflow. Spacelift manages and applies the changes, and Argo CD reconciles declared state against the cluster. This server is where an agent looks once a change lands to check live resources against the spec.
How Kubernetes fits
After a pipeline applies a manifest, an agent can use pods_list and pods_list_in_namespace to confirm workloads scheduled, pods_get to inspect a specific resource, and events_list to catch warnings or failed rollouts the apply did not report. configuration_view shows which context the agent is reading. nodes_top, pods_top, and nodes_stats_summary check whether the new state fits within node capacity, and nodes_log helps when a node-level problem blocks the rollout.
The honest gap: this server does not author IaC, run a plan, or gate an apply, and the tools here read and operate pods and nodes rather than diffing your declared manifests against the cluster. Spacelift is the stronger pick for managing and applying changes with policy gates. Argo CD fits better when GitOps reconciliation, comparing Git-declared state to what is deployed, is the core need. Docker covers the image and local-runtime layer beneath. Use this server as the runtime-truth check that closes the loop after an IaC change is applied.
Tools you would use
| Tool | What it does |
|---|---|
| configuration_view | Get the current Kubernetes configuration content as a kubeconfig YAML (minified to the current context by default). |
| events_list | List Kubernetes events (warnings, errors, state changes) for debugging and troubleshooting in the current cluster. |
| namespaces_list | List all the Kubernetes namespaces in the current cluster. |
| nodes_log | Get logs from a Kubernetes node (kubelet, kube-proxy, or other system logs) via the node's proxy endpoint. |
| nodes_stats_summary | Get detailed resource usage statistics from a node via the kubelet's Summary API. |
| nodes_top | List the CPU and memory consumption of nodes as recorded by the Kubernetes Metrics Server. |
| pods_list | List all the Kubernetes pods in the current cluster across all namespaces. |
| pods_list_in_namespace | List all the Kubernetes pods in a specified namespace. |
| pods_get | Get a Kubernetes pod by name in the current or provided namespace. |
| pods_delete | Delete a Kubernetes pod by name in the current or provided namespace. |
FAQ
- Can this server apply my Terraform or Helm changes?
- No. It reads and operates a live Kubernetes or OpenShift cluster through the API; it does not run an IaC plan or apply. Spacelift gates and applies changes, and Argo CD reconciles declared state. This server verifies the runtime result with tools like pods_list and events_list after the apply.
- How does it help confirm an IaC change worked?
- It reads the cluster directly. pods_list and pods_get show whether workloads scheduled, events_list surfaces rollout warnings or errors, and nodes_top and pods_top confirm the change fits within capacity, so an agent can compare the live state to what the change was meant to produce.