Kubernetes production best practices: the 2026 guide

SECTION 1

Why a raw Kubernetes cluster does not hold up in production

Kubernetes has established itself as the standard for container orchestration and the foundation of the DevOps wave, offering a fast platform to ship software at a sustained pace. The project has reached maturity, version 1.36 shipped in spring 2026 and the three-releases-a-year cadence is well established, yet it remains demanding: a cluster created in minutes on a managed provider is not thereby ready to host critical workloads.

The gap between a demo cluster and a production cluster is measured in incidents and cloud spend. Without health probes, a failing container keeps receiving traffic; without resource limits, a greedy service starves its neighbours; without network policies, any pod can talk to any pod. The practices that follow cover the points where a Kubernetes production truly plays out: application health, resource management, scaling, access security, network isolation and deployment governance.

Managed offerings, EKS, AKS, GKE, take the control plane off your hands, not the configuration of your workloads. They also impose their own pace: with three minor versions a year and a limited support window, version upgrades are no longer optional, and each one brings its share of deprecated APIs to hunt down in the manifests. A healthy Kubernetes production therefore builds regular cluster upgrades into its normal operations, just like application deployments, rather than enduring them in a rush at end of support.

SECTION 2

Health probes: readiness, liveness and startup probes

Create custom health probes for each application. The readiness probe signals that a container is ready to receive traffic: while it fails, the pod is removed from the service endpoints, which prevents requests from being sent to an instance that is still initialising. The liveness probe checks that the process is still healthy: on repeated failure, Kubernetes restarts the container. The startup probe, finally, protects slow-starting applications, JVMs, AI model loading, by suspending the other two until initialisation is complete.

### Calibrating probes to avoid cascading restarts

The classic trap is the overly aggressive liveness probe: a timeout that is too short, or an external dependency checked inside the probe, turns a passing slowdown into a restart loop that makes the incident worse. The rule: liveness must only test the internal state of the process, never the availability of a database or a third-party API, and its thresholds must give the application time to recover on its own.

On the implementation side, expose dedicated, low-cost endpoints, a /ready that checks the dependencies the service requires, a /healthz that sticks to the state of the process, and use the native gRPC probes for services that do not expose HTTP. Finally, document the semantics of each probe in the service's repository: during an incident, it is the first thing the on-call engineer will check, and a probe with ambiguous behaviour costs precious minutes of diagnosis.

SECTION 3

Requests, limits and namespaces: taking back control of resources

Keep control of resources by setting requests and limits specific to each container. Requests guide pod placement by the scheduler, limits cap actual consumption; their combination determines the pod's quality-of-service class and its eviction order under memory pressure. The goal is to balance a low resource cost with maximum utilisation: a high utilisation rate should reflect a good level of optimisation, not a cluster under permanent strain.

### Namespaces, quotas and multi-team governance

Organise environments into namespaces by team or by domain, and back them with ResourceQuotas and LimitRanges: every team gets an explicit envelope, and a badly sized deployment can no longer drain the entire cluster. The vertical pod autoscaler, used in recommendation mode, completes the setup by confronting declared requests with actually observed consumption, a direct FinOps lever, since overestimated requests are paid for in nodes provisioned for nothing.

Two settings deserve particular attention. Memory limits must always be defined, because an overrun results in a clean, localised OOMKill rather than the degradation of the whole node. CPU limits, on the other hand, are debated: set too tight, they cause invisible throttling that degrades latency without failing a single request. For critical workloads, the Guaranteed class, requests equal to limits, offers the most predictable behaviour under pressure.

SECTION 4

Modern autoscaling: HPA, KEDA and Karpenter

Kubernetes offers three historical scaling mechanisms, to be combined according to the need: the horizontal pod autoscaler adjusts the number of replicas based on load, the vertical pod autoscaler adjusts the resources allocated to a pod, and node autoscaling adds or removes cluster capacity. Enabling the right mechanism, with coherent thresholds, avoids both service degradation at peak and wasted capacity in troughs.

### Karpenter, the new standard for node scaling

