The Helm install can be one command. The deployment is not.

Running AI agents on Kubernetes means operating a stateful, tool-using application whose usefulness depends on databases, secrets, external APIs, storage, ingress, TLS, observability and failure recovery. The container is only one piece.

This guide is a production-oriented deployment model for AI agents on Kubernetes. It keeps the central lesson from our original DEV.to field note “the honest one-command version” but expands it into a reusable architecture that applies beyond one chart or one cluster.

Should you deploy AI agents on Kubernetes?

Kubernetes is a good fit when you already have platform engineering capability and need self-hosted deployment, standardized identity and network policy, multiple runtime services, stateful dependencies, horizontal scaling, GitOps or portable infrastructure.

It is usually not the fastest first deployment for a small stateless agent. If a managed runtime or simple container service satisfies your reliability and compliance requirements, extra cluster complexity may not create value.

The complete Kubernetes deployment path

container image → namespace → secrets → database/storage → runtime deployment → service → ingress → TLS → DNS → health checks → observability → backup → rollout policy

Helm can package many of those resources. It cannot magically provide every cluster capability they depend on.

1. Containerize the agent runtime correctly

The runtime image should be immutable, versioned and able to start without local state assumptions.

• pin application dependencies;

• run as a non-root user when possible;

• expose readiness and liveness endpoints;

• handle termination signals gracefully;

• do not persist business state only to the container filesystem;

• make model/provider configuration external.

2. Create an isolated namespace and service identity

Use a dedicated namespace for the agent platform or workload. Give workloads explicit service accounts and the minimum RBAC required.

An agent that can use business tools should not inherit broad Kubernetes permissions merely because it happens to run in the cluster.

3. Handle secrets as infrastructure

API keys, database credentials and signing secrets need a production secret-management path. Kubernetes Secrets are an interface, not by themselves a complete secret-management strategy.

Depending on the environment, secret material may be synchronized from a cloud KMS/secret manager or managed through an operator. Rotation and auditability matter more than whether the value ultimately appears as an environment variable.

4. Decide where durable state lives

AI agents often need more persistence than a typical stateless API:

• sessions and conversation events;

• workflow/run records;

• long-term memory;

• documents or artifacts;

• queue/event state;

• vector or relational data.

Do not confuse Kubernetes restartability with application durability. A pod restarting cleanly does not help if the agent’s state existed only inside the pod.

For the recovery model itself, see AI agent state management.

5. Storage classes and persistent volumes are cluster-specific

A Helm chart may request a PersistentVolumeClaim. Whether that claim can actually bind depends on the cluster’s storage class and provisioner.

• verify that a default or explicit StorageClass exists;

• confirm access modes;

• check capacity and volume expansion;

• verify snapshot/backup support;

• define restore procedures for stateful components.

6. Install the runtime with Helm but inspect the values first

A production install should use a versioned values file rather than a long command copied from a tutorial.

helm upgrade --install apowerb oci://REGISTRY/apowerb-chart \
  --namespace apowerb \
  --create-namespace \
  -f values.production.yaml

helm upgrade --install apowerb oci://REGISTRY/apowerb-chart \
  --namespace apowerb \
  --create-namespace \
  -f values.production.yaml

The command is intentionally illustrative: use the current ApowerB chart registry, chart version and documented values when you deploy.

A useful production values file should make explicit image version, replicas, resource requests/limits, database topology, storage, ingress host, TLS, secret references, autoscaling and observability endpoints.

7. Ingress, TLS and DNS are three separate things

An Ingress object does not create an ingress controller. A TLS block does not install cert-manager. A hostname in YAML does not create a DNS record.

DNS → load balancer / ingress controller → Ingress rule → Kubernetes Service → runtime pod

8. Readiness matters more than “the pod is running”

A runtime can be alive while still unable to serve useful agent traffic because its database is unavailable, migrations are incomplete or required dependencies cannot be reached.

• liveness: should Kubernetes restart the process?

• readiness: should this pod receive traffic?

• startup: does this service need extra initialization time?

9. Treat model APIs and tools as dependencies with failure modes

The cluster can be healthy while a model provider returns 429s or a business API times out. Runtime-level timeouts, backoff and tool-aware retry policy belong above Kubernetes.

This is the key boundary: Kubernetes restarts processes; the agent runtime decides whether repeating an agent action is safe.

10. Observability needs agent semantics

CPU and memory graphs are necessary but insufficient. Production agent operations also need run IDs, user/tenant attribution, model calls, tool calls, token/cost signals, state transitions, approval events and replay status.

See AI observability for the application-level layer.

11. Scaling AI agents is not only replica scaling

HTTP request volume may be only one pressure signal. Long-running work can be limited by worker concurrency, model-provider quotas, queue depth, tool latency, database connections and token spend.

Scale the bottleneck you can measure. Adding pods does not fix an external 429 limit.

12. Backups and upgrades need state-aware procedures

Before a production upgrade, know which data must survive, how schema migrations run, whether writes need to pause, how rollback interacts with the database schema, and how backups are restored—not merely created.

Deploy the open-source runtime on infrastructure you control

ApowerB is designed for self-hosted agent workloads and includes deployment artifacts for the runtime stack.

The honest “one-command” checklist

Production deployment sequence

1. Choose the cluster and namespace.

2. Verify StorageClass and capacity.

3. Verify ingress controller.

4. Verify certificate management.

5. Prepare DNS and hostname.

6. Provision secrets.

7. Decide database topology and backups.

8. Review Helm values and pin versions.

9. Install into staging first.

10. Verify migrations, readiness and tool connectivity.

11. Enable metrics, traces and logs.

12. Test pod restart and node disruption.

13. Test backup restore.

14. Promote with a controlled rollout.

Security controls specific to agent workloads

Kubernetes gives you strong infrastructure primitives, but agent workloads introduce an extra trust problem: untrusted content can influence tool selection.

• workload identity and least-privilege RBAC;

• network policies and egress controls;

• separate credentials per integration;

• tool-level authorization inside the runtime;

• human approval for high-impact writes;

• audit logs for tool actions;

• sandboxing for code execution.

Where ApowerB fits

ApowerB provides the application/runtime layer that Kubernetes does not: agent execution, application state, model/tool integration and the wider agent platform. Kubernetes supplies the infrastructure control plane underneath it.

The original deployment field note contains the concise chart-oriented walkthrough and practical traps we encountered: read it on DEV.to.

For the broader runtime architecture, see production-ready AI agents.

The practical takeaway

The command that creates Kubernetes objects can be one line. Production readiness is everything that makes those objects useful after the command finishes.

Kubernetes should recover the infrastructure. The agent runtime should recover the work.