Skip to main content
rule official · GitHub

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.

Install into GitHub Copilot · Manually: put the files in place All methods and platforms ↓
.github/instructions/kubernetes-manifests.instructions.md
Open on GitHub

What 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.md

The applyTo field sets which files it applies to

Step 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

Similar IDE rules

All IDE rules for DevOps and infrastructure →

From the same set952

The whole set →
markdown-accessibility This rule reviews Markdown files for accessibility issues and suggests specific fixes. Use it when checking documentation or a GitHub profile page. ★ 40,451repo stars lwc Defines Salesforce Lightning Web Components conventions for GitHub Copilot, covering folder structure, standard UI tags, and SLDS utility classes. ★ 40,451repo stars localization This rule guides GitHub Copilot through localizing Markdown files, preserving document links, checking the result, and adding a translated disclaimer. ★ 40,451repo stars langchain-python A GitHub Copilot instruction file that steers the agent toward LangChain patterns: Runnable, LCEL, chat models, retrievers and vector stores. Useful when your Python code talks to LangChain. ★ 40,451repo stars kubernetes-deployment-best-practices This rule guides Copilot when drafting Kubernetes manifests, from deployment probes and resource settings to network access. Use it while building or reviewing a deployment. ★ 40,451repo stars kotlin-mcp-server A rule with patterns for building MCP servers in Kotlin on top of the official io.modelcontextprotocol:kotlin-sdk. It gives Copilot the context it needs to generate server code. ★ 40,451repo stars joyride-workspace-automation Guides GitHub Copilot to build project-specific VS Code scripts with ClojureScript and Joyride. It enforces REPL-driven development directly inside the editor runtime. ★ 40,451repo stars joyride-user-project This rule guides Joyride project work through ClojureScript REPL checks and VS Code automation. Use it when you want to test code in VS Code’s runtime before editing project files. ★ 40,451repo stars

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor