How Do Kubernetes Components Fit Together?

“Drivers” can mean several things, but in storage discussions it usually refers to CSI drivers, or Container Storage Interface plugins. They allow Kubernetes to work with storage systems from cloud providers or other vendors. A CSI driver can help provision, attach, mount, and discover volumes so that pods can use persistent storage. In general, Kubernetes uses plugins and drivers to connect its standard APIs to external infrastructure.

The kubelet is the Kubernetes agent running on each worker node. It receives instructions through the control plane, starts and stops containers through the container runtime, and reports the node and pod status back to the API server. The control plane handles decisions and coordination. Its main pieces include the API server, which accepts requests; etcd, which stores cluster state; the scheduler, which chooses nodes for new pods; and the controller manager, which keeps the actual state aligned with the desired state.

A useful way to think about Kubernetes is as a system that continuously works toward a desired state. You describe what you want—such as three copies of an application—and Kubernetes compares that with what is actually running, then makes corrections when something fails. A pod is the basic deployment unit and contains one or more containers. A deployment describes how many pod replicas you want, while a controller creates or replaces pods as needed. A node is a worker machine that runs pods. The cluster is the complete setup: the control plane plus the worker nodes.

Helm is separate from Kubernetes itself. It’s a package and templating tool for installing applications that require multiple Kubernetes YAML resources. A Helm chart bundles those definitions together and lets you customize values, install an application, and manage upgrades more conveniently. Helm doesn’t replace the control plane—it generates and applies Kubernetes configuration on your behalf.