Many Kubernetes environments accumulate risk because application manifests start with too little structure. No resource requests, no startup probe, loose security settings, and no agreed pattern for how a workload declares its runtime needs.

That is not a tooling problem. It is a baseline problem.

Define resources and probes together

Requests and limits matter because the scheduler and the node both need to know what the workload expects. Probes matter because the platform needs to know when the workload is starting, healthy, and ready for traffic.

containers:
  - name: api
    image: ghcr.io/example/orders-api:1.4.2
    resources:
      requests:
        cpu: 250m
        memory: 512Mi
      limits:
        cpu: "1"
        memory: 1Gi
    startupProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
      failureThreshold: 30
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /actuator/health/readiness
        port: 8080
    livenessProbe:
      httpGet:
        path: /actuator/health/liveness
        port: 8080

If those settings are absent, the platform is being asked to guess.

Use security context deliberately

Not every workload can run with the same container restrictions, but most application services can avoid privileged execution, writable root filesystems, and running as root. That should be the default engineering assumption until a real exception is proven.

Hardening is easier when teams repeat patterns

The strongest clusters do not depend on every team remembering every field. They depend on reusable workload templates, review expectations, and admission policies that reinforce the same baseline repeatedly.

Closing view

Kubernetes hardening is most successful when it becomes ordinary. Resources, probes, and security defaults should feel like the normal way to ship a workload. When those decisions remain optional or inconsistent, the platform inherits operational instability that was avoidable from the start.