Pods and Nodes
In Module 2, the Deployment created a Pod which hosted your application instance. A Pod is a group of one or more application containers (such as Docker or rkt) that includes shared storage (volumes), a unique cluster IP address and information about how to run them (like container image version or specific ports). Containers within a Pod share an IP Address and port space. Containers of the same Pod are always co-located and co-scheduled, and run in a shared context on the same node. A Pod models an application-specific “logical host” and contains one or more application containers which are relatively tightly coupled. An example of container that would fit on the same Pod with our the NodeJS app, would be a side container that feeds the data published by the webserver. In a pre-container world, they would have run on the same physical or virtual machine.
Pods are tied to the Node where they are deployed and remain there until termination (according to restart policy) or deletion. In case of a Node failure, new identical Pods will be deployed on other available Nodes. The Pod is the atomic deployment unit on the Kubernetes platform. When we trigger a Deployment on Kubernetes, it will create Pods with containers inside them, not containers directly.
- Kubectl main commands
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.
Pods always run on Nodes. A Node is a worker machine in Kubernetes and may be a VM or a physical machine, depending on the cluster. Each Node runs Pods and is managed by the Master. On a Node you can have multiple pods. The scheduling of Pods is performed automatically by the Master and this takes into account the available resources on the Nodes.
Every Kubernetes Node runs at least:
- A container runtime (like Docker, rkt) that will take care of pulling all your containers from a registry.
- Kubelet, that acts as a bridge between the Kubernetes Master and the Nodes; it manages the Pods and the containers running on a machine.
Containers should only be scheduled together in a single Pod if they are tightly coupled and need to share resources such as disk.
Troubleshooting with kubectl
In Module 2 we introduced the kubelet cli tool. We’ll use it in this module to get information about deployed applications and their environments. 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
Those commands will help you see when applications were deployed, what their current status is, where they are running and what their configuration is.
Now that we know more about our cluster components and the command line, let’s explore our application.
A node is a worker machine in Kubernetes and may be a VM or physical machine, depending on the cluster. Multiple Pods can run on one Node.