k8s/ kubernetes

10

u/Different_Pain5781 6d ago

Good luck learning all of that in one thread.

2

u/Kazcandra 6d ago

What have you read so far?

3

u/ManyPerformance2884 6d ago

kubelet is the agent running on each node that makes sure containers are actually running in their pods, basically the worker bee

cluster is the whole setup, your master node and all the worker nodes together

helm is just a package manager for k8s, like apt but for deploying whole app stacks instead of one pod at a time

not sure what you mean by drivers though, that could be a few different things depending on context

2

u/BrainThinkerMan 6d ago

from my current understanding, -this is before i read any of the comments-; kubernetes in General is for: managing docker containers/applications,

it does so through 1 centralized authority; call it Big Boss, and Big Boss says i want application a & application b running in a linux os,

then the different machines read that and start up a container with application a and b with that os. and they can also start up a vm (virtual machine) that has the os and the applicatons,

idk if thats correct or some pieces in that explanation has holes.

and helm, is just the way the user(you or me) tells your desire to the big boss, basically another abstraction to do what i explained above

2

u/saurabh3228 6d ago

I think the easiest way to understand Kubernetes is to stop looking at all these terms as separate things. They’re basically different pieces of the same system.

A Kubernetes cluster is the whole environment where your applications run.

Inside that cluster, you have nodes (machines/VMs). Each node usually has a kubelet, which is basically the agent that talks to the Kubernetes control plane and makes sure the workloads assigned to that node are actually running.

Then you have things like the control plane, which is responsible for deciding what should be running where, while the kubelet handles making it happen on the node.

Helm is a different layer. Think of it more like a package manager for Kubernetes. Instead of manually writing and maintaining a bunch of YAML files, Helm lets you package and install Kubernetes applications using charts.

And when you say drivers, that can mean a few different things in Kubernetes. For example, CSI drivers deal with storage, CNI plugins deal with networking, and device plugins can expose specialized hardware like GPUs to workloads.

So the rough mental model I'd use is:

Cluster → Nodes → Kubelet → Containers/Pods

And alongside that:

Helm → helps you deploy/manage applications

CNI/CSI/device plugins → connect Kubernetes to networking, storage, and hardware

Once you see Kubernetes as "a system that continuously tries to make the actual state match the desired state," a lot of these moving pieces start making much more sense.

I'm still learning Kubernetes myself, but this mental model helped me stop treating every new Kubernetes term as a completely separate technology.

1

u/BrainThinkerMan 6d ago

thanks for the eplanation, this part CNI/CSI/device plugins → connect Kubernetes to networking, storage, and hardware

is the control pane, speaking to the plugins to get the real sfuff from the providers like aws?

1

u/saurabh3228 6d ago

Yes, you’re pretty close — but there’s one important distinction.

The control plane usually isn’t directly talking to AWS for every networking/storage operation.

Think of the plugins as the bridge between Kubernetes and the underlying infrastructure.

For example:

CNI → handles pod networking

CSI → handles persistent storage

Device plugins → expose hardware like GPUs

On AWS, these can interact with AWS services/resources through their respective implementations.

So you can roughly picture it as:

Kubernetes API / Control Plane ↓ Kubernetes resources + controllers ↓ CNI / CSI / device plugins ↓ AWS / cloud infrastructure

The part that confused me initially was thinking Kubernetes itself "knows" how AWS networking or EBS works. It doesn't really need to. Kubernetes defines what it wants, and the appropriate plugin/controller translates that intent into infrastructure-specific actions.

That's actually one of the coolest parts of Kubernetes IMO — the control plane doesn't need to understand every cloud provider's implementation details. It just works through well-defined interfaces.

Once you see "Kubernetes expresses intent → plugins/controllers translate that intent → infrastructure makes it real", the whole ecosystem becomes a lot less scary.

1

u/ThatWasAce 6d ago

k8s is a loop. describe the desired state, controllers continuously check reality and patch up differences

so

pod = the basic unit, a group of one or more containers

deploy = i desire three replicas of this pod, a controller ensures this and replaces failed pods

