Kubernetes Best Practice Areas

Kubernetes Best Practice Areas are the distinct categories of applied, cross-cutting guidance covered within this knowledge area, spanning security hardening, resource governance, manifest and labeling conventions, workload design principles, least-privilege access control, version and upgrade management, and cost optimization, each drawing on mechanisms already established elsewhere in this knowledge base.

Security Hardening as Default Posture

Baseline Container Security Context

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

Applying a restrictive security context by default, rather than only when a specific incident demands it, is a foundational best practice area: running as a non-root user, mounting a read-only root filesystem, and dropping all Linux capabilities except those explicitly required closes off a wide class of container-escape and privilege-escalation techniques before they become relevant.

Resource Governance

Requests, Limits, and Quota as a Cluster-Wide Discipline

resources:
  requests: { cpu: 250m, memory: 256Mi }
  limits: { memory: 512Mi }

Applying resource requests and limits consistently across every workload, informed by observed usage rather than guesswork, and backing them with namespace-level ResourceQuota and LimitRange guardrails, is the practical application of the resource reliability mechanisms already covered under reliability and availability.

Manifest and Labeling Conventions

Consistent, Predictable Resource Organization

metadata:
  labels:
    app.kubernetes.io/name: myapp
    app.kubernetes.io/component: web
    app.kubernetes.io/managed-by: helm

Consistently applying the recommended Kubernetes labels, coupled with a deliberate manifest organization scheme (by component, by layer) as covered under packaging and customization, keeps a growing set of cluster resources navigable and queryable at scale rather than becoming an unstructured accumulation of manifests.

Workload Design Principles

Choosing the Right Primitive for the Job

Stateless, scalable -> Deployment
Ordered, stable identity, persistent state -> StatefulSet
One-per-node infrastructure -> DaemonSet
Bounded unit of work -> Job / CronJob

Matching a workload's actual operational characteristics to the correct Kubernetes primitive, rather than defaulting to whichever is most familiar, avoids both under-engineering (using a Deployment for a workload that genuinely needs stable identity) and over-engineering (introducing a full Operator for a workload with no meaningful day-two complexity, as discussed under the extensibility boundary).

Least-Privilege Access Control

RBAC Scoped to Actual Need

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: web-team-editor
  namespace: web-team
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "watch", "update"]

Granting exactly the verbs and resources a team or service account actually requires, scoped to the narrowest applicable namespace rather than cluster-wide, is the practical application of the RBAC aggregation and escalation-prevention mechanisms covered under extensibility, applied as a default operating discipline rather than an occasional audit finding.

Version and Upgrade Management

Staying Within Supported Skew

control plane: v1.29
kubelet: v1.28 or v1.29  (within 1 minor version)

Keeping cluster components within Kubernetes's supported version skew policy, and establishing a regular, tested upgrade cadence rather than deferring upgrades until forced by an end-of-life deadline, avoids both the security exposure of running unsupported versions and the operational risk of attempting a large, multi-version jump under time pressure.

Cost Optimization Without Sacrificing Reliability

Right-Sizing Against Observed Usage

quantile_over_time(0.95, container_memory_working_set_bytes[7d])

Sizing resource requests from actual observed usage, applying autoscaling with a reliability-consistent floor as covered under autoscaling reliability basics, and consolidating underutilized nodes are the standard levers for controlling infrastructure cost without eroding the redundancy and headroom the reliability mechanisms elsewhere in this knowledge base depend on.

Multi-Tenancy Isolation

Namespace, Network, and Resource Boundaries Together

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-cross-namespace
spec:
  podSelector: {}
  policyTypes: ["Ingress"]

Combining namespace-scoped RBAC, resource quotas, and network policies together provides the layered isolation multiple independent teams or customers sharing a single cluster require, since any single one of these mechanisms alone leaves a gap the others are specifically designed to close.

Relationship to Best Practices Scope

These areas are the concrete categories of applied guidance operating within the boundary established by best practices scope: each draws directly on mechanisms already covered in depth elsewhere in this knowledge base, security context and RBAC from extensibility, resource governance and autoscaling from reliability, manifest organization from packaging, turning that mechanism-level knowledge into the practical, everyday recommendations that shape how a well-run Kubernetes environment is actually operated day to day.