Hierarchy:

• Cluster (parent)
• --- Nodes Group (collection of machines)
• ----- Node (machines)
• ------- Pods (workload units on nodes)
• --------- Containers (running applications)

Think of the Node as a hotel. In Hotel Node, each room is a pod. If the hotel's land and zoning (RAM and CPU) permit, it can have many rooms (pods) per floor, and many floors. If a node needs more rooms because it's full, then pods get assigned to a new node unless the pod itself can grow.

Here's a breakdown of parent, cluster, pod, and node, and how they relate to each other in a Kubernetes environment:

Cluster (The Parent) The overall container orchestration environment. It is a collection of physical or virtual machines (nodes) that Kubernetes manages. Highest-level object and acts as the parent of all resources. It manages everything: nodes, pods, services, and configurations. The central brain that manages the containerized applications across multiple nodes (machines).

Node Group (Node Pool) A collection of nodes that share similar configurations, such as instance types, operating systems, and resource capabilities. Node groups are typically used in cloud environments for managing autoscaling and resource allocation.

Node (Worker) The physical or virtual machine within the Kubernetes cluster that runs the containerized workloads. Each node contains the necessary services to support running containers. Master node and worker nodes.

Pod (Smallest Deployable Unit) The smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in your cluster. Pods can contain one or more closely related containers that share resources.

One pod encapsulates one or more containers that share resources such as networking (an IP address) or storage. A node is the physical or virtual machine, and using the pods use the node's resources. Each node will have multiple pods.

Multiple pods per node: Pods share the node’s resources. Pods are ephemeral: They can be created, destroyed, and moved between nodes as needed. Kubernetes ensures balance: It manages pods across the cluster to make efficient use of node resources. This model is what gives Kubernetes its scalability and flexibility—pods are lightweight and can easily move between nodes!

But why not just make a node bigger so it can handle more pods? Because if there is a problem with that node (server), then all the pods have issues. In the hotel analogy, it's like there is one big hotel that handles all the rooms for miles around. If the power goes out, then the entire hotel doesn't have power. But if there are twenty hotels, if the power is cut to one of them, then the other hotels are still available and if they have the rooms available people in the hotel that lost power can change to that hotel instead.

But why not put everything in one container, like a traditional VM? If you have an nginx server container, php server container instead of both in one container, it separates the things you need to do with each container. Changing xginx? It doesn't touch PHP, etc.