Gains:
- Ability to understand the basic objects (Pod, Deployment, Service, ConfigMap, Secret, Namespace) and declarative philosophy of Kubernetes and produce solid manifests for artificial intelligence
- Ability to make manifests ready for production and secure with resource limits, health checks (probes), fixed image tags and narrow RBAC
- Ability to verify correct context before execution and apply dry-run discipline with dry-run/diff
It is easy to run one container. But establishing a system that spreads hundreds of containers across dozens of servers, automatically restarts when one of them crashes, replicates it when the load increases, and updates it with zero downtime? That's orchestration, and the industry standard tool is Kubernetes (K8s for short) — the platform that automatically deploys, scales, and manages containers across a cluster. Kubernetes is powerful but complex: everything is defined by long, indentation-sensitive YAML files — called manifests. This is where AI gives a breath of fresh air; With the right context, it quickly produces these manifests and decodes their mysterious errors.
But in Kubernetes, a wrong manifest means failing to stand up an entire service, scaling incorrectly, or leaving a vulnerability. It is your responsibility to understand and verify each manifest the AI produces — especially before kubectl apply.
Kubernetes core objects
To audit Kubernetes, you should know the main concepts:
- Pod: Smallest working unit; It contains one or several containers. Generally, the Pod is not used directly, but the parent objects that manage it are used.
- Deployment: Defines how many copies of an application will run, which image it will use, and how it will be updated. If a Pod crashes it will automatically recreate it.
- Service: Provides a fixed network address and load balancing to the pods; Even though pods come and go, the access address does not change.
- ConfigMap and Secret: Keeps configuration values and secret information separate from Pods. ConfigMap is for explicit settings, Secret is for sensitive values.
- Namespace: The area that logically divides and isolates resources (e.g. dev, prod).
- Ingress: The rule set that directs HTTP traffic from the outside world to services in the cluster.
Helm is the "package manager" of Kubernetes: it allows you to template recurring manifests (charts) and install them with different values in different environments with a single command. AI produces both raw manifest and Helm chart.
Why are there so many objects? Because the core philosophy of Kubernetes is declarative: you define "how you want the system to ultimately look" (e.g. "always have 3 copies of this application running"), while Kubernetes continually moves the current state closer to that desired state. If a Pod dies, it creates a new one; if a node goes down, it moves the workload to another node. That's why manifests are not "do" commands, but "let it be like this" recipes. Grasping this distinction is critical when reading the manifests that AI produces: each domain describes part of the desired state of the system. A wrong domain means Kubernetes is working towards a wrong goal — and that goal is silently, persistently enforced.
Tip: In Kubernetes, the most important safe testing tool is kubectl apply --dry-run=server -f file.yaml: it shows whether the server will accept and what to do without actually applying the manifest. Be sure to run dry-run and kubectl diff before applying a manifest to prod.
Step by step: Creating manifests with AI
- Describe the application and need. Image name, port, how many replicas, resource limits (CPU/memory).
- Request Deployment + Service. Usually both are required together.
- Separate config and secret. Settings to ConfigMap, sensitive values to Secret.
- Add health checks. livenessProbe (is it live) and readinessProbe (is it ready for traffic) are critical.
- Set a resource limit. Without requests/limits a Pod can consume the entire node.
- Verify with `--dry-run` and `diff`, then apply. First in the test namespace.
Security: Kubernetes-specific risks
- Secret isn't really secret — it's just base64. The Kubernetes Secret object base64 encodes values; This is not encryption, it is easily decrypted. For true privacy, etcd encryption and external vault (Vault, cloud secret manager) are required. Never commit secret manifests directly to Git (there are solutions for this such as Sealed Secrets/External Secrets).
- Set a resource limit. A Pod without limits can crash the entire node with a memory leak.
- Minimum authority (RBAC). With Role-Based Access Control, each service/user has only the permissions it needs. AI sometimes gives large cluster-admin; narrow this down.
- Do not use the `latest` image tag. You don't know which version is running and you can't roll it back.
Caution: kubectl delete or an incorrect apply can destroy a live Deployment. Be sure to verify which namespace you are in (kubectl config current-context) before running the commands; Accidental work is a common disaster in the production context.
Raw manifest vs. Helm table
criterion
Raw YAML manifest
Helm chart
Installation
kubectl apply -f
helm install
Multimedia (dev/prod)
Copy-paste, error prone
Single chart, different values.yaml
Version/rollback
by hand
easy with helm rollback
Learning curve
low
medium
when
Small, single environment
Multi-media, repetitive service
three mini cases
Case 1 — the secret of the crashed service. A Pod was constantly rebooting (CrashLoopBackOff). The team gave the logs and manifest to the AI; The AI showed that the Pod was never considered "ready" because the readinessProbe was looking at the wrong port. They fixed the port, the service became stable in 10 minutes. Establishing this relationship manually could take hours.
Case 2 — not setting limits broke the knot. There were no limits in a Deployment; A memory leak bloated the Pod and crashed the entire node, bringing down neighboring services as well. After the incident, they made AI say "add reasonable CPU/memory requests and limits to all Deployments" and made it standard. One missing line cost hours of downtime.
Case 3 — large RBAC captured. During an investigation, a ServiceAccount manifest generated by AI was found to be tied to the cluster-admin role — meaning that service could manage the entire cluster. The team narrowed the permission to only reading Pods in their namespace. The principle of least privilege closed a security vulnerability.
Four copyable templates
1) Deployment + Service production:
Write a Deployment and Service manifest for Kubernetes. Application: [AD], image: [image: fixed-version], port: [X], replica: [N]. Rules:- Add CPU/memory requests and limits.- Define livenessProbe and readinessProbe.- Read configuration from ConfigMap, secret from Secret object; Do not embed values in the manifest, use placeholders. - DO NOT use image tag ":latest". Give with description.
2) Manifest error solving:
The current Pod is in [CrashLoopBackOff / Pending / ImagePullBackOff] state. According to the following manifest and 'kubectl describe' output, list the possible root causes in order of probability and issue the verify command for each. Manifest: [YAML] Describe: [OUTPUT]
3) Security/integrity check:
Check this Kubernetes manifest: is the resource limit missing, is it missing prob, is there a :latest tag, is there an overly broad RBAC/permission, is the secret embedded in the manifest? Write the findings in order of importance and with correction. Manifest: [YAML]
4) Conversion to Helm chart:
Convert the following raw manifests into a reusable Helm chart: which values should go out to values.yaml (image, replica, source, environment)? Show chart structure and sample values.yaml.Manifests: [YAML]
Weak prompt / Strong prompt
Weak: "Write Kubernetes YAML for my application."
Result: a no-probe, no-limit Deployment with :latest tag, embedding the secret plain; Insecure and fragile in prod.
Strong: "Write Kubernetes Deployment + Service. Image myapp:1.4.2, 3 replicas, 8080 ports. CPU 100m-500m, memory 128Mi-512Mi add requests/limits. Put liveness probe for /healthz, readiness probe for /ready. Read the Secret from the Secret object, don't embed it in the manifest. Give with description."
Difference: second prompt version gives scale, resource limits, health checks and secret rule; The output is close to production and safe.
Common mistakes
- Not setting resource limits. A single Pod can consume the entire node.
- Not adding a health check (probe). Kubernetes cannot detect a crashed/not ready Pod.
- `:latest` tag. It becomes unclear which version is running, it cannot be rolled back.
- Committing the secret directly to Git. Base64 is not encryption; everyone solves it.
- Running commands in wrong context/namespace. The most common way to crash in prod.
- skipping `--dry-run`/`diff`. Not seeing what will happen before implementation.
In summary
Kubernetes is a powerful but complex orchestrator that automatically deploys, scales, and optimizes containers across a cluster; Everything is defined by manifest YAMLs, which Helm templatizes. AI quickly produces Deployment/Service manifests and Helm charts, solves mysterious bugs — but you have to explicitly ask for resource limit, health check, immutable image tag, narrow RBAC and secret security rules. --dry-run, diff and correct context checking are habits that prevent prod crashes.
Application task
Have AI generate a manifest for a sample application with the "Deployment + Service generation" template. Then: (1) Have it checked for resource limit, probe, :latest, and secret with the "Security/sanity check" template; (2) run kubectl apply --dry-run=server on a test cluster/minikube if possible and read the output; (3) note the two most critical safety/robustness items you find missing.
checklist
- [ ] I added the image version, number of replicas, port and resource limits to my request.
- [ ] I added liveness and readiness probe to the manifest.
- [ ] Image tag fixed; I didn't use :latest.
- [ ] Secret is not embedded in the manifest; I used Secret object/external vault.
- [ ] I narrowed down RBAC/permissions to minimal permissions.
- [ ] Before applying, I verified that I was in the correct context and that --dry-run/diff outputs.