A Pod is Kubernetes’ smallest schedulable unit, but production applications normally use a controller. This lab builds a Pod manifest with labels, environment, resources, probes, and a security context so every field is observable.
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 pod-lab
kubectl explain pod.spec
kubectl explain pod.spec.containers.resources
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: v1
kind: Pod
metadata:
name: web
namespace: pod-lab
labels: {app: web, environment: lab}
spec:
securityContext: {runAsNonRoot: true}
containers:
- name: web
image: nginxinc/nginx-unprivileged:1.28-alpine
ports: [{containerPort: 8080}]
resources:
requests: {cpu: 50m, memory: 32Mi}
limits: {cpu: 250m, memory: 128Mi}
readinessProbe:
httpGet: {path: /, port: 8080}
initialDelaySeconds: 2
securityContext:
allowPrivilegeEscalation: false
capabilities: {drop: [ALL]}
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 --server-side --dry-run=server -f pod.yaml
kubectl apply -f pod.yaml
kubectl -n pod-lab wait --for=condition=Ready pod/web --timeout=90s
kubectl -n pod-lab get pod web -o yaml
kubectl -n pod-lab logs web
kubectl -n pod-lab port-forward pod/web 8080:8080
4. Troubleshooting
Use describe and events for scheduling or image errors. Pods are mostly immutable; if a field cannot be patched, update the manifest and recreate through a controller rather than editing a live Pod by hand.
5. Rollback and cleanup
Review the exact target before deleting resources, especially namespaces, claims, Secrets, and cluster-wide add-ons.
kubectl delete -f pod.yaml
kubectl delete namespace pod-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.
