Onboarding a Service to EKS with an Agent

The goal

A new microservice repo lands. The agent reads the repo structure, identifies the runtime, infers resource requirements from existing services, generates all Kubernetes manifests (Deployment, Service, HPA, ServiceAccount, Ingress/HTTPRoute), opens a PR, and after approval applies them to the cluster.

No human writes YAML. The agent does it, a human reviews, and the agent applies. That was the goal.

What worked

Reading the repo The agent correctly identified the runtime (Node.js, Go, Python), the exposed port from the Dockerfile, and the service name from package.json / go.mod.

Generating Deployment and Service Basic manifests were correct on the first try. Image tag set to latest with a comment noting it should be pinned in CI.

Referencing existing patterns The agent read similar services already in the cluster and matched their label conventions, namespace, and resource bracket.

Opening the PR PR created with a summary of what was generated and why each decision was made. Reviewable.

What didn't work

Secrets The agent had no way to know what secrets the service needed. It generated a placeholder SecretKeyRef with a TODO. Every service needs this done manually before deploy.

Resource limits Inferred from similar services, but the inference was often wrong. A CPU-heavy data processor got the same limits as a lightweight API proxy. The agent had no load data to reason from.

HPA targets HPA was generated, but the target metric (CPU %) was guessed. Works as a starting point, needs tuning after first load test.

Applying after approval The "apply after PR merge" step was never completed. The agent could detect when a PR was merged but the apply flow had the dry-run bug (bug #07 from the 8 bugs post) — it applied immediately without dry-run validation.

What's left

Secrets integration Connect to the secrets store (External Secrets / AWS SSM) so the agent can check existing secret definitions and reference them correctly.

Safe apply after review Apply gate: dry-run → show diff → wait for explicit confirm → apply → watch rollout. All steps need to be in the loop before this is production-safe.

Rollout monitoring After apply, the agent should watch the rollout and report back. Today it fires and forgets.

The honest take: the manifest generation is good enough to save 80% of the manual work. But the last 20% — secrets, correct limits, safe apply — is where the risk is. Saving a human from writing YAML is useful; removing the human from the apply step isn't ready yet.