Containers, Kubernetes & Platform Engineering

A deployment can remain unavailable when replicas fail readiness, scheduling constraints block pods, or image and configuration problems prevent startup. What to check Inspect deployment conditions, replica sets, pod events, scheduling decisions, image pulls, probes, and recent rollout changes. Compare desired replicas with ready endpoints....

A mounted file can exist but remain unreadable because of ownership, file mode, security context, volume type, or a path mismatch in the container. What to check Check mount path, pod events, file permissions, user and group IDs, read-only settings, and security context. Compare the container’s view with the source volume. Recommended next step Grant...

A node upgrade can disrupt workloads if replicas are concentrated, disruption budgets are too strict, or replacement pods cannot schedule. What to check Check replica placement, pod disruption budgets, resource requests, node capacity, readiness, and storage constraints. Confirm the maintenance sequence and workload criticality. Recommended next step...

A pod may remain pending when its persistent volume cannot be provisioned or attached because of storage class, quota, zone, or access mode constraints. What to check Review pod and PVC events, storage class parameters, capacity, topology, access mode, and CSI driver health. Confirm whether the workload expects an existing claim. Recommended next step...

A pod may fail to resolve a service because of DNS configuration, namespace scope, network policy, or a cluster DNS issue. Application retries can make the symptom intermittent. What to check Check pod resolver settings, service name and namespace, DNS pod health, CoreDNS logs, and network policy. Compare lookup results from a healthy workload in the...

A pod may fail to start when a referenced secret is missing from its namespace, named incorrectly, or restricted by deployment configuration. What to check Inspect pod events, namespace, secret name, volume and key references, service account, and recent deployment changes. Avoid printing secret contents while debugging. Recommended next step Correct...

Kubernetes may evict pods when node storage is under pressure from container layers, logs, ephemeral data, or images. Repeated eviction can disrupt unrelated workloads. What to check Inspect node conditions, ephemeral storage requests and limits, image usage, log volume, and pod events. Check cleanup behavior and whether workloads write large temporary...

A workload may reference a similarly named ConfigMap from the wrong namespace or deployment revision. The pod can run successfully while using incorrect behavior settings. What to check Check namespace, pod template references, rollout history, mounted values without secrets, and application startup logs. Compare the running revision with the intended...