Markdown

--- name: k8s-manifest-generator description: 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. ---

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?

2. Create Deployment Manifest

**Follow this structure:**

apiVersion: apps/v1
kind: Deployment
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
    version: <version>
spec:
  replicas: 3
  selector:
    matchLabels:
      app: <app-name>
  template:
    metadata:
      labels:
        app: <app-name>
        version: <version>
    spec:
      containers:
        - name: <container-name>
          image: <image>:<tag>
          ports:
            - containerPort: <port>
              name: http
          resources:
            requests:
              memory: "256Mi"
              cpu: "250m"
            limits:
              memory: "512Mi"
              cpu: "500m"
          livenessProbe:
            httpGet:
              path: /health
              port: http
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: http
            initialDelaySeconds: 5
            periodSeconds: 5
          env:
            - name: ENV_VAR
              value: "value"
          envFrom:
            - configMapRef:
                name: <app-name>-config
            - secretRef:
                name: <app-name>-secret

**Best practices to apply:**

Always set resource requests and limits
Implement both liveness and readiness probes
Use specific image tags (never `:latest`)
Apply security context for non-root users
Use labels for organization and selection
Set appropriate replica count based on availability needs

**Reference:** See `references/deployment-spec.md` for detailed deployment options

3. Create Service Manifest

**Choose the appropriate Service type:**

**ClusterIP (internal only):**

apiVersion: v1
kind: Service
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
spec:
  type: ClusterIP
  selector:
    app: <app-name>
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

**LoadBalancer (external access):**

apiVersion: v1
kind: Service
metadata:
  name: <app-name>
  namespace: <namespace>
  labels:
    app: <app-name>
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  type: LoadBalancer
  selector:
    app: <app-name>
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

**Reference:** See `references/service-spec.md` for service types and networking

4. Create ConfigMap

**For application configuration:**

apiVersion: v1
kind: ConfigMap
metadata:
  name: <app-name>-config
  namespace: <namespace>
data:
  APP_MODE: production
  LOG_LEVEL: info
  DATABASE_HOST: db.example.com
  # For config files
  app.properties: |
    server.port=8080
    server.host=0.0.0.0
    logging.level=INFO

**Best practices:**

Use ConfigMaps for non-sensitive data only
Organize related configuration together
Use meaningful names for keys
Consider using one ConfigMap per component
Version ConfigMaps when making changes

**Reference:** See `assets/configmap-template.yaml` for examples

5. Create Secret

**For sensitive data:**

apiVersion: v1
kind: Secret
metadata:
  name: <app-name>-secret
  namespace: <namespace>
type: Opaque
stringData:
  DATABASE_PASSWORD: "changeme"
  API_KEY: "secret-api-key"
  # For certificate files
  tls.crt: |
    -----BEGIN CERTIFICATE-----
    ...
    -----END CERTIFICATE-----
  tls.key: |
    -----BEGIN PRIVATE KEY-----
    ...
    -----END PRIVATE KEY-----

**Security considerations:**

Never commit secrets to Git in plain text
Use Sealed Secrets, External Secrets Operator, or Vault
Rotate secrets regularly
Use RBAC to limit secret access
Consider using Secret type: `kubernetes.io/tls` for TLS secrets

6. Create PersistentVolumeClaim (if needed)

**For stateful applications:**

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: <app-name>-data
  namespace: <namespace>
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3
  resources:
    requests:
      storage: 10Gi

**Mount in Deployment:**

spec:
  template:
    spec:
      containers:
        - name: app
          volumeMounts:
            - name: data
              mountPath: /var/lib/app
      volumes:
        - name: data
          persistentVolumeClaim:
            claimName: <app-name>-data

**Storage considerations:**

Choose appropriate StorageClass for performance needs
Use ReadWriteOnce for single-pod access
Use ReadWriteMany for multi-pod shared storage
Consider backup strategies
Set appropriate retention policies

7. Apply Security Best Practices

**Add security context to Deployment:**

spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000
        fsGroup: 1000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - name: app
          securityContext:
            allowPrivilegeEscalation: false
            readOnlyRootFilesystem: true
            capabilities:
              drop:
                - ALL

**Security checklist:**

[ ] Run as non-root user
[ ] Drop all capabilities
[ ] Use read-only root filesystem
[ ] Disable privilege escalation
[ ] Set seccomp profile
[ ] Use Pod Security Standards

