Containers, Kubernetes & Platform Engineering

A pod may start but fail to read a mounted secret because of the wrong namespace, file path, permissions, projected volume timing, or application configuration. Logging the secret value to debug access can expose credentials. What to check Inspect pod events, volume and key names, mount path, service account and namespace, file permissions, and...

Pods may restart after a node upgrade because of runtime changes, kernel behavior, resource pressure, disruption budgets, or an application dependency on node-specific settings. A cluster may remain available while a subset of workloads degrades. What to check Compare affected nodes and workloads, pod events, runtime and kernel versions, resource...

A Service may keep sending requests to a pod that should have been removed if endpoint readiness, selector labels, rollout state, or service mesh discovery is stale. Users may see intermittent behavior as old and new replicas coexist. What to check Inspect EndpointSlices, pod labels and readiness, deployment rollout, termination grace period, service...

A pod may fail to resolve another service because of cluster DNS health, namespace search paths, network policy, malformed service names, or a node-specific resolver issue. Direct IP tests can work while service discovery fails. What to check Check DNS pod health, service and namespace names, resolver configuration, CoreDNS logs, network policy, and...

A workload may fail only on one node pool because of different runtime versions, labels, taints, network routes, storage access, or resource profiles. The application manifest can be identical across pools. What to check Compare node image and runtime versions, labels, taints, CNI and storage configuration, resource pressure, and pod events. Test...

A service rename can break environment variables, DNS references, network policies, service mesh rules, or configuration in dependent workloads. Some components may continue using cached connections to the old name. What to check Search deployment configuration and runtime logs for old service references, inspect DNS and endpoints, and map dependencies...

Pods may fail DNS queries when cluster DNS is overloaded, network policy blocks port 53, node-local caching is unhealthy, or resolver configuration points elsewhere. Workloads may fail only intermittently. What to check Check DNS service endpoints, CoreDNS health and logs, pod resolver configuration, network policies, node placement, and query latency....

A pod may fail to connect to a database because of network policy, service name, secret, TLS settings, connection limits, or database-side firewall rules. A database may be healthy for other clients while one namespace is blocked. What to check Test DNS and port reachability from the affected namespace, inspect service and endpoint objects, credentials...