DEV Community: Catt

day5: kubelet

Catt — Fri, 12 Dec 2025 02:51:20 +0000

Short and sweet one on the Kubelet today.

Kubelet is like a captain on a ship in the ship analogy - it asks for the paperwork necessary to become part of the cluster. It is sole point of contact from the master/control plane ship, it loads and unloads containers on the ship as instructed by the Scheduler, and it sends back reports on the status of the ship as well as the containers on them.

The Kubelet registers the worker node with a Kubernetes cluster. When it receives instructions to load a pod on the node with a container, it requests the container runtime engine to pull and run an image. The Kubelet will then continue to monitor the state of the pod and containers in it, and then reports this back to the Kube API server.

I personally think of the Kubelet as the manager of the node and what's going on on it - the fact that it's the one doing status reports to the API server encapsulates what I think of when I think of the Kubelet, especially as it needs to know the state and status of the pods in this way. Also it's the one instructing the container runtime.

Even with the Kube Admin Tool, the Kubelet needs to be manually installed on the worker nodes - download the installer, extract it, and run it as a service.

You can view the running Kubelet process and options by listeing the process on the worker node and search for kubelet with ps aux | grep kubelet

Sweet and simple!

- Catt

day4: kube scheduler

Catt — Thu, 11 Dec 2025 03:12:18 +0000

Day 4, writing about the Kubernetes Scheduler!

The Kubernetes scheduler is responsible for deciding which pods go on which nodes - it doesn't place the pods on the nodes but it notes which node a pod should go on. The Kubelet is the actual agent that is responsible for creating pods on the nodes.

The Scheduler is for ensuring that the right pods end up on the right notes - in the previous analogy with the ships, there are different sizes of ships and different destinations to which the ships are directed, and the containers have different sizes as well. The kube scheduler looks at each pod and finds the best fit node for the pod.

There are two phases to this -

The first is the scheduler will filter out the nodes that do not fit the profile for the pod - it may be marked to not go on a specific node or it may not have the resources to support the resources the pod requires.

The second is it creates a priority function to assign a score to the nodes on a scale of 1-10 and schedules the pod on the most suited one.

These values can be customised, and you can write your own scheduler as well.

Some determinants for this are resource requirements/requests and limits, taints and tolerations, node selectors, affinity rules, etc.

To install the kube scheduler, you can download the kube scheduler binary from the kubernetes release page, extract it and run it as a service. When you run it as a service, you specify the scheduler config file.

To view the kube scheduler, you have the option to find the kube scheduler as a pod in the kube-system namespace if you deployed it with the kubeadm tool - the pod definition file exists in the /etc/kubernetes/manifests file, or you can do a process search using ps -aux | grep kube-scheduler

That's all I have for today!

-Catt

day3: kube controller manager

Catt — Wed, 10 Dec 2025 01:34:19 +0000

The Kube Controller Manager manages the various controllers in Kubernetes.

Controllers are:
1 - continually on the lookout for the status of things
2 - take necessary actions to remediate the situation

A controller is a process that continually monitors the state of various components within the system, and it works towards bringing the whole system to the desired functioning state.

For example, with a node controller, it monitors the status of the nodes and takes necessary actions to keep the apps running. It does this through the Kube API server. It checks the nodes every 5 seconds - if a heartbeat is not detected, it waits for 40 seconds before marking it as unreachable. Then it gives it 5 minutes to come back up - if it doesn't, the pods get evicted and provisioned onto healthy nodes if they're part of a replicaset

Another example with a replica controller - these monitor the status of replicasets, ensuring the desired number of pods are available at all times within the set.

The controllers are packaged in a single process known as the Kubernetes Controller Manager. When the Kubernetes Controller Manager is installed, the different controllers get installed as well.

To install the Kubernetes Controller Manager, you can download it from the Kubernetes release page, extract it and run it as a service.

There are additional options to customise your controllers, such as default settings for the node controller to evict your pods, for example.

If set up with kube admin tool, kubeadm deploys a kube controller manager as a pod in the kube-system namespace on the master node's /etc/kubernetes/manifests folder.