8. Add Labels and Annotations

**Standard labels (recommended):**

metadata:
  labels:
    app.kubernetes.io/name: <app-name>
    app.kubernetes.io/instance: <instance-name>
    app.kubernetes.io/version: "1.0.0"
    app.kubernetes.io/component: backend
    app.kubernetes.io/part-of: <system-name>
    app.kubernetes.io/managed-by: kubectl

**Useful annotations:**

metadata:
  annotations:
    description: "Application description"
    contact: "team@example.com"
    prometheus.io/scrape: "true"
    prometheus.io/port: "9090"
    prometheus.io/path: "/metrics"

9. Organize Multi-Resource Manifests

**File organization options:**

**Option 1: Single file with `---` separator**

# app-name.yaml
---
apiVersion: v1
kind: ConfigMap
...
---
apiVersion: v1
kind: Secret
...
---
apiVersion: apps/v1
kind: Deployment
...
---
apiVersion: v1
kind: Service
...

**Option 2: Separate files**

manifests/
├── configmap.yaml
├── secret.yaml
├── deployment.yaml
├── service.yaml
└── pvc.yaml

**Option 3: Kustomize structure**

base/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
└── configmap.yaml
overlays/
├── dev/
│   └── kustomization.yaml
└── prod/
    └── kustomization.yaml

10. Validate and Test

**Validation steps:**

# Dry-run validation
kubectl apply -f manifest.yaml --dry-run=client

# Server-side validation
kubectl apply -f manifest.yaml --dry-run=server

# Validate with kubeval
kubeval manifest.yaml

# Validate with kube-score
kube-score score manifest.yaml

# Check with kube-linter
kube-linter lint manifest.yaml

**Testing checklist:**

[ ] Manifest passes dry-run validation
[ ] All required fields are present
[ ] Resource limits are reasonable
[ ] Health checks are configured
[ ] Security context is set
[ ] Labels follow conventions
[ ] Namespace exists or is created

Common Patterns

Pattern 1: Simple Stateless Web Application

**Use case:** Standard web API or microservice

**Components needed:**

Deployment (3 replicas for HA)
ClusterIP Service
ConfigMap for configuration
Secret for API keys
HorizontalPodAutoscaler (optional)

**Reference:** See `assets/deployment-template.yaml`

Pattern 2: Stateful Database Application

**Use case:** Database or persistent storage application

**Components needed:**

StatefulSet (not Deployment)
Headless Service
PersistentVolumeClaim template
ConfigMap for DB configuration
Secret for credentials

Pattern 3: Background Job or Cron

**Use case:** Scheduled tasks or batch processing

**Components needed:**

CronJob or Job
ConfigMap for job parameters
Secret for credentials
ServiceAccount with RBAC

Pattern 4: Multi-Container Pod

**Use case:** Application with sidecar containers

**Components needed:**

Deployment with multiple containers
Shared volumes between containers
Init containers for setup
Service (if needed)

Templates

The following templates are available in the `assets/` directory:

`deployment-template.yaml` - Standard deployment with best practices
`service-template.yaml` - Service configurations (ClusterIP, LoadBalancer, NodePort)
`configmap-template.yaml` - ConfigMap examples with different data types
`secret-template.yaml` - Secret examples (to be generated, not committed)
`pvc-template.yaml` - PersistentVolumeClaim templates

Reference Documentation

`references/deployment-spec.md` - Detailed Deployment specification
`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

Related Skills

`helm-chart-scaffolding` - For templating and packaging
`gitops-workflow` - For automated deployments
`k8s-security-policies` - For advanced security configurations

Kubernetes Manifest Generator

Markdown

Kubernetes Manifest Generator

Purpose

When to Use This Skill

Step-by-Step Workflow

1. Gather Requirements

2. Create Deployment Manifest

3. Create Service Manifest

4. Create ConfigMap

5. Create Secret

6. Create PersistentVolumeClaim (if needed)

7. Apply Security Best Practices

8. Add Labels and Annotations

9. Organize Multi-Resource Manifests

10. Validate and Test

Common Patterns

Pattern 1: Simple Stateless Web Application

Pattern 2: Stateful Database Application

Pattern 3: Background Job or Cron

Pattern 4: Multi-Container Pod

Templates

Reference Documentation

Best Practices Summary

Troubleshooting

Next Steps

Related Skills

Conteúdos relacionados

Relacionados