kubernetes-manifests — GitHub Copilot rule: setup and features
Configures GitHub Copilot to generate production-ready Kubernetes manifests. Enforces standard labels, hardened security contexts, resource limits, and health probes.
.github/instructions/kubernetes-manifests.instructions.mdWhat kubernetes-manifests does
The rule triggers on YAML files located inside k8s, manifests, deploy, or Helm templates under charts. It mandates official app.kubernetes.io/* labels, explicit image tags instead of :latest, and non-root execution. Privilege escalation is disabled by default.
Pod stability relies on startup, liveness, and readiness probes with tuned timeouts. For high availability, production setups enforce a minimum of 2 or 3 replicas, Pod Disruption Budgets, and rolling updates where maxUnavailable is set to 0.
Containers using readOnlyRootFilesystem: true must mount tmpfs volumes for writable paths. Before applying manifests, the instructions guide validation using kubectl apply --dry-run and kubeconform -strict for schema verification.
What it helps with
- harden container security contexts and drop Linux capabilities
- configure CPU and memory requests alongside strict limits
- implement liveness, readiness, and startup health probes
- attach standard metadata labels and Prometheus annotations
- define zero-downtime rolling update configurations
Example prompts for the agent
- Create a deployment manifest for a backend API with three replicas and non-root security settings.
- Add a PodDisruptionBudget and zero-downtime rolling update strategy to
deploy/api.yaml. - Configure liveness and readiness probes with resource limits in
k8s/worker.yaml.
How to install kubernetes-manifests
Manually: put the files in place
.github/instructions/kubernetes-manifests.instructions.mdThe applyTo field sets which files it applies to
Manually: put the files in place
.claude/rules/kubernetes-manifests.mdThe paths frontmatter field limits the files: move applyTo from the source into paths
AGENTS.md
Codex reads AGENTS.md: paste the rule text there
Manually: put the files in place
.cursor/rules/kubernetes-manifests.mdcFrontmatter: description, globs, alwaysApply. Move applyTo from the source into globs, or the rule will not attach on its own
Manually: put the files in place
.devin/rules/kubernetes-manifests.mdManually: put the files in place
.clinerules/kubernetes-manifests.mdStep by step, with commands for each platform: AGENTS.md vs CLAUDE.md: what they are and which one to use
Questions about kubernetes-manifests
How to install kubernetes-manifests in GitHub Copilot?
Add the rule content to .github/instructions/kubernetes-manifests.instructions.md in your repository root.
Which file paths does this rule target?
It matches YAML files in k8s, manifests, deploy, and Helm template directories under charts.
How can I test manifests before deploying them?
Run kubectl apply --dry-run=client -f manifest.yaml or execute kubeconform -strict manifest.yaml to validate the schemas.
Source text
kubernetes-manifests.instructions.md · MIT
--- applyTo: 'k8s/**/*.yaml,k8s/**/*.yml,manifests/**/*.yaml,manifests/**/*.yml,deploy/**/*.yaml,deploy/**/*.yml,charts/**/templates/**/*.yaml,charts/**/templates/**/*.yml' description: 'Best practices for Kubernetes YAML manifests including labeling conventions, security contexts, pod security, resource management, probes, and validation commands' --- # Kubernetes Manifests Instructions ## Your Mission Create production-ready Kubernetes manifests that prioritize security, reliability, and operational excellence with consistent labeling, proper resource management, and comprehensive health checks. ## Labeling Conventions **Required Labels** (Kubernetes recommended): - `app.kubernetes.io/name`: Application name - `app.kubernetes.io/instance`: Instance identifier - `app.kubernetes.io/version`: Version - `app.kubernetes.io/component`: Component role - `app.kubernetes.io/part-of`: Application group - `app.kubernetes.io/managed-by`: Management tool **Additional Labels**: - `environment`: Environment name - `team`: Owning team - `cost-center`: For billing **Useful Annotations**: - Documentation and ownership - Monitoring: `prometheus.io/scrape`, `prometheus.io/port`, `prometheus.io/path` - Change tracking: git commit, deployment date ## SecurityContext Defaults **Pod-level**: - `runAsNonRoot: true` - `runAsUser` and `runAsGroup`: Specific IDs - `fsGroup`: File system group - `seccompProfile.type: RuntimeDefault` **Container-level**: - `allowPrivilegeEscalation: false` - `readOnlyRootFilesystem: true` (with tmpfs mounts for writable dirs) - `capabilities.drop: [ALL]` (add only what's needed) ## Pod Security Standards Use Pod Security Admission: - **Restricted** (recommended for production): Enforces security hardening - **Baseline**: Minimal security requirements - Apply at namespace level ## Resource Requests and Limits **Always define**: - Requests: Guaranteed minimum (scheduling) - Limits: Maximum allowed (prevents exhaustion) **QoS Classes**: - **Guaranteed**: requests == limits (best for critical apps) - **Burstable**: requests < limits (flexible resource use) - **BestEffort**: No resources defined (avoid in production) ## Health Probes **Liveness**: Restart unhealthy containers **Readiness**: Control traffic routing **Startup**: Protect slow-starting applications Configure appropriate delays, periods, timeouts, and thresholds for each. ## Rollout Strategies **Deployment Strategy**: - `RollingUpdate` with `maxSurge` and `maxUnavailable` - Set `maxUnavailable: 0` for zero-downtime **High Availability**: - Minimum 2-3 replicas - Pod Disruption Budget (PDB) - Anti-affinity rules (spread across nodes/zones) - Horizontal Pod Autoscaler (HPA) for variable load ## Validation Commands **Pre-deployment**: - `kubectl apply --dry-run=client -f manifest.yaml` - `kubectl apply --dry-run=server -f manifest.yaml` - `kubeconform -strict manifest.yaml` (schema validation) - `helm template ./chart | kubeconform -strict` (for Helm) **Policy Validation**: - OPA Conftest, Kyverno, or Datree ## Rollout & Rollback **Deploy**: - `kubectl apply -f manifest.yaml` - `kubectl rollout status deployment/NAME` **Rollback**: - `kubectl rollout undo deployment/NAME` - `kubectl rollout undo deployment/NAME --to-revision=N` - `kubectl rollout history deployment/NAME` **Restart**: - `kubectl rollout restart deployment/NAME` ## Manifest Checklist - [ ] Labels: Standard labels applied - [ ] Annotations: Documentation and monitoring - [ ] Security: runAsNonRoot, readOnlyRootFilesystem, dropped capabilities - [ ] Resources: Requests and limits defined - [ ] Probes: Liveness, readiness, startup configured - [ ] Images: Specific tags (never :latest) - [ ] Replicas: Minimum 2-3 for production - [ ] Strategy: RollingUpdate with appropriate surge/unavailable - [ ] PDB: Defined for production - [ ] Anti-affinity: Configured for HA - [ ] Graceful shutdown: terminationGracePeriodSeconds set - [ ] Validation: Dry-run and kubeconform passed - [ ] Secrets: In Secrets resource, not ConfigMaps - [ ] NetworkPolicy: Least-privilege access (if applicable) ## Best Practices Summary 1. Use standard labels and annotations 2. Always run as non-root with dropped capabilities 3. Define resource requests and limits 4. Implement all three probe types 5. Pin image tags to specific versions 6. Configure anti-affinity for HA 7. Set Pod Disruption Budgets 8. Use rolling updates with zero unavailability 9. Validate manifests before applying 10. Enable read-only root filesystem when possible
© github · MIT · github/awesome-copilot