Without the kube admin tool, you have to inspect options by viewing the Kube Controller Manager service, located in the services directory. You can also list the processes on the master node with ps -aux | grep kube-controller-manager

That's what I've got for today!

-Catt

day2: kube-api server

Catt — Sat, 06 Dec 2025 03:31:22 +0000

day 2 of my CKA study course - this one was a bit long and it is Friday - but yeah I happen to be free today so why not :) had I plans I would have skipped a writeup today but it's 10pm and my house is in good order and I just happen to have nothing planned. Tomorrow is a different story I've got plans from 8am on basically, should be fun and a good break, though if I've got time in the middle of the day I'll work more on the course.

kube-api server does a lot! It's the primary management component in kubernetes. The kubectl command line utility is always reaching out to the kube-api server - it authenticates and validates the request, then retrieves the data from the etcd cluster and responds with the requested information.

That pretty much sounds like a typical API request, and it is, as you can also send POST requests directly without the CLI.

The course goes into creating a pod as an example to illustrate how the kube-api server is core to all the functions and behind the scenes with kubernetes, so let's look at that example -

The request is authenticated and validated
The API server creates a pod object without assigning it to a node
The API server updates the etcd server with information, and updates the user that the pod is created
The scheduler continually monitors the api server, then realises a new pod is now created with no node assigned - it will then kick in to find the right node on which to schedule the pod, and then it will communicate this information back to the API server
The API server then updates the information in the etcd cluster, and passes that information to the kubelet on the worker node
The Kubelet then creates the pod on that node, and instructs the container runtime engine to deploy the application image. Once that takes place, the Kubelet updates the status back to the API server, and the API server then updates the etcd cluster.

Wow that's quite a bit of work to get a pod created and scheduled on a node! Might I mention that a similar pattern is followed every single time a change is requested - the kube-api server is at the centre of all these different tasks that need to be performed to make a change in the cluster. The kube-api server is the only component that interacts directly with the etcd data store - the other components such as the scheduler, kube control manager, and the kubelet, use the API server to make updates in the cluster in their respective areas.

To reiterate some of this again, the kube-api server is responsible for:

Authenticating users
Validating requests
Retrieving data (and updates)
Updating etcd
The Scheduler
The Kubelet

The kube-api server is available as a binary in the kubernetes release page - you can download and configure it to run as a service on your kubernetes master/control plane node.

Kubernetes architecture consists of a lot of different components working with each other, talking to each other in so many different ways, so they all need to know where the other components are. Additionally, there are different modes of authentication, authorisation, encryption/security, etc. - many options exist with this. The kube-apiserver.service file has these options and configurations, a lot of the config being certificates that are used to secure connectivity between different components (all the components have certificates associated with them).

Depending again on how you set up the cluster, viewing the kube-api server options will differ.

If it was set up with the kube admin tool (kubeadm), kube admin deploys the kube-apiserver as a pod in the kube-system namespace (kubectl get pods -n kube-system) on the master/control plane node - (/etc/systemd/system/kubeapi-server.service).

If it was set up without kubeadm, you can inspect the options with a kubeapiserver.service or do ps -aux | grep kube-apiserver to see running processes and effective options by listing the processes.

An additional piece to the notes above - this is coming from The Kubernetes Book by Nigel Poulton, 2024 Edition, The kube-api server is the front-end of Kubernetes - even the internal control plane services communicate to each other via the kube-api server. It is a RESTful API over HTTPS, so all the requests are subject to authentication and authorisation.

That's in the intro, which is where I'm at right now in the CKA course as well - it looks like there is also a whole chapter on the API in general that includes JSON serialisation, named API groups, inspecting the API, alpha and beta and stable, resource deprecation, and extending the API. Flipping through the headers, it doesn't seem as bad as I thought - I did see something about extending the API in a Kelsey Hightower Kubernetes book that is about a decade old by now, which I don't know about, but it's otherwise seemingly a pretty standard API, which I know pretty well working with APIs to test things and with the web development work from before.

That's all I have today - it's getting late actually. Hopefully this is helpful and anyone else interested in studying together or if this helped, leave a comment! Trying to make Kubernetes interesting but it's just a lot of work really ;)

- Catt

day1: Intro to etcd

