• 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

• 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

• 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?

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

• 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

references/deployment-spec.md

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

• 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

assets/configmap-template.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-----

• 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

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

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

• 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

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

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

apiVersion: v1 kind: ConfigMap ...

apiVersion: v1 kind: Secret ...

apiVersion: apps/v1 kind: Deployment ...

**Option 2: Separate files**

**Option 3: Kustomize structure**

undefined

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

assets/deployment-template.yaml

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

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

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

assets/

• 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

• references/deployment-spec.md

  - Detailed Deployment specification

• references/service-spec.md

  - Service types and networking details

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

• Check image pull errors:

  kubectl describe pod <pod-name>

• Verify resource availability:

  kubectl get nodes

• Check events:

  kubectl get events --sort-by='.lastTimestamp'

• 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

• Verify names match in Deployment
• Check namespace
• Ensure resources exist:

  kubectl get configmap,secret

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