Minikube Application Deployment Patterns: Production-Ready Manifests for Four Common Workloads

Choosing the Right Workload Type#

Every application fits one of four deployment patterns. Choosing the wrong one creates problems that are hard to fix later – a database deployed as a Deployment loses data on reschedule, a batch job deployed as a Deployment wastes resources running 24/7.

PatternKubernetes ResourceUse When
Stateless web appDeployment + Service + IngressHTTP APIs, frontends, microservices
Stateful appStatefulSet + Headless Service + PVCDatabases, caches with persistence, message brokers
Background workerDeployment (no Service)Queue consumers, event processors, stream readers
Batch processingCronJobScheduled reports, data cleanup, periodic syncs

Pattern 1: Stateless Web App#

A web API that can be scaled horizontally with no persistent state. Any pod can handle any request.

Pod Security Standards: Admission Control and Secure Pod Configuration

Pod Security Standards#

Kubernetes Pod Security Standards define three security profiles that control what pods are allowed to do. Pod Security Admission (PSA) enforces these standards at the namespace level. This is the replacement for PodSecurityPolicy, which was removed in Kubernetes 1.25.

The Three Levels#

Privileged – Unrestricted. No security controls applied. Used for system-level workloads like CNI plugins, storage drivers, and logging agents that genuinely need host access.

Baseline – Prevents known privilege escalations. Blocks hostNetwork, hostPID, hostIPC, privileged containers, and most host path mounts. Allows most workloads to run without modification.

Security Contexts, Seccomp, and AppArmor: Container Runtime Security

Security Contexts, Seccomp, and AppArmor#

Security contexts control what a container can do at the Linux kernel level: which user it runs as, which syscalls it can make, which files it can access, and whether it can escalate privileges. These settings are your last line of defense when a container is compromised. A properly configured security context limits the blast radius of a breach by preventing an attacker from escaping the container, accessing the host, or escalating to root.