Containers, Kubernetes & Platform Engineering

A Kubernetes CronJob can create overlapping work when an earlier run takes longer than its schedule, a controller misses and catches up, or retries are mistaken for new runs. Duplicate jobs can repeat payments, reports, or data updates if the workload is not idempotent. What to check Inspect CronJob concurrency policy, schedule timezone, job history,...

A node that repeatedly becomes NotReady can disrupt workloads and trigger rescheduling. The cause may be resource pressure, a failing kubelet, container runtime errors, network loss, or storage problems rather than the application pods themselves. What to investigate Review node conditions, kubelet and runtime logs, resource pressure, disk and inode...

Pods can be evicted when writable layers, logs, or temporary files consume node storage. Increasing persistent volume size may not help if the usage comes from ephemeral container storage or unbounded logs. What to check Review eviction events, node disk and inode pressure, container writable-layer usage, log growth, temporary directories, and...

A container can be killed for exceeding its own memory limit even while the Kubernetes node has free memory. The pod limit, application heap settings, sidecars, and burst patterns determine whether the workload reaches its ceiling. What to check Check container and pod memory limits, working set and peak usage, restart reason, sidecar consumption, and...

A pod may fail to start when the registry credential is missing, expired, attached to the wrong namespace, or inaccessible from the node. The image name or tag may also reference a repository the workload identity cannot read. What to check Inspect pod events, image reference, pull secret namespace and service account association, registry permissions,...

A Kubernetes Secret update may not be picked up by an application that reads it only at startup, or a mounted file can change while the application keeps using an old connection. A rollout can also reference the wrong secret name or namespace. What to check Check secret version and namespace, pod template references, mount behavior, environment...

A Kubernetes workload may be healthy internally but unable to reach an external provider because of egress policy, DNS, proxy settings, NAT capacity, TLS trust, or rate limits. Other workloads on the cluster may use a different network path. What to check Test DNS and connectivity from the affected pod or an approved diagnostic workload. Review network...

A pod may mount a persistent volume successfully but lack permission to write because of filesystem ownership, storage access mode, security context, or a read-only mount. The issue can affect only one workload using the same storage class. What to check Check mount status, volume and claim events, pod security context, filesystem ownership, access...