Catt — Fri, 05 Dec 2025 01:55:02 +0000

day 1 of the kubernetes CKA study journey - the first lesson in the KodeKloud video is on etcd - so today we're chatting about et-see-dee!

etcd is basically a highly available, distributed, reliable key-value database that is simple, secure, and fast. This is important because etcd stores all the cluster information and whenever you use kubectl get <object>, the API is querying the etcd database. It stores information regarding the cluster including nodes, pods, configurations, secrets, accounts, roles, role bindings, etc.

There are many types of databases and etcd is a key value one for the purpose of being very quick to search and retrieve information (high performance), although this also means it doesn't handle really complex queries like a SQL database might. You can, however, store complex data - you can have the key, then the value can be a set of properties, or an entire json itself.

When an etcd server is started, it starts a service on the IP address of the server that listens by default on port 2379. You can then attach clients to the etcd server to store and retrieve information. The default client is the etcdctl - the CLI client for etcd. It runs commands such as ./etcdctl put key1 value1. Note that different etcd versions have different APIs, and thus different etcdctl commands/verbs!

Every change made in a Kubernetes cluster is considered complete only when the etcd server is updated. Kubernetes stores data in a specific directory structure - root directory is a registry, and under that are the various kubernetes objects.

If you are setting up your cluster from scratch, you will have to download the etcd binary and deploy it on your master/control plane node yourself. If you are setting up your cluster with the kubeadm tool, it will deploy the etcd server as a pod in the kube-system namespace.

In a high availability environment, you may have multiple master/control plane nodes with multiple etcd servers, so you will have to ensure they know about each other by specifying this in the --initial-cluster controller parameter in the etcd.service configuration.

etcd entered the CNCF incubation as a project in 2018, and graduated November 2020.

That's all I have for today, hopefully this is solid information about etcd!

- Catt

day0: The beginning of a journey with Kubernetes - cluster architecture

Catt — Thu, 04 Dec 2025 00:48:28 +0000

I'm starting my Kubernetes journey and wanted to document and blog about what I'm learning, to help myself get more acquainted with the content while I learn. I'm currently studying with Kodekloud's CKA course so I will be documenting my notes from there.

I don't have any clear idea of how I'll go about it - my main goal is to try to explain what I've learnt to help myself better understand and retain the information in the process of recapping what I've studied.

First day of this, I have notes from the first video on the core concepts in Kubernetes.

The video goes over an analogy of a ship operation, carrying cargo containers, to illustrate cluster architecture. The main idea is that there is a master/control plane node managing the cluster, while there are a number of worker nodes carrying the containers.

Here are some of the notes I have on this analogy, relating the different components like the controllers, etcd, the scheduler, the kube API server, and the kubelet, to the cargo ship operations analogy.

Master/control plane node doing all the managing of the cluster using control plane components
- containers stored on the ship, which ship, what time it was loaded, etc - all stored in a highly available key-value store called the etcd cluster
- cranes identifying containers that need to be on the ships - size, capacity, number of containers already on the ship - the schedulers
- operations team, cargo team, communications, etc - controllers take care of different areas - manage node lifecycle, container replication, system stability. Node controlled, replication controller, controller manager
- Kube API server - central hub for cluster communication and management, primary management component of k8s,
  - Kube API server is responsible for orchestrating all operations within the cluster
    - exposes the k8s API, which is used by external users to perform management operations on the cluster and controllers to monitor the state of the cluster and make necessary changes as required and by worker nodes to communicate with the server
Cargo ships -
- every ship has a captain that manages all the activity, liaising with master ship - this is the Kubelet, an agent that runs on each node in a cluster
  - listens for instructions from the kube API server and deploys or destroys containers on the nodes as required.
  - Kube API server periodically fetches status reports from the kubelet to monitor the status of nodes and containers on them

This is a really great way to get an overview of the main components in a kubernetes cluster, however I think I have a better idea of this after having already studied a couple things about kubernetes already - otherwise they can seem pretty abstract. So the more I go into the course and study more of the components individually, I'm sure these will all come together and become more and more familiar!

If you're also studying Kubernetes reach out to see if we'd have a good accountability buddy system!

- Catt