Meaning:

The container is repeatedly starting, crashing, and restarting. Kubernetes is trying to run it, but it fails immediately.

Common Solutions:

• Check logs for application errors: `kubectl logs `
• Verify configuration in ConfigMaps or Secrets.
• Ensure the application isn't running out of memory (check for `OOMKilled` in `kubectl describe pod`).
• Check liveness/readiness probes for misconfiguration.

Meaning:

The cluster was unable to pull the container image from the specified registry.

Common Solutions:

• Verify the image name and tag are correct in your manifest.
• Check for typos in the registry URL.
• Ensure the cluster has network connectivity to the registry.
• If it's a private registry, confirm that an `imagePullSecret` is correctly configured and valid.

Meaning:

The container was forcefully terminated (`SIGKILL`) because it exceeded its memory limit.

Common Solutions:

• Run `kubectl describe pod ` and look for the `Reason: OOMKilled` message.
• Increase the memory `limit` and `request` for the container in your deployment manifest.
• Analyze your application for memory leaks.

Meaning:

The Pod has been accepted by the cluster, but one or more of the containers has not been started. Often due to unschedulable conditions.

Common Solutions:

• Check scheduling events: `kubectl describe pod | grep -A3 -i events`.
• Verify resource requests/limits are not too high for any node.
• Inspect node taints and Pod tolerations.
• Confirm required PersistentVolumes can bind to PVCs.

Meaning:

Kubelet is pulling the image and setting up volumes and networks. Long waits can indicate CNI or image issues.

Common Solutions:

• Check image pull progress/events and registry connectivity.
• Verify CNI plugin Pods are healthy in `kube-system` namespace.
• Ensure volume mounts exist and permissions are correct.

Meaning:

Authentication to the private registry failed.

Common Solutions:

• Create a pull secret: `kubectl create secret docker-registry regcred --docker-server= --docker-username= --docker-password= --docker-email=`.
• Reference it in your Pod/Deployment: `imagePullSecrets: [ { name: regcred } ]`.
• Ensure the secret exists in the same namespace as the workload.

Meaning:

One of the init containers is failing repeatedly, preventing main containers from starting.

Common Solutions:

• Inspect init container logs: `kubectl logs -c `.
• Validate that dependent services/volumes the init step needs are reachable/mounted.
• Check init container resource limits; they can also be OOMKilled.

Meaning:

A worker node has failed its readiness checks. Pods already scheduled there may stay running, but no new Pods will land until the node recovers.

Common Solutions:

• Review node conditions: `kubectl describe node | grep -A4 Conditions`.
• Check kubelet and systemd service status on the node; restart kubelet if required.
• Validate CNI/CSI Pods on that node by inspecting `kubectl get pods -n kube-system -o wide`.
• If the node is lost, `kubectl cordon` and `kubectl drain` it, then remove with `kubectl delete node`.

Meaning:

The container failed to start after being created. Startup commands, permissions, or image entrypoints are common culprits.

Common Solutions:

• Inspect events with `kubectl describe pod ` to see detailed error messages.
• Review container logs (if any were written) using `kubectl logs --previous`.
• Ensure the `command`/`args` in the manifest match the container image expectations.
• Use `kubectl debug --image=busybox` for an ephemeral shell to inspect mounted volumes and permissions.

Meaning:

Pods that depend on custom resources (like cert-manager, operators) are failing due to missing or misconfigured CRDs.

Common Solutions:

• Check if CRDs are properly installed: `kubectl get crd | grep `.
• Verify custom resource status: `kubectl describe `.
• Check operator logs: `kubectl logs -n -l app=`.
• Ensure proper RBAC permissions for service accounts: `kubectl auth can-i '*' '*' --as system:serviceaccount::`.

Meaning:

A PVC cannot bind to an available PersistentVolume, often due to storage class issues or resource constraints.

Common Solutions:

• Check available PVs: `kubectl get pv` and verify if any match the PVC requirements.
• Verify storage class exists: `kubectl get storageclass` and check if it's set as default.
• Review PVC events: `kubectl describe pvc ` for detailed binding failures.
• Check if dynamic provisioner is running: `kubectl get pods -n kube-system | grep `.

Meaning:

A Service exists but traffic cannot reach the underlying Pods, indicating selector or networking issues.

Common Solutions:

• Verify service endpoints: `kubectl get endpoints ` - should list Pod IPs.
• Check label selectors match: `kubectl get pods --show-labels` and compare with service selector.
• Test from within cluster: `kubectl run tmp-shell --rm -it --image=busybox -- nslookup `.
• Check NetworkPolicies: `kubectl get networkpolicy` and verify they allow required traffic.

Meaning:

TLS handshake failures, expired certificates, or missing certificate secrets causing connection issues.

Common Solutions:

• Check certificate secrets: `kubectl get secrets --field-selector type=kubernetes.io/tls`.
• Verify certificate validity: `kubectl get secret -o jsonpath='{.data.tls\.crt}' | base64 -d | openssl x509 -text`.
• Review certificate signing requests: `kubectl get certificatesigningrequests`.
• Check cert-manager logs if using it: `kubectl logs -n cert-manager -l app=cert-manager`.