Keep production AI workloads available, bounded, and ready to scale with Kubernetes

No. Kubernetes documents Pods as relatively ephemeral, and its Job documentation warns that the same program can sometimes start twice even with one completion, one replica, and a Never restart policy. A Job can retry computation; it cannot infer whether an external CRM update, document publication, payment-related action, or approval already happened. MetaCTO keeps the work item and recovery state in a durable queue or workflow system, gives every attempt a stable idempotency key, records the destination receipt, and reconciles ambiguous outcomes before retrying. Kubernetes remains the replaceable execution layer.

Deployments fit continuously available, usually stateless services such as retrieval APIs, inference gateways, and request workers. Jobs fit bounded tasks that run to completion, while CronJobs create Jobs on a schedule. MetaCTO chooses by lifecycle rather than by team convention: a service must tolerate Pod replacement and a batch task must tolerate retry or concurrency. Long-lived human approvals, multi-day timers, source-system events, and business process history stay in a workflow engine or system of record rather than inside a Pod or Job status.

The HorizontalPodAutoscaler can adjust a supported workload from observed CPU, memory, custom, or external metrics, and resource-utilization scaling depends on resource requests. More replicas do not guarantee more completed work when a model endpoint, database, queue, or vendor API is the bottleneck. MetaCTO tests concurrency and cold-start behavior, sets minimum and maximum replicas, and prefers demand signals such as queue age or safe in-flight work when they represent the workload better than CPU. We also cap downstream calls, preserve backpressure, and alert before scaling turns a dependency limit into a wider incident.

They answer different runtime questions. A startup probe can prevent readiness and liveness checks from interfering with a slow initialization; a failed readiness probe removes the Pod from matching Service endpoints; repeated liveness failure can restart the container. None of those checks proves that retrieved context is permitted, an answer is supported, a model version meets quality thresholds, or a write-back is safe. MetaCTO makes probes narrow and inexpensive, then monitors separate workflow signals such as evidence coverage, evaluation results, exception rates, queue age, confirmed writes, and reviewer corrections.

No. RBAC governs Kubernetes API access, and the project recommends namespace-scoped least privilege and avoiding unnecessary service-account token mounts. NetworkPolicy controls selected network paths only when the cluster networking implementation enforces it. Kubernetes also warns that Secret data is stored unencrypted in etcd by default unless encryption at rest is configured. MetaCTO combines dedicated service accounts, enforced ingress and egress policy, encrypted or external secret handling, and admission controls with application-level authorization for every CRM, ERP, document, model, and write action. Human approval and business authority remain outside the cluster permission model.