Create production-ready Kubernetes manifests for Deployments, Services, ConfigMaps, and Secrets following best practices and security standards. Use when generating Kubernetes YAML manifests, creating K8s resources, or implementing production-grade Kubernetes configurations.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Create production-ready Kubernetes manifests for Deployments, Services, ConfigMaps, and Secrets following best practices and security standards. Use when generating Kubernetes YAML manifests, creating K8s resources, or implementing production-grade Kubernetes configurations.
version
1.1.0
model
sonnet
invoked_by
["devops"]
tools
["Read","Write","Edit","Bash","Glob","Grep"]
verified
true
lastVerifiedAt
"2026-02-22T00:00:00.000Z"
source
builtin
trust_score
100
provenance_sha
db6be73e2db8914d
Kubernetes Manifest Generator
Step-by-step guidance for creating production-ready Kubernetes manifests including Deployments, Services, ConfigMaps, Secrets, and PersistentVolumeClaims.
Purpose
This skill provides comprehensive guidance for generating well-structured, secure, and production-ready Kubernetes manifests following cloud-native best practices and Kubernetes conventions.
When to Use This Skill
Use this skill when you need to:
Create new Kubernetes Deployment manifests
Define Service resources for network connectivity
Generate ConfigMap and Secret resources for configuration management
Create PersistentVolumeClaim manifests for stateful workloads
Follow Kubernetes best practices and naming conventions
Implement resource limits, health checks, and security contexts
Design manifests for multi-environment deployments
Step-by-Step Workflow
1. Gather Requirements
Understand the workload:
Application type (stateless/stateful)
Container image and version
Environment variables and configuration needs
Storage requirements
Network exposure requirements (internal/external)
Resource requirements (CPU, memory)
Scaling requirements
Health check endpoints
Questions to ask:
What is the application name and purpose?
What container image and tag will be used?
Does the application need persistent storage?
What ports does the application expose?
Are there any secrets or configuration files needed?
What are the CPU and memory requirements?
Does the application need to be exposed externally?
references/service-spec.md - Service types and networking details
Best Practices Summary
Always set resource requests and limits - Prevents resource starvation
Implement health checks - Ensures Kubernetes can manage your application
Use specific image tags - Avoid unpredictable deployments
Apply security contexts - Run as non-root, drop capabilities
Use ConfigMaps and Secrets - Separate config from code
Label everything - Enables filtering and organization
Follow naming conventions - Use standard Kubernetes labels
Validate before applying - Use dry-run and validation tools
Version your manifests - Keep in Git with version control
Document with annotations - Add context for other developers
Troubleshooting
Pods not starting:
Check image pull errors: kubectl describe pod <pod-name>
Verify resource availability: kubectl get nodes
Check events: kubectl get events --sort-by='.lastTimestamp'
Service not accessible:
Verify selector matches pod labels: kubectl get endpoints <service-name>
Check service type and port configuration
Test from within cluster: kubectl run debug --rm -it --image=busybox -- sh
ConfigMap/Secret not loading:
Verify names match in Deployment
Check namespace
Ensure resources exist: kubectl get configmap,secret
Next Steps
After creating manifests:
Store in Git repository
Set up CI/CD pipeline for deployment
Consider using Helm or Kustomize for templating
Implement GitOps with ArgoCD or Flux
Add monitoring and observability
Iron Laws
ALWAYS set CPU and memory resource requests and limits on every container โ pods without resource limits consume unbounded node resources, cause node pressure evictions, and starve neighboring workloads.
NEVER run containers as root (runAsNonRoot: false or omitted) in production โ root containers can escape containment via kernel exploits; always set securityContext.runAsNonRoot: true with a specific runAsUser.
ALWAYS define liveness and readiness probes on every workload โ without probes, Kubernetes cannot distinguish a deadlocked container from a healthy one; failing probes block deployments and traffic incorrectly.
NEVER store secrets in ConfigMaps โ ConfigMaps are stored in plaintext in etcd; use Kubernetes Secrets (with etcd encryption at rest) or an external secrets manager (Vault, AWS Secrets Manager).
ALWAYS set a PodDisruptionBudget for production workloads โ without PDBs, node drains during upgrades can terminate all replicas simultaneously, causing complete service outages.
Anti-Patterns
Anti-Pattern
Why It Fails
Correct Approach
No resource limits
Pod consumes all node memory; node OOM kills other pods; cluster destabilized
Set requests (scheduling) and limits (enforcement) for CPU and memory on every container
Running as root
Kernel exploits allow container escape; file system writes as root corrupt host
Set runAsNonRoot: true, runAsUser: 1000, readOnlyRootFilesystem: true
Missing liveness/readiness probes
Deadlocked pods serve traffic; new pods receive traffic before ready
Add /health liveness and /ready readiness probes with appropriate initialDelaySeconds
Secrets in ConfigMaps
Plaintext in etcd; visible in kubectl get configmap; audit log exposes values
Use kind: Secret with base64 encoding; enable etcd encryption; prefer external secrets
Single replica for production
Pod restart = service outage; zero tolerance for node failure
Minimum 2 replicas + PodAntiAffinity rules to spread across nodes; PodDisruptionBudget
Related Skills
helm-chart-scaffolding - For templating and packaging
gitops-workflow - For automated deployments
k8s-security-policies - For advanced security configurations
