K8s Manifest Generator
Seth HobsonCommunityCreated by Seth Hobson
- Skill
- Tool integration
- Cloud and DevOps
- MIT
- Low risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The k8s-manifest-generator provides a standardized workflow for creating essential Kubernetes resources. It emphasizes cloud-native best practices, such as implementing resource limits, health checks, security contexts, and proper labeling. By following this skill, users can ensure their manifests are well-structured, maintainable, and ready for production environments, while also learning how to troubleshoot common deployment and connectivity issues.
What it does
- Provides templates for Deployments, Services, ConfigMaps, and Secrets.
- Guides users through defining resource requests, limits, and health probes.
- Outlines security best practices like running as non-root and using specific image tags.
- Offers troubleshooting steps for common Pod and Service issues.
- Suggests organizational patterns like labeling and version control for manifests.
- Includes references for advanced deployment and service specifications.
When to use it
- When you need to create new Kubernetes resource manifests from scratch.
- When you want to ensure your YAML configurations follow production-grade standards.
- When you need to define network connectivity via Services or configuration via ConfigMaps.
- When you are setting up stateful workloads requiring PersistentVolumeClaims.
- When you need to debug common Kubernetes deployment or connectivity failures.
Advantages
- Promotes consistency and reliability across Kubernetes environments.
- Reduces configuration errors by enforcing best practices like resource limits.
- Improves security posture through mandatory security context configurations.
- Simplifies the creation process with clear, step-by-step patterns.
- Provides actionable troubleshooting guidance for common cluster issues.
Usage examples
- “Generate a production-ready Deployment manifest for a web application named 'auth-service' using image 'auth:v1.2.0'.”
- The agent provides a YAML manifest including resource requests/limits, liveness/readiness probes, and security context settings.
- “How do I expose my application externally using a Kubernetes Service?”
- The agent explains the difference between ClusterIP and LoadBalancer types and provides a template for a LoadBalancer service.
- “My pod is failing to start, what should I check?”
- The agent lists diagnostic commands like kubectl describe and kubectl get events to identify image pull errors or resource constraints.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/wshobson/k8s-manifest-generator/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip k8s-manifest-generator.zip -d .agents/skills
Documentation by Seth Hobson
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
Detailed patterns and worked examples
Detailed pattern documentation lives in references/details.md. Read that file when the navigation tier above is insufficient.
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 nodesCheck 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
Related Skills
helm-chart-scaffolding- For templating and packaginggitops-workflow- For automated deploymentsk8s-security-policies- For advanced security configurations
Files
- ATTRIBUTION.mdAdded by AutoGineer1008 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md3.0 KiB
- assets/configmap-template.yaml6.1 KiB
- assets/deployment-template.yaml5.1 KiB
- assets/service-template.yaml3.6 KiB
- references/deployment-spec.md17.3 KiB
- references/details.md10.6 KiB
- references/service-spec.md13.8 KiB
assets/configmap-template.yaml
# Kubernetes ConfigMap Templates
---
# Template 1: Simple Key-Value Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-config
namespace: <namespace>
labels:
app.kubernetes.io/name: <app-name>
app.kubernetes.io/instance: <instance-name>
data:
# Simple key-value pairs
APP_ENV: "production"
LOG_LEVEL: "info"
DATABASE_HOST: "db.example.com"
DATABASE_PORT: "5432"
CACHE_TTL: "3600"
MAX_CONNECTIONS: "100"
---
# Template 2: Configuration File
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-config-file
namespace: <namespace>
labels:
app.kubernetes.io/name: <app-name>
data:
# Application configuration file
application.yaml: |
server:
port: 8080
host: 0.0.0.0
logging:
level: INFO
format: json
database:
host: db.example.com
port: 5432
pool_size: 20
timeout: 30
cache:
enabled: true
ttl: 3600
max_entries: 10000
features:
new_ui: true
beta_features: false
---
# Template 3: Multiple Configuration Files
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-multi-config
namespace: <namespace>
labels:
app.kubernetes.io/name: <app-name>
data:
# Nginx configuration
nginx.conf: |
user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;
events {
worker_connections 1024;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
sendfile on;
keepalive_timeout 65;
include /etc/nginx/conf.d/*.conf;
}
# Default site configuration
default.conf: |
server {
listen 80;
server_name _;
location / {
proxy_pass http://backend:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /health {
access_log off;
return 200 "healthy\n";
}
}
---
# Template 4: JSON Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-json-config
namespace: <namespace>
labels:
app.kubernetes.io/name: <app-name>
data:
config.json: |
{
"server": {
"port": 8080,
"host": "0.0.0.0",
"timeout": 30
},
"database": {
"host": "postgres.example.com",
"port": 5432,
"database": "myapp",
"pool": {
"min": 2,
"max": 20
}
},
"redis": {
"host": "redis.example.com",
"port": 6379,
"db": 0
},
"features": {
"auth": true,
"metrics": true,
"tracing": true
}
}
---
# Template 5: Environment-Specific Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-prod-config
namespace: production
labels:
app.kubernetes.io/name: <app-name>
environment: production
data:
APP_ENV: "production"
LOG_LEVEL: "warn"
DEBUG: "false"
RATE_LIMIT: "1000"
CACHE_TTL: "3600"
DATABASE_POOL_SIZE: "50"
FEATURE_FLAG_NEW_UI: "true"
FEATURE_FLAG_BETA: "false"
---
# Template 6: Script Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: <app-name>-scripts
namespace: <namespace>
labels:
app.kubernetes.io/name: <app-name>
data:
# Initialization script
init.sh: |
#!/bin/bash
set -e
echo "Running initialization..."
# Wait for database
until nc -z $DATABASE_HOST $DATABASE_PORT; do
echo "Waiting for database..."
sleep 2
done
echo "Database is ready!"
# Run migrations
if [ "$RUN_MIGRATIONS" = "true" ]; then
echo "Running database migrations..."
./migrate up
fi
echo "Initialization complete!"
# Health check script
healthcheck.sh: |
#!/bin/bash
# Check application health endpoint
response=$(curl -sf http://localhost:8080/health)
if [ $? -eq 0 ]; then
echo "Health check passed"
exit 0
else
echo "Health check failed"
exit 1
fi
---
# Template 7: Prometheus Configuration
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
namespace: monitoring
labels:
app.kubernetes.io/name: prometheus
data:
prometheus.yml: |
global:
scrape_interval: 15s
evaluation_interval: 15s
external_labels:
cluster: 'production'
region: 'us-west-2'
alerting:
alertmanagers:
- static_configs:
- targets:
- alertmanager:9093
rule_files:
- /etc/prometheus/rules/*.yml
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
action: keep
regex: true
- source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
action: replace
target_label: __metrics_path__
regex: (.+)
- source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
action: replace
target_label: __address__
regex: ([^:]+)(?::\d+)?;(\d+)
replacement: $1:$2
---
# Usage Examples:
#
# 1. Mount as environment variables:
# envFrom:
# - configMapRef:
# name: <app-name>-config
#
# 2. Mount as files:
# volumeMounts:
# - name: config
# mountPath: /etc/app
# volumes:
# - name: config
# configMap:
# name: <app-name>-config-file
#
# 3. Mount specific keys as files:
# volumes:
# - name: nginx-config
# configMap:
# name: <app-name>-multi-config
# items:
# - key: nginx.conf
# path: nginx.conf
#
# 4. Use individual environment variables:
# env:
# - name: LOG_LEVEL
# valueFrom:
# configMapKeyRef:
# name: <app-name>-config
# key: LOG_LEVEL
Requirements and compatibility
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Security
What our scanner noticed· Low risk
- Instructions that use the network
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- Seth Hobson
- Publisher
- Seth Hobson (Community)
- Source
- wshobson/agents · plugins/kubernetes-operations/skills/k8s-manifest-generator · commit 4bde316
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Seth Hobson or Seth Hobson.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download k8s-manifest-generator.zip