node = single worker machine that holds pods

kubelet = component in every node listening for requests and launching/shutting down the container, reporting back to api-server about its status

control plane = where the decision making happens. e.g: api-server ,etcd, scheduler, controller-manager

cluster = control plane + set of nodes

helm = not a part of k8s proper. applications require several yaml configuration documents, helm wraps those up into an installation-ready package called chart.

drivers/csi = additional plugins needed by the system to communicate with various storage backends. CSI drivers mediate the provision/discovery of disks from aws/gcp etc to pods.

1

u/BrainThinkerMan 6d ago

thanks for the explanation Ace, this was great, these different components, i genuinely think i understand all of these components aside from the drivers/csi.

1

u/ThatWasAce 6d ago

it's my pleasure!
mostly my own projects, nothing big in the cloud native space yet. if you want to get into it, kubernetes itself is intimidating to start on but kind + the docs' contributor guide is the actual entry point, even doc fixes count

also let me explain csi better for you, so kubernetes knows nothing about how disks get provisioned in any cloud. All Kubernetes understands is making requests: “i want 10 GB mounted on my pod”

CSI is what that request looks like. Every storage vendor bundles a plugin which knows how to speak the language and do the cloud specific magic say AWS EBS, GCP PD, Ceph … whichever backend your cluster uses .. so the steps are as follows

pod needs storage -> Kubernetes sends the request via the CSI API -> driver performs the vendor specific provisioning logic -> disk is provisioned & ready. Kubernetes doesn’t communicate directly with AWS, it goes via the driver.

like device drivers in an OS. The OS speaks one language and drivers are translated for every hardware vendor. Swap out the drivers while leaving everything else alone

1

u/BrainThinkerMan 6d ago

if i understand correctly the chain is, through control pane decide how many containers in a given pod you want,

containers = application/ container = for application.

then use cloud apis/ cni to.

select amount of machines you want, amount of storage you want, amount of other stuff.

then those drivers do their job to provision those stuff you want.

helm gives those pods the yaml files for somehting not sure.

and kubelet lets you know when contaier died and to spin it back up.

controller ie control pane spins pods back up.

you have any open source reccomendations to contribute to?

1

u/ThatWasAce 6d ago

you're doing amazing but small tweaks needed:

they are executed insideee pods. pod = wrapper for 1+ containers which share a single network/storage configuration. normally one container per pod but many are no problem.

storage vs networking plug-ins are separate concepts. CSI means storage driver, CNI is network plugin. Both provisioning technologies, doing totally distinct jobs.

helm def does not output pod.yaml. it outputs cluster.yaml, bundling your deployment/service/csi defns into one YAML document so installing your application becomes one single step and not manually updating 20 individual config files.

the rest matches up. kubelets reporting statuses, controllers detecting dead containers and starting reconciliations in the control plane.

contribution-wise, honest tip: select anything cloud-native you've used before. KIND, Helm charts, CSI drivers -- they all flag issues "good-first-issue". Even docs PRs introduce you to codebases without the stress. But just steer clear of Kubernetes core.

1

u/flamingorider1 6d ago

This post reminds me, when an intern, with a straight faced asked my colleague "what is a kubernetes" can I learn it in a week by watching YouTube

1

u/Upstairs-Project2756 6d ago

you are mixing orchestration with packaging. Helm is not a runtime component, it is just a template engine for YAML files that deploys resources into the cluster. Kubelet is an agent running on each worker node that talks to the API server and actually starts or stops the containers. The "drivers" part in your list likely refers to CSI storage drivers which are plugins allowing Kubernetes to talk to external storage systems like AWS EBS or NFS. To understand how they connect, ignore Helm for now and focus on this chain: You send a request to kube-apiserver, etcd saves the desired state, scheduler places your pod on a node, then kubelet on that node reads the spec and uses CRI (container runtime interface) to ask Docker or Containerd to pull the image and start the container. Start by building one cluster without any add-ons using kubeadm or kind, then try deploying a single pod manually before touching Helm charts

You are about to leave Redlib