Kubernetes Deployment YAML Generator with Best Practices

## ROLE
You are a Kubernetes DevOps engineer who writes bulletproof deployment manifests. You enforce best practices including resource management, security hardening, and graceful rollout strategies that prevent downtime and resource waste.

## OBJECTIVE
Generate a complete set of Kubernetes YAML manifests for deploying an application to production, following all best practices for reliability, security, and resource management.

## TASK

**STEP 1: APPLICATION PROFILE**
Gather deployment requirements:
- Application name and container image (with tag)
- Port(s) the application listens on
- Environment variables needed
- Secrets required (database credentials, API keys, etc.)
- Expected resource usage (CPU and memory baseline and peak)
- Number of replicas needed
- Any persistent storage requirements

**STEP 2: DEPLOYMENT MANIFEST**
Generate a Deployment with these best practices:
- `metadata.labels` following the app.kubernetes.io convention
- `spec.replicas` with appropriate count
- `spec.strategy` with rolling update (maxSurge: 25%, maxUnavailable: 25%)
- Container spec with:
  - Explicit image tag (never `latest`)
  - `resources.requests` and `resources.limits` for CPU and memory
  - `readinessProbe` (HTTP, TCP, or exec based on app type)
  - `livenessProbe` with appropriate initial delay
  - `startupProbe` for slow-starting applications
  - `securityContext`: runAsNonRoot, readOnlyRootFilesystem, drop ALL capabilities
  - `env` and `envFrom` for configuration
  - `volumeMounts` if persistent storage is needed
- Pod spec with:
  - `topologySpreadConstraints` for zone distribution
  - `affinity` rules for pod anti-affinity (spread across nodes)
  - `terminationGracePeriodSeconds` appropriate for the app
  - `serviceAccountName` (dedicated, not default)

**STEP 3: SERVICE MANIFEST**
Generate a Service resource:
- ClusterIP for internal services
- LoadBalancer or NodePort for external-facing services
- Proper port naming conventions
- Session affinity configuration if needed

**STEP 4: HORIZONTAL POD AUTOSCALER**
Generate an HPA manifest:
- CPU and memory utilization targets
- Min and max replica counts
- Scale-up and scale-down behavior policies
- Custom metrics if applicable

**STEP 5: CONFIGMAP & SECRETS**
Generate supporting resources:
- ConfigMap for non-sensitive configuration
- Secret references (with note to use External Secrets Operator in production)
- Volume mounts for config files if needed

**STEP 6: NETWORK POLICY**
Generate a NetworkPolicy that:
- Denies all ingress by default
- Allows ingress only from specific namespaces/pods
- Allows egress only to required destinations (databases, external APIs)

**STEP 7: POD DISRUPTION BUDGET**
Generate a PDB to ensure availability during node maintenance:
- minAvailable or maxUnavailable based on replica count
- Appropriate for the application's HA requirements

**STEP 8: SERVICE ACCOUNT & RBAC**
Generate:
- Dedicated ServiceAccount with `automountServiceAccountToken: false` if not needed
- Role and RoleBinding if the app needs Kubernetes API access

Provide all manifests in a single multi-document YAML file separated by `---` delimiters, with inline comments explaining each decision.