[Kubernetes] – P.3 – Pods and Nodes

Kubernetes Pods

  • A Pod is a group of one or more application containers (such as Docker or rkt) and includes shared storage (volumes), IP address and information about how to run them.

A Pod is a Kubernetes abstraction that represents a group of one or more application containers, and some shared resources for those containers. Those resources include: 

  • Shared storage (as Volumes)
  • Networking (as a unique cluster IP address)
  • Information about how to run each container  (such as the container image version or specific ports to use)

A Pod models an application-specific “logical host” and can contain different application containers which are relatively tightly coupled. For example, a Pod might include both the container with your Node.js app as well as a different container that feeds the data to be published by the Node.js web server. The containers in a Pod share an IP Address and port space, are always co-located and co-scheduled, and run in a shared context on the same Node.

Pods are the atomic unit on the Kubernetes platform. When we create a Deployment on Kubernetes, that Deployment creates Pods with containers inside them (as opposed to creating containers directly). Each Pod is tied to the Node where it is scheduled and remains there until termination (according to restart policy) or deletion. In case of a Node failure, identical Pods are scheduled on other available Nodes in the cluster.

 

Nodes

A Pod always runs on a Node. A Node is a worker machine in Kubernetes and may be either a virtual or a physical machine, depending on the cluster. Each Node is managed by the Master. A Node can have multiple pods, and the Kubernetes master automatically handles scheduling the pods across the Nodes in the cluster. The Master’s automatic scheduling takes into account the available resources on each Node.

Every Kubernetes Node runs at least:

  • Kubelet, a process responsible for communication between the Kubernetes Master and the Node; it manages the Pods and the containers running on a machine.
  • A container runtime (like Docker, rkt), responsible for pulling the container image from a registry, unpacking the container, and running the application.

Troubleshooting with kubectl

The most common operations can be done with the following kubectl commands:

  • kubectl get – list resources
  • kubectl describe – show detailed information about a resource
  • kubectl logs – print the logs from a container in a pod
  • kubectl exec – execute a command on a container in a pod

You can use these commands to see when applications were deployed, what their current statuses are, where they are running and what their configurations are.

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

Step 1: Check application configuration

We’ll use the kubectl get command and look for existing Pods

kubectl get pods

To view what containers are inside that Pod and what images are used to build those containers we run the describe podscommand:

kubectl describe pods

Step 2: Show the app in the terminal

Open a new terminal and run the command:

kubectl proxy

Next, we’ll get the Pod name and query that pod directly through the proxy to get the Pod name and store it in the POD_NAME environment variable:

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

And you will see something like this on the terminal if success

Name of the Pod: kubernetes-bootcamp-6bf84cb898-tf98f

To see the output of our application:

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

Step 3: View the container logs

Anything that the application would normally send to STDOUTbecomes logs for the container within the Pod. We can retrieve these logs using the kubectl logs command:

kubectl logs $POD_NAME

Step 4: Executing the command on the container

We can execute commands directly on the container once the Pod is up and running. For this, we use the exec command and use the name of the Pod as a parameter. Let’s list the environment variables:

kubectl exec $POD_NAME env

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

kubectl exec -ti $POD_NAME bash

From the bash session, we can view the source code of the app is in the server.js file:

cat server.js

Also, we can check that the application is up by running a curl command:

curl localhost:8080

Leave a Reply

Your email address will not be published. Required fields are marked *