Pod Spec Fields: 2026 Best Practice

Most pods missing fields. The checklist.

Must have

Pod spec best practice is the discipline of including the right fields in pod specifications. Some fields are required for production; some are recommended; some should be avoided. The discipline pays off in operational quality and security.

What every pod must have:

• resources.requests.: Every pod must declare its resource requests. Without requests, the scheduler cannot place pods correctly; the cluster cannot enforce QoS; the discipline starts here.
• resources.limits.: Every pod must declare its resource limits. Without limits, pods can consume unbounded resources; one pod can affect others on the node; the discipline requires limits.
• Readiness probe.: The readiness probe gates traffic. Pods are not ready by default; the readiness probe must pass before traffic flows; the probe matches the application's actual readiness.
• Liveness probe (with care).: The liveness probe restarts unhealthy pods. Used carelessly, it produces restart loops; used carefully, it catches stuck applications. The probe must be calibrated to the application's actual behavior.
• Security context.: Run as non-root user. Drop unnecessary capabilities. Read-only root filesystem where possible. The security context bounds the pod's blast radius if compromised.

The must-have fields are non-negotiable for production. Without them, the pod's behavior is unbounded.

Should have

Beyond must-have, some fields significantly improve operations. The team's policy includes these for production workloads; non-production may be less strict.

• nodeSelector or affinity.: Workloads with specific node requirements use nodeSelector or nodeAffinity. GPU workloads, region-specific workloads, performance-tier workloads all benefit from explicit placement.
• Tolerations.: Workloads that need to schedule on tainted nodes use tolerations. Dedicated nodes, GPU nodes, special-purpose nodes all require tolerations.
• PriorityClass.: Critical workloads get higher priority. The cluster's eviction order respects priority; critical workloads survive resource pressure better.
• Tunable for the workload.: The should-have fields are workload-specific. Different services have different placement, priority, and toleration needs; the per-workload tuning matters.
• Anti-affinity for high availability.: Multi-replica workloads benefit from pod anti-affinity. Replicas spread across nodes; node failures do not take down all replicas; availability is preserved.

The should-have fields are operational quality. They are not strictly required but produce significantly better operations.

Avoid

Some fields should be avoided unless specifically needed. Privileged settings have security implications; their use should be justified.

• hostNetwork: true.: The pod uses the host's network namespace. The pod can see all the host's network; security implications are significant; only specific use cases warrant this.
• privileged: true.: The pod runs with full privileges. Container security boundaries are reduced; the pod can affect the host; only specific operational pods (CNI plugins, system agents) warrant this.
• Specific use cases only.: When privileged or hostNetwork is genuinely needed, document the justification. Future reviewers understand the choice; the discipline is preserved through team changes.
• Pod Security Admission catches these.: If the namespace's PSA level is restricted or baseline, these fields are blocked. The discipline is enforced by the platform; the team's policy is automated.
• Audit periodically.: The team audits pods using these fields. The justifications are reviewed; some can be removed; the discipline maintains.

Pod spec fields best practice is one of those Kubernetes engineering disciplines that compounds across many pods. Nova AI Ops integrates with cluster pod inventory, surfaces fields-related patterns, and supports the team's pod-spec discipline.