How to debug a Kubernetes service deployment

If you are working on kubernetes or heard about that with someone working on kubernetes, says Kubernetes is complex and hard to manage or troubleshoot. Same time you may see in kubernetes cluster either one, goes wrong sometimes. One of the key reasons for this could be it contains many components and variables, that may make it complicate to understand what the issue is.

Always remember the fundamental rules of troubleshooting in any scenarios.

1. Use historical data, such as logs, and observation to identify the root cause of a problem.
2. One of the key rules for the troubleshooting When you are ascertaining the cause or trying a fix, change only one variable at a time.
3. Before trusting a fix, confirm that it works under different conditions.

As like basic of the troubleshooting, you should understand the component or architecture of the tool, like that in Kubernetes understand the components and administrative commands. This is critical to execute the first rule successfully and to debug Kubernetes application and service deployments.

Check the Events

Kubectl is the primary administrative tool for Kubernetes clusters and includes other commands. The command “kubectl get” reveals basic information about a particular resource. For example, “kubectl get pods” lists the available pods and their status, while “kubectl get services” lists the applications running as a service on a set of pods.

However, a more detailed option exists for troubleshooting: “kubectl describes pods”, also used as “kubectl describes pod (TYPE/NAME)”, provides detail about container or pod labels, resource requirements, state, readiness, restart count and events.

For example, an admin finds that “kubectl get pods” for a Nginx application shows a particular pod isn’t running. Using “kubectl describe pod nginx-wcre” shows the admin that the pod couldn’t be scheduled, due to inadequate available resources. The following is a subset of returned output that demonstrates the problem:

Name:      nginx-wcre
  Namespace:    default
  Node:         /
  Labels:       app=nginx,pod-template-hash=fut
  Status:       Pending
...
  Events:
FirstSeen LastSeen Count From SubobjectPath Type Reason Message
2m        56s      10    {default-scheduler} Warning
FailedScheduling pod (nginx-deployment-wcre-as2aq) failed to fit in any node
fit failure on node (kubernetes-node-xxx): Node didn't have enough resource: CPU, requested: 250, used: 800, capacity: 1000

In this case resources are only one possible reason a pod might not work. Others include one or more downed nodes or connectivity problems with the internal or external load balancers.

Continue reading on How to debug a Kubernetes service deployment — FoxuTech