Core Concepts and Terminology in Kubernetes

Most concepts in Kubernetes—such as Node, Pod, Replication Controller, and Service—can be considered "resource objects." Almost all resource objects can be created, read, updated, deleted, or otherwise manipulated via the kubectl command-line tool (or API calls) provided by Kubernetes, and they are persisted in etcd. From this perspective, Kubernetes is a highly automated resource control system. It achieves advanced functions like automatic control and self-healing by continuously tracking the difference between the "desired resource state" stored in etcd and the "actual resource state" in the current environment.

Master

The Master is the cluster control node. Every Kubernetes cluster requires a Master node to manage and control the entire cluster. Essentially, all control commands are sent to the Master, which is responsible for executing them. All commands we run later are executed on the Master node. The Master node usually occupies a dedicated physical server (or a virtual machine) because it is crucial—it acts as the "brain" of the entire cluster. If it goes down or becomes unavailable, all control commands become ineffective. The following key processes run on the Master node:

• kube-apiserver: Provides the HTTP REST interface, serving as the only entry point for all CRUD operations on Kubernetes resources and the control entry point for the cluster.
• Kubernetes Controller Manager: The automation control center for all resource objects in Kubernetes, acting as the "general manager" of resource objects.
• Kubernetes Scheduler: The process responsible for resource scheduling, analogous to the "dispatch office" for a bus system.
• etcd: Often runs on the Master node as well, since all resource object data in Kubernetes is stored in etcd.

Node

All other machines in a Kubernetes cluster, besides the Master, are called Node nodes. Like the Master, a Node can be a physical host or a virtual machine. Nodes are the workload-bearing units in the cluster. Each Node is assigned workloads (Docker containers) by the Master. If a Node goes down, its workloads are automatically transferred to other nodes by the Master.

The following key processes run on each Node node:

• kubelet: Responsible for creating, starting, and stopping containers corresponding to Pods, and collaborates closely with the Master node to achieve basic cluster management functions.
• kube-proxy: A crucial component that implements communication and load balancing mechanisms for Kubernetes Services.
• Docker Engine: The Docker engine, responsible for creating and managing containers on the node.

Nodes can be dynamically added to a Kubernetes cluster while it is running. Once a Node is incorporated into the cluster's management scope, the kubelet process periodically reports its status to the Master—including the operating system, Docker version, CPU and memory usage, and which Pods are running on it. This allows the Master to understand each Node's resource utilization and implement efficient, balanced resource scheduling strategies. If a Node fails to report status within a specified time, the Master determines it is "unreachable" and marks its status as NotReady. Subsequently, the Master triggers an automatic "workload migration" process.

Commands to interact with Nodes:

# List all nodes in the cluster
kubectl get nodes

# Show detailed information about a specific node
kubectl describe node <node-name>

Pod

The Pod is the most important and fundamental concept in Kubernetes. A Pod is the smallest deployable unit of computing that you can create and manage. It contains one or more tightly coupled containers. A Pod can be thought of as a "logical host" at the application layer within a containerized environment. Each Pod includes a special container called the "pause" container, which acts as the root container. The pause container image is part of the Kubernetes platform. Besides the pause container, each Pod contains one or more closely related user business containers.

Why did Kubernetes design the Pod concept? Each container typically represents a single application. For a group of related containers to communicate with each other, they need to share network and storage resources. In a Pod, multiple business containers share the IP address of the pause container and also share the volumes mounted to the pause container. This simplifies communication between closely related containers and solves file-sharing issues among them.

Service

In the Kubernetes world, although each Pod is assigned a unique IP address, this IP address is ephemeral—it disappears when the Pod is destroyed. This raises a question: if a group of Pods forms a cluster to provide a service, how do you access it? The answer is Service.

A Service can be considered the external access interface to a group of Pods that provide the same service. The set of Pods a Service targets is defined using label selectors.

Characteristics of a Service:

• Has a specific name (e.g., my-mysql-server).
• Has a virtual IP (Cluster IP, Service IP, or VIP) and port number that remain unchanged until the Service is destroyed. This IP is only accessible within the cluster network.
• Provides some remote service capability.
• Is mapped to a set of Pod containers that offer that service.

If a Service needs to be accessilbe from outside the cluster, you must specify a public IP, a NodePort, or an external load balancer.

NodePort: The system opens a real port on the host machine of each Node in the Kubernetes cluster. Clients that can access that Node can then reach the Service through that port.

Commands to work with Services:

# List all services in the namespace
kubectl get services

# Show detailed information about a specific service
kubectl describe service <service-name>