What Are Kubernetes Pods?
A “pod” in Kubernetes is the smallest and simplest unit that you can create and manage within the platform. It is a group of one or more containers, with shared storage and network resources, and a specification for how to run the containers. Each pod is meant to run a single instance of a given application, and it can contain different types of containers within it based on the needs of that application.
The pod is a useful concept because it abstracts the network and storage away from the application. This means that the application doesn’t need to know anything about the underlying infrastructure; it just needs to know how to interact with its local environment. This abstraction is what makes Kubernetes such a powerful tool for managing complex, distributed systems.
The design of pods also allows for easy scaling. You can easily create multiple identical pods for a single application, and Kubernetes automatically handles distributing and balancing the network traffic between them. This makes it possible to handle large amounts of traffic without any changes to the application itself.
This is part of a series of articles about Kubernetes troubleshooting
Kubernetes Pods Statuses
Once you have created a pod in Kubernetes, you can use the Kubernetes API to check its status. Pod statuses are crucial in understanding the health and state of a pod at any given time. There are five primary phases or statuses that a pod can be in:
- Pending: When a pod is in the Pending status, it means that it has been accepted by the Kubernetes system, but one or more of the container images has not been created. This could be because the system is pulling the image from a remote registry, there is insufficient capacity in the cluster, or another scheduling issue.
- Running: Once all of the containers in a pod have been created and at least one of them is running, or is in the process of starting or restarting, the pod is in the Running status. This means the pod is now doing whatever work it was designed to do.
- Succeeded: A pod is in the Succeeded status when all of its containers have been terminated, and will not be restarted. This usually means that the containers have completed their tasks successfully.
- Failed: When at least one container in the pod has terminated in failure, the pod is in the Failed status. A container is considered to have failed if it exited with a non-zero status.
- Unknown: The Unknown status is reserved for situations when the state of the pod could not be obtained, usually due to an error in communicating with the host where the pod is supposed to be running.
Understanding Kubernetes Pod Conditions
Pod conditions provide more detailed information about the state of the pod and its containers. Here are the main pod conditions:
PodScheduled
The PodScheduled condition means that the pod has been scheduled to one of the nodes in the cluster. This condition has three possible status values:
- True means that the scheduling was successful
- False means that the scheduling failed
- Unknown means that the system could not determine the scheduling status
Initialized
The Initialized condition indicates whether all init containers have started successfully. Init containers are the ones that run before the application containers in a pod and are usually used to set up the environment for the application. Like the PodScheduled condition, the Initialized condition can also be True, False, or Unknown.
ContainersReady
The ContainersReady condition shows the status of all containers within a pod. It indicates whether all the containers in a pod are ready to accept connections and perform their tasks:
- If the ContainersReady status is True, this means that all containers within the pod are ready, up, and running.
- If the status is False, one or more containers in the pod are not ready. This could be due to a variety of reasons such as a container crash, slow startup, or a failure in pulling the container image.
Understanding the ContainersReady condition can help troubleshoot issues within your pods. For instance, if a pod is not functioning as expected, checking the ContainersReady condition can help you identify if the problem lies with the containers.
Ready
The Ready condition is another important pod condition in Kubernetes. It indicates that a pod is ready to serve requests. A pod is considered ready when all of its containers are ready:
- If the Ready status is True, the pod is ready to serve requests and will be considered for service load balancing.
- If the status is False, the pod is not ready to serve requests.
The Ready condition is crucial as it helps you determine the overall status of your pods. It allows you to know whether your pod is fully operational or if there are any issues preventing it from serving requests.
4 Ways to Monitor Kubernetes Pod Status and Conditions
Here are the primary ways to monitor your Kubernetes pod status and conditions.
1. Checking Pod Status and Conditions with kubectl
Here is an example of how to check the status of a Kubernetes pod using the kubectl command-line tool.
kubectl get pods
The output will look something like this:
NAME READY STATUS RESTARTS AGE my-pod 1/1 Running 0 5m
The output shows that the current status of the pod is Running.
For more detailed information about a specific pod, use the command kubectl describe pod <my-pod>. This provides more detailed information about the pod, including its status, conditions, container details, and events. The output looks something like this:
Name: my-pod
Namespace: default
Priority: 0
PriorityClassName: <none>
Node: node-1/192.168.1.10
Start Time: Thu, 15 Dec 2023 10:00:00 -0800
Labels: app=my-app
Annotations: <none>
Status: Running
IP: 10.244.1.2
Controlled By: ReplicaSet/my-pod-76ff7cd74
Containers:
my-container:
Container ID: docker://1234567890abcdef
Image: my-image:latest
Image ID: docker-pullable://my-image@sha256:70f3118fda22
Port: 8080/TCP
Host Port: 0/TCP
State: Running
Started: Thu, 15 Dec 2023 10:01:00 -0800
Ready: True
Restart Count: 0
Limits:
cpu: 500m
memory: 128Mi
Requests:
cpu: 250m
memory: 64Mi
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from default-token-xyz (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
default-token-xyz:
Type: Secret (a volume populated by a Secret)
SecretName: default-token-xyz
Optional: false
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute for 300s
node.kubernetes.io/unreachable:NoExecute for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 5m default-scheduler Successfully assigned default/my-pod to node-1
Normal Pulled 4m59s kubelet, node-1 Container image "my-image:latest" already present on machine
Normal Created 4m59s kubelet, node-1 Created container my-container
Normal Started 4m58s kubelet, node-1 Started container my-container
This output includes the pod’s name, namespace, node assignment, container details, resource limits and requests, environment settings, volume mounts, pod conditions, and recent events, which can help understand and troubleshoot issues.
2. Monitoring with Kubernetes Dashboard
The Kubernetes Dashboard is a web-based Kubernetes user interface that allows you to manage your cluster and applications running in the cluster. You can use the Dashboard to deploy containerized applications, troubleshoot applications, and manage the cluster itself.
The Dashboard provides a graphical interface that displays the status and conditions of your pods. This can be useful for visualizing the state of your cluster and quickly identifying any issues. Select Workloads > Pods from the navigation bar to view essential information about your pods, including their status.
3. Leverage Kubernetes Metrics Server
The Kubernetes Metrics Server is a source of resource usage data in your cluster. It collects resource metrics from Kubelets and exposes them via the Metrics API.
You can leverage the Metrics Server to monitor your pods’ resource usage, such as CPU and memory. This can help you identify any resource bottlenecks that could be impacting your pods’ performance.
For example, once you have Metrics Server deployed in your cluster, you can use the following commands to view resource usage of pods in a specific namespace:
kubectl top pods --namespace=<namespace>
4. Use Third-Party Monitoring Tools
There are also third-party tools available that can help you monitor Kubernetes pod status and conditions. These tools often provide advanced features and capabilities that can make monitoring your Kubernetes environment easier and more efficient.
Troubleshooting Pods in Pending Status with Komodor
Troubleshooting Kubernetes pods in a pending status relies on the ability to quickly contextualize the problem with what’s happening in the rest of the cluster.
Komodor can help with our ‘Pod Status and Logs’ view, enabling you to quickly drill down in the pods of an unhealthy service, all from the comfort of your Komodor dashboard.
This offers quick access to all of the initial pod-level data you`ll need for troubleshooting, including:
- Overview of all pods running the service
- Pod details, similar to what you would get with kubectl describe
- Live view of all events
- Pod containers’ logs
However, there’s more. Komodor provides a “guided investigation” experience which enables your engineers to understand independently, with a few clicks, the actual K8s issue, map the impact, and identify the root-cause, with auto-generated step by step playbooks as well as suggested actions to remediate the issue.
If you are interested in checking out Komodor, use this link to sign up for a Free Trial.
