Kubernetes Tutorial - Viewing Pods and Nodes

Target

Learn about Kubernetes Pods.
Learn about Kubernetes nodes.
Troubleshoot deployed applications.

Kubernetes Pod

When you created a Deployment in Module 2 , Kubernetes created a Pod to host your application instance. Pod is abstracted by Kubernetes and represents a group of one or more application containers (such as Docker) and some shared resources of these containers. These resources include:

shared storage, as a volume
network, as the unique cluster IP address
Information about how each container is running, such as the container image version or the specific port to use

Pods model application-specific "logical hosts" and can contain relatively tightly coupled containers of different applications. For example, a Pod might contain both a container with a Node.js application and a different container that provides data to be published by a Node.js web server. Containers in a Pod share IP addresses and ports, are always co-located and co-scheduled, and run in a shared context on the same node.

A Pod is an atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, the Deployment creates Pods containing containers in it (instead of creating containers directly). Each Pod is bound to the node on which it was scheduled, and remains there until terminated (according to restart policy) or deleted. If a node fails, the same Pods are scheduled on other available nodes in the cluster.

Summarize:

Pod
node
Kubectl main commands

A Pod is a collection of one or more application containers (such as Docker), including shared storage (volumes), IP addresses, and information about how to run them.

Pod overview

node

Pods always run on nodes . A node is a computing machine in Kubernetes, which can be a virtual machine or a physical computer, depending on the cluster. Each node is managed by the control plane. A node can have multiple pods, and the Kubernetes control plane automatically handles scheduling pods on nodes in the cluster. The automatic scheduling of the control plane takes into account the available resources on each node.

Each Kubernetes node runs at least:

Kubelet, the process responsible for the Kubernetes control plane and communication between nodes; it manages the pods and containers running on the machine.
A container runtime (such as Docker) is responsible for pulling the container image from the registry, unpacking the container, and running the application.

Containers should only be orchestrated in a Pod if they are tightly coupled and need to share resources such as disks.

Node overview

Troubleshooting with kubectl

In Module 2 , you used the kubectl command line interface. You'll continue using kubectl in module 3 to get information about the deployed application and its environment. The most common operations can be accomplished with the following kubectl subcommands:

kubectl get - list resources
kubectl describe - Display detailed information about a resource
kubectl logs - Prints the logs of containers in a Pod
kubectl exec - Execute commands on containers in a Pod

You can use these commands to see when your application was deployed, its current state, where it is running, and its configuration.

Now that we know more about the cluster components and the command line, let's explore our application.

Nodes are machines in Kubernetes that are responsible for computation, and may be virtual machines or physical computers, depending on the cluster. Multiple Pods can run on a single node.

Check application configuration

Let's verify that the application deployed in the previous scenario is running. We will use kubectl get the command to view existing Pods:

kubectl get pods

If no pods are running, wait a few seconds for the pods to be listed again. Once you see a pod running, you can move on.

Next, to see what containers are in the Pod and what images were used to build them, we run kubectl describe pods the command:

kubectl describe pods

Here we see details about the Pod's container: the IP address, the ports used, and a list of events related to the Pod's lifecycle.

The describe subcommand's output is broad and covers some concepts we haven't covered yet, but don't worry, you'll be familiar with them by the end of this lesson.

Note: The describe subcommand can be used to get detailed information about most Kubernetes primitives, including Nodes, Pods, and Deployments. The output of describe is designed to be human-readable, not scripted.

Show application in terminal

Recall that Pods run on isolated, private networks, so we need a proxy to access them for debugging and interaction. In order to do this, we will use kubectl proxy the command to run a proxy in a second terminal . Open a new terminal window and run the following command in this new terminal:

kubectl proxy

Now we get the pod command again and query the pod directly through the proxy. To get the Pod command and store it in the POD_NAME environment variable, run the following command:

export POD_NAME="$(kubectl get pods -o go-template --template '{
   
   {range .items}}{
   
   {.metadata.name}}{
   
   {"\n"}}{
   
   {end}}')"
echo Name of the Pod: $POD_NAME

To see the output of the application, run curl the request:

curl http://localhost:8001/api/v1/namespaces/default/pods/$POD_NAME:8080/proxy/

The URL is the route to the Pod API.

View container logs

Everything an application would normally send to stdout becomes a log for a container within a Pod. We can kubectl logs retrieve these logs with the command:

kubectl logs "$POD_NAME"

Note: We don't need to specify a container name because there is only one container inside the Pod.

Execute the command on the container

Once the Pod is up and running, we can execute commands directly on the container. To do this, we use exec a subcommand with the name of the Pod as an argument. Let's list the environment variables:

kubectl exec "$POD_NAME" -- env

It's also worth mentioning that since there is only one container in a Pod, the name of the container itself can be omitted.

Next, let's start a bash session in the Pod's container:

kubectl exec -ti $POD_NAME -- bash

We now have an open console on the container running our Node.js application. The source code for the app is in the server.js file:

cat server.js

You can see if the app is started by running the curl command:

curl http://localhost:8080

Note: We used localhost here because we executed this command inside a NodeJS Pod. If you can't connect to localhost:8080, make sure you've run kubectl exec the command and started it from within the pod.

To close your container connection, type exit.