Kubernetes Best Practices

Kubernetes Best Practices are the accumulated set of conventions and configuration disciplines that experienced operators apply when running workloads on the platform, addressing the gap between what Kubernetes allows and what actually produces a secure, reliable, and maintainable system. Kubernetes' flexibility means it will faithfully run a poorly configured workload just as readily as a well-configured one; best practices exist to close that gap deliberately, rather than discovering the consequences of skipping them during an incident.

Workload Configuration

Always Set Resource Requests and Limits

Every container should declare explicit CPU and memory requests, so the scheduler can make informed placement decisions, and appropriate limits, so a single misbehaving container cannot exhaust a node's resources at the expense of its neighbors. Omitting these values produces BestEffort Pods, the first to be evicted under any resource pressure.

resources:
  requests:
    cpu: "100m"
    memory: "128Mi"
  limits:
    cpu: "500m"
    memory: "256Mi"

Configure Meaningful Probes

Readiness probes should reflect genuine ability to serve traffic, not merely process liveness, and liveness probes should only fail for conditions a restart can actually fix, since an overly aggressive liveness probe can cause unnecessary restart loops under transient load rather than improving reliability.

Pin Image Versions

Deploying with a mutable tag such as latest makes rollouts non-reproducible and rollbacks unreliable, since the same tag can silently point to different image content over time; pinning to an immutable tag or digest ensures that what was tested is exactly what runs in production.

image: codartium/api@sha256:3f29e1a7c9...

Reliability and Availability

Run Multiple Replicas, Spread Across Failure Domains

A single-replica workload has no redundancy against node failure or routine maintenance; running multiple replicas, combined with anti-affinity or topology spread constraints, ensures availability survives the loss of any one node or zone.

Define PodDisruptionBudgets for Critical Services

Without a PodDisruptionBudget, cluster maintenance operations such as node drains are free to evict every replica of a service simultaneously if scheduling allows it; a PDB bounds how much voluntary disruption a service can absorb at once.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: codartium-api-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: codartium-api

Security

Run as Non-Root with a Minimal Capability Set

Containers should run as an unprivileged user, drop all Linux capabilities not explicitly required, and use a read-only root filesystem wherever the application permits it, minimizing the blast radius of a compromised container process.

securityContext:
  runAsNonRoot: true
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]

Apply Least-Privilege RBAC

ServiceAccounts and human identities should be granted only the specific verbs and resources they require, scoped to the narrowest applicable namespace, rather than broad or cluster-wide permissions granted for convenience.

Restrict Network Traffic with NetworkPolicy

In the absence of explicit NetworkPolicy rules, every Pod can reach every other Pod by default; defining default-deny policies and explicitly allowing only necessary traffic paths limits lateral movement in the event of a compromised workload.

Configuration Management

Keep Manifests Declarative and in Version Control

Manifests, or the Helm charts and Kustomize overlays that generate them, should be treated as the authoritative source of a cluster's intended state, reviewed through the same process as application code, rather than relying on ad hoc imperative commands whose effects are not recorded anywhere.

kubectl apply -f deployment.yaml   # preferred over imperative kubectl run/edit for durable changes

Separate Configuration from Secrets

Non-sensitive configuration belongs in ConfigMaps; credentials and other sensitive values belong in Secrets, with access to Secrets further restricted through RBAC, and ideally backed by encryption at rest or an external secret management integration.

Namespace and Resource Governance

Use Namespaces with Quotas

Dividing a shared cluster into namespaces per team or environment, paired with ResourceQuota and LimitRange objects, prevents any single workload or team from unintentionally consuming disproportionate cluster capacity.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: codartium-team-quota
  namespace: codartium-team
spec:
  hard:
    requests.cpu: "20"
    requests.memory: 40Gi

Operational Discipline

Validate Rollouts Before They Complete

Rolling update parameters should be conservative enough, and readiness probes accurate enough, that a broken release is detected and halted before it replaces a majority of healthy capacity, and revision history should be retained sufficient to support a fast rollback.

kubectl rollout status deployment/codartium-api --timeout=90s
kubectl rollout undo deployment/codartium-api

Monitor and Alert on the Signals That Matter

Resource utilization, error rates, and latency should be continuously observed with alerting tied to symptoms that actually affect users, rather than relying solely on Kubernetes' own self-healing behavior to mask underlying problems that will eventually resurface at greater scale.

The Underlying Principle

Nearly every best practice above traces back to the same underlying idea: give the platform's declarative, self-healing machinery accurate, complete information, resource needs, health signals, disruption tolerance, security constraints, so that its automated decisions match what an operator would actually want, rather than leaving gaps that manifest as outages, security exposure, or wasted capacity under real-world conditions.