How to Monitor Kubernetes Pod Uptime and Status

How to Monitor Kubernetes Pod Uptime and Status

Kubernetes has become the standard orchestrator for containerized workloads in SaaS architectures. While Kubernetes simplifies deployment scaling and load balancing, its distributed nature makes tracking application health more complex.

In a cluster environment, pods are transient. They are created, rescheduled, and terminated automatically by controllers. Troubleshooting pod crashes requires a systematic approach to analyzing logs, events, and metrics.

If you are asking: How do I monitor Kubernetes pod uptime and status? This guide covers CLI diagnostics using kubectl, understanding unhealthy states like CrashLoopBackOff, and configuring Kubernetes probes for automated recovery.

1. Quick CLI Diagnostics: The kubectl Toolset

The kubectl command-line utility is the primary tool for auditing pod status and resource utilization:

Inspecting Pod Health

# Get all pods in the default namespace
kubectl get pods

# Get all pods across all namespaces (useful for system logs)
kubectl get pods -A

# View extended pod data, including assigned node IPs
kubectl get pods -o wide

# Monitor pod state transitions in real time
kubectl get pods -w

Checking CPU and Memory Limits

If the Kubernetes Metrics Server is installed in your cluster, you can verify container resource consumption using:

# Show resource consumption of all pods in the active namespace
kubectl top pods

# Sort all pods across the cluster by memory usage
kubectl top pods -A --sort-by=memory

2. Troubleshooting Unhealthy Pod States

When running kubectl get pods, pay attention to the STATUS column. Common error states include:

• CrashLoopBackOff: The container is starting, crashing, and restarting repeatedly. This is typically caused by application configuration errors, missing environment variables, or database connection failures.
• OOMKilled: The container exceeded its hard memory limit set in the deployment manifest, causing the kernel to terminate the process.
• ImagePullBackOff: The node cannot pull the container image from the registry (often due to authentication errors or incorrect image tags).

To diagnose these states, inspect the lifecycle logs and cluster events:

# View detailed metadata and recent event history for a specific pod
kubectl describe pod <pod-name>

# View standard output logs for a running container
kubectl logs <pod-name>

# View logs from a previous, crashed container instance
kubectl logs <pod-name> --previous

3. Configuring Kubernetes Liveness and Readiness Probes

To automate self-healing, define readiness and liveness probes in your deployment configuration.

• Readiness Probes: Determine if a container is ready to accept user traffic. If the readiness probe fails, the ingress controller removes the pod from the load balancer pool.
• Liveness Probes: Determine if the container needs to be restarted. If a liveness probe fails, Kubernetes terminates the pod and spawns a new instance.

Deployment Manifest Configuration Example

Add this block under the container specification in your deployment manifest:

spec:
  containers:
  - name: saas-api
    image: company/api:latest
    ports:
    - containerPort: 8080
    readinessProbe:
      httpGet:
        path: /healthz/ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
    livenessProbe:
      httpGet:
        path: /healthz/live
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 20

4. Production Observability and External Ingress Audits

For production clusters, teams run Prometheus and Grafana to track resource thresholds and generate alerts. Key indicators include pod restart loops, container memory limits, and ingress latency spikes.

In addition to internal cluster monitoring, it is critical to run external audits. An internal pod might report it is healthy, but if the ingress controller (such as Nginx Ingress or AWS ALB) is misconfigured, external traffic will be blocked.

Pingzo provides external validation by monitoring your public endpoints. It verifies that your Kubernetes Ingress routes load successfully from outside the cluster. If your cluster experiences an ingress timeout or a DNS failure, Pingzo will bypass internal tools and alert your team via WhatsApp within seconds.