git:20260119.5684887 to git:20260522.be57c0b

2 added, 459 removed. Audit A to A.

---

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:**

- ```yaml

- 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):**

- ```yaml

- 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):**

- ```yaml

- 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:**

- ```yaml

- 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:**

- ```yaml

- 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:**

- ```yaml

- apiVersion: v1

- kind: PersistentVolumeClaim

- metadata:

- name: <app-name>-data

- namespace: <namespace>

- spec:

- accessModes:

- - ReadWriteOnce

- storageClassName: gp3

- resources:

- requests:

- storage: 10Gi

- ```

- **Mount in Deployment:**

- ```yaml

- 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:**

- ```yaml

- 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):**

- ```yaml

- 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:**

- ```yaml

- 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**

- ```yaml

- # 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:**

- ```bash

- # 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

+ ## Detailed patterns and worked examples

- - `references/deployment-spec.md` - Detailed Deployment specification

- - `references/service-spec.md` - Service types and networking details

+ 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

## Related Skills

- `helm-chart-scaffolding` - For templating and packaging

- `gitops-workflow` - For automated deployments

- `k8s-security-policies` - For advanced security configurations