Introspection
1. Introspection
Now that you've been introduced to the kubectl command, which is the way to specify the action that you want to perform on a Kubernetes cluster, let's explore how to debug problems when an application is running. This process is called introspection. It's the act of gathering information about the containers, pods, services, and other engines that run within the cluster. We'll start with four commands to use to gather information about your app: get, describe, exec, and logs. A good place to start is with Pods, the basic units of Kubernetes. A simple kubectl "get pods" command tells you whether your Pod is running. It shows the Pod's phase status as pending, running, succeeded, failed, or unknown, or CrashLoopBackOff. The phase provides a high-level summary, not the comprehensive details about a Pod or its containers. The pending status indicates that Kubernetes has accepted a Pod, but it's still being scheduled. This means that the container images defined for the Pod have not yet been created by the container runtime. For example, when images are being pulled from the repository, the Pod will be in the pending phase. A Pod runs after it is successfully attached to a node, and all its containers are created. Containers inside a Pod can be starting, restarting, or running continuously. Succeeded means that all containers finished running successfully, or instead, that they terminated successfully and they won't be restarting. Failed means a container terminated with a failure, and it won't be restarting. Unknown is where the state of the Pod simply cannot be retrieved, probably because of a communication error between the control plane and a kubelet. And CrashLoopBackOff means that one of the containers in the Pod exited unexpectedly even after it was restarted at least once. This is a common error. Usually, this means that the Pod isn't configured correctly. To investigate a Pod in detail, use the kubectl "describe pod" command. This command provides information about a Pod and its containers such as labels, resource requirements, and volumes. It also details the status information about the Pod and container. For Pods, the name, namespace, node name, labels, status, and IP address are displayed. For containers, the state–waiting, running, or terminated, images, ports, commands, and restart counts–are displayed. Single command execution using the exec command lets you run a single command inside a container and view the results in your own command shell. This is useful when a single command, such as ping, will do. And finally, the logs command provides a way to see what is happening inside a Pod. This is useful in troubleshooting, as the logs command can reveal errors or debugging messages written by the applications that run inside Pods. The logs contain both the standard output and standard error messages that the applications within the container have generated. The logs command is useful when you need to find out more information about containers that are failing to run successfully. And if the Pod has multiple containers, you can use the -c argument to show the logs for a specific container inside the Pod. There might be a scenario where you need to work inside a Pod, maybe to run a command. Let's say you need to install a package, like a network monitoring tool or a text editor, before you can begin troubleshooting. To do so, you can launch an interactive shell using the -it switch, which connects your shell to the container that allows you to work inside the container. This syntax attaches the standard input and standard output of the container to your terminal window or command shell. The -i argument tells kubectl to pass the terminal's standard input to the container, and the -t argument tells kubectl that the input is a TTY. If you don't use these arguments then the exec command will be executed in the remote container and return immediately to your local shell. Now it's important to note that it's not a best practice to install software directly into a container, as changes made by containers to their file systems are usually ephemeral. Instead, consider building container images that have exactly the software you need, instead of temporarily repairing them at run time. The interactive shell will allow you to figure out what needs to be changed to solve a problem, but you should then integrate those changes into your container images and redeploy them.2. Let's practice!
Create Your Free Account
or
By continuing, you accept our Terms of Use, our Privacy Policy and that your data is stored in the USA.