Running AI Agents on Kubernetes

An agent is a long-running workload that needs supervision. Kubernetes restarts it when it fails, caps its CPU and memory, injects credentials at runtime instead of baking them into code, and describes the setup in reviewable manifests. It also lets you control the agent's network access and identity from outside the agent, where a prompt cannot change the rules.

The mechanics are the same: an agent is usually a process that serves HTTP. The difference is risk. A service follows its code, while an agent follows a model whose next action depends on whatever is in its context, and it often holds credentials and can act. Steps that are optional hardening for a normal service, such as secrets handling, resource limits and egress control, are essential for agents.

Containerize the agent, create a Kubernetes Secret for its API key, write a Deployment with resource requests and limits and health probes, expose it with a Service, and add a default-deny NetworkPolicy with only the egress it needs. You can practise all of this on a local kind cluster.

Not in the image or the repository. Use a Kubernetes Secret at minimum, with encryption at rest and RBAC limiting who can read it. For production, sync secrets from a store using External Secrets Operator, Vault Secrets Operator or a cloud secret manager, and prefer workload identity so pods get short-lived credentials instead of long-lived keys.

Use a default-deny egress NetworkPolicy and allow only what the agent needs, such as DNS and HTTPS. Plain NetworkPolicy matches IPs and ports, so it cannot name allowed domains. For that, use a DNS-aware policy engine such as Calico or Cilium, or route agent traffic through an egress gateway.

No. An agent is usually orchestration code that calls a model over an API, so ordinary nodes are enough. You only need GPU nodes if you host the model yourself, which is a separate project covered by model-serving tools.

Set CPU and memory requests so the scheduler can place pods, then use the Horizontal Pod Autoscaler on resource or custom metrics, or KEDA to scale on queue length or events. Run scheduled or one-off agent tasks as Jobs or CronJobs, and put limits on each pod so a looping agent cannot starve a node.

Combine controls: run as non-root with a restricted security context, apply Pod Security Standards, add admission policy with Kyverno or OPA Gatekeeper, and run code the agent generates in an isolated sandbox such as the Kubernetes Agent Sandbox project, gVisor or Kata Containers. Turn off automatic service account token mounting when the agent does not call the Kubernetes API.

This page is about deploying and securing your own agent as a workload. AI Agents on Kubernetes Clusters covers Kubernetes-native agent runtimes such as kagent, agents that operate the cluster, Kubernetes MCP servers and model serving.

It was inspired by Tigera's beginner guide to AI agents on Kubernetes, published in September 2026, and by the official Kubernetes, security and framework documentation linked here. Links were checked in November 2026, and sites that block automated checks may need a manual click. This is a resource list, not engineering advice.