For nodes, Karpenter, stable in its 1.x releases, has become the reference: by calling the cloud APIs directly, it provisions a node fitted to the pending pods in under a minute, finely selects instance types, including spot, and continuously consolidates under-utilised nodes. Born on AWS EKS, it now powers AKS node auto-provisioning, generally available since 2025, while GKE keeps its native autoscaler. On the pod side, KEDA complements the HPA by driving scaling from business events, message queue depth, application metrics, rather than CPU alone, down to scale-to-zero for intermittent workloads.

Dynamic autoscaling demands its guardrails: PodDisruptionBudgets so that a node consolidation never removes too many replicas at once, topology spread constraints to distribute pods across availability zones, and pod priorities so that critical workloads preempt deferrable jobs. Without these protections, cost optimisation is paid for in micro-outages that are hard to diagnose, precisely at the moment the cluster is recomposing its capacity.

@cite:introduction-a-l-orchestration-de-conteneurs

SECTION 5

Securing the cluster: RBAC, Pod Security Standards and network policies

Secure access with role-based access control. RBAC restricts permissions per user, per service account and per namespace, following the principle of least privilege: nobody should operate day to day with cluster-admin rights, and each application should only see the resources it needs. Pod Security Standards, which replaced PodSecurityPolicies, complete the setup by enforcing the baseline or restricted profiles at namespace level: no privileged containers, no running as root, read-only root filesystem.

Cluster security actually starts upstream, in the supply chain: scanned and signed images, private registries, and admission policies that reject any non-compliant deployment. The ValidatingAdmissionPolicies built into Kubernetes, or engines such as Kyverno, enforce these rules declaratively, no latest tag, no unsigned image, mandatory labels, without depending on the individual discipline of teams. Secrets, finally, never live in clear text in the manifests: an external manager synchronised into the cluster keeps the Git repository publishable and rotation automatable.

### Isolating the network with default deny

Define explicit network policies. Without them, all pods in a cluster can communicate with each other, which needlessly widens the attack surface and eases lateral movement in case of compromise. The good practice is to set a default-deny policy per namespace, then allow only legitimate flows. eBPF-based CNIs such as Cilium extend this control to the application layer and provide fine-grained visibility of actual flows, invaluable for building policies without breaking production.

@cite:devsecops-10-bonnes-pratiques

SECTION 6

Labels and GitOps: operating the cluster as declared state

Label your objects systematically, building on the recommended app.kubernetes.io labels: application name, version, component, owning team. Consistent labels make bulk operations, queries, per-team cost allocation and the targeting of security policies easier. A well-labelled cluster is far quicker to operate and troubleshoot than an inventory of anonymous objects.

### GitOps: Git as the source of truth

The natural extension is GitOps: the cluster's desired state lives in Git, and a controller such as Argo CD or Flux continuously reconciles reality with that source of truth. Every change goes through review, every configuration drift is detected and corrected, and rebuilding an entire cluster becomes a controlled operation rather than an archaeology of kubectl commands. Combined with the previous practices, GitOps turns Kubernetes production into an auditable, reproducible system.

Standardising the manifests matters as much as storing them: a shared foundation of Helm charts or Kustomize bases, versioned and tested, prevents each team from reinventing its deployments with its own blind spots. Cost labels fit in naturally, opening the way to precise FinOps allocation per team, per application and per environment, and to capacity trade-offs grounded in numbers rather than impressions.

@cite:cloud-native-construire-pour-l-ere-kubernetes

SECTION 7

Making your Kubernetes production reliable with Adservio

None of these practices is exotic, but implementing them coherently takes experience: badly calibrated probes make incidents worse, misconfigured autoscaling wastes capacity, overly permissive RBAC cancels the benefits of isolation. It is the articulation of the whole, health, resources, scale, security, governance, that makes the difference between a cluster that suffers its growth and a platform that sustains it. And without observability, correlated metrics, logs and traces, none of these practices can be steered over time: you do not calibrate probes or autoscaling thresholds blind.

At Adservio, our cloud architects and DevOps teams support Kubernetes production end to end: auditing existing clusters, tuning probes and resources, migrating to Karpenter and KEDA, security hardening and GitOps adoption, to optimise your environments and gain lasting operational efficiency.

FAQ

Frequently asked questions