Requests influence scheduling; limits constrain runtime use. Readiness controls traffic, liveness restarts a stuck container, and startup probes protect slow initialization. This manifest makes all four behaviors explicit.
1. Prepare and execute
Confirm the active kubeconfig context and namespace before applying changes. Save commands and manifests in version control without credentials.
kubectl create namespace reliability-lab
kubectl -n reliability-lab create deployment web --image=nginxinc/nginx-unprivileged:1.28-alpine
2. Declarative configuration
Save the following example in a clearly named YAML file, review it, then use server-side dry-run when the API is available.
apiVersion: apps/v1
kind: Deployment
metadata: {name: web, namespace: reliability-lab}
spec:
replicas: 2
selector: {matchLabels: {app: web}}
template:
metadata: {labels: {app: web}}
spec:
containers:
- name: web
image: nginxinc/nginx-unprivileged:1.28-alpine
resources:
requests: {cpu: 50m, memory: 32Mi}
limits: {cpu: 500m, memory: 128Mi}
startupProbe: {httpGet: {path: /, port: 8080}, failureThreshold: 30, periodSeconds: 2}
readinessProbe: {httpGet: {path: /, port: 8080}, periodSeconds: 5}
livenessProbe: {httpGet: {path: /, port: 8080}, periodSeconds: 10}
3. Verify the result
A successful command is not enough. Inspect resource state, conditions, events, endpoints, logs, and an end-to-end request where applicable.
kubectl apply -f reliability.yaml
kubectl -n reliability-lab rollout status deployment/web
kubectl -n reliability-lab describe pod -l app=web
kubectl -n reliability-lab top pod
kubectl -n reliability-lab get pod -w
4. Troubleshooting
OOMKilled indicates the memory limit was exceeded. CPU throttling does not normally restart a container. A bad liveness probe creates a restart loop; test endpoints and timing before deployment.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete namespace reliability-lab
Production checklist
- The active context, namespace, and target version were verified.
- Manifests passed client or server-side validation.
- Resource conditions and recent events show no unresolved error.
- Access, network exposure, resource limits, persistence, and rollback were reviewed.
- Commands and expected output were recorded for the operating team.
References: topic documentation and Kubernetes documentation.
