Generated banner for K8s Manifest Generator
Generated logo for K8s Manifest Generator

K8s Manifest Generator

Seth HobsonCommunityCreated by Seth Hobson

  • Skill
  • Tool integration
  • Cloud and DevOps
  • MIT
  • Low risk

From the author

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.
— the description by Seth Hobson

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

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/wshobson/k8s-manifest-generator/download
  2. Unzip 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

  1. Always set resource requests and limits - Prevents resource starvation

  2. Implement health checks - Ensures Kubernetes can manage your application

  3. Use specific image tags - Avoid unpredictable deployments

  4. Apply security contexts - Run as non-root, drop capabilities

  5. Use ConfigMaps and Secrets - Separate config from code

  6. Label everything - Enables filtering and organization

  7. Follow naming conventions - Use standard Kubernetes labels

  8. Validate before applying - Use dry-run and validation tools

  9. Version your manifests - Keep in Git with version control

  10. 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:

  1. Store in Git repository

  2. Set up CI/CD pipeline for deployment

  3. Consider using Helm or Kustomize for templating

  4. Implement GitOps with ArgoCD or Flux

  5. Add monitoring and observability

  • helm-chart-scaffolding - For templating and packaging

  • gitops-workflow - For automated deployments

  • k8s-security-policies - For advanced security configurations

Files

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.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download k8s-manifest-generator.zip