Today, a gentle breeze is blowing on this cloudy day—perfect weather for fishing. However, I didn’t go out to shoot a fishing video. Instead, I’m sitting in front of the computer, starting to type this article, reflecting on my original intent for doing content creation. I’m questioning whether I’m receiving positive feedback, whether I’ve met my expectations, whether I’m suited for content creation, and whether I can stick with it.

Before venturing into content creation, I thought it had a low barrier to entry and would be relatively easy. But after trying it out, while creating content is indeed easy, producing high-quality content is difficult, and creating videos that generate traffic is even harder.

Today, I saw a post discussing side jobs on V2EX, and considering my current situation, I want to talk about my main job and side gigs.

My main job is gone, and the side gigs they’re discussing could potentially be my main job. The only thing that could count as a side gig in recent years might be passive income, but with the poor market conditions, it’s been more like negative income 😒, just sitting there doing nothing. I used to focus all my energy on increasing my main job’s income because, based on past experience, investing time in my main job had the best return. But now, it seems that this approach wasn’t very wise—the times have changed.

There are two extreme views among programmers. The first is, “All other paths are inferior; only technical skills reign supreme. If I stop being a programmer, I can crush anything else with ease.” The second is, “If I’m not a programmer, I’m good for nothing.”

After deciding to live independently, I first began exploring the path of video content creation. The first step was choosing a theme. Since I’ve been fishing a lot lately and watching fishing videos on Bilibili, I decided to try out the fishing genre. Through my videos, I want to convey a sense of leisurely enjoyment of life. People in fast-paced big cities are often rushed by life, like zombies, without their own time, and under immense pressure. They long for a free and relaxed life. I hope that after watching my videos, they can feel mentally and physically relaxed, and see the attitude of enjoying life by taking it easy. Of course, this requires me to already have a relaxed mindset to capture that feeling in my videos.

After being laid off in March, job hunting hasn’t been very smooth. This gave me time to stop and think about the way forward. When I was working before, my idea was to first expand my technical influence, thinking that my skills were good enough to survive on, while also thinking about how to be independent during work. After months of doing coding exercises, memorizing technical theories, and sending out resumes, I’ve realized that continuing to survive by working for others isn’t feasible. I need to consider other paths.

A long time ago, a former colleague of mine told me to learn to be independent. It wasn’t until the end of 2020 that I truly began to think about how to live independently. My first step was to write blogs to promote myself. Now, I’m starting the next step: practice and exploration.

Since the scheduler and descheduler are two independently operating components, there is no communication or negotiation mechanism between them. After the descheduler evicts a pod, there can be a resource contention issue between the scheduling of pods generated by the eviction and the scheduling of normal pods (those generated for non-eviction reasons). For instance, if both a normal pod and a newly generated pod after eviction require the same resources, and the cluster’s remaining schedulable resources are tight (or fragmented), the normal pod may get scheduled before the new pod, causing the newly generated pod to be rescheduled to its original node or even fail to be scheduled.

The MigrationController plugin addresses this issue by communicating with the koordinator scheduler through the Reservation resource, allowing the koordinator scheduler to reserve resources before evicting the pod.

The arbitration mechanism, introduced in version 1.4.0, is a mechanism that intervenes in the pod eviction process. It temporarily pauses the eviction of application pods during application maintenance, such as during a deployment’s rolling update when the descheduler also evicts pods, which can affect the application’s stability and potentially leave no ready pods. The arbitration mechanism provides a way to add an approval process during pod eviction, enabling actions such as approval or rejection.

Recently I bought a new productivity tool, and I wanted to thoroughly evaluate the new machine. However, after the first boot of Windows 11, it requires mandatory internet connection for activation. Even though using the OOBE method (press Shift+F10 or FN+Shift+F10 shortcut keys, enter oobe\bypassnro in the command prompt that appears, then press Enter, the system will automatically restart, and after the restart, there will be an option “I don’t have an Internet connection” on the network connection interface, click on this option to skip the network connection), it can skip the network connection step, but still cannot connect to the internet after entering the system, which prevents me from enjoying the new machine.

I couldn’t find any effective methods online to connect to the internet without activating Windows. So, I decided to do some research on my own to see if I could solve this problem.

The article A Deep Dive into HighNodeUtilization and LowNodeUtilization Plugins with Descheduler discusses two Node utilization plugins of the descheduler in the Kubernetes community. Both of these plugins use requests to calculate the resource usage of nodes, which cannot address the problem of node overheating (where a small number of nodes have higher resource usage than the majority of other nodes). However, this article introduces the LowNodeLoad plugin of koordinator descheduler, which solves this problem. It distinguishes between high-watermark nodes, normal nodes, and low-watermark nodes based on the actual resource usage of nodes.

The koordinator descheduler is compatible with the community descheduler while adding two plugins, MigrationController and LowNodeLoad (added in Koordinator v1.1).

The LowNodeLoad plugin of koordinator is similar to the lowNodeUtilization plugin in that it evicts pods from high-watermark nodes to low-watermark nodes. However, unlike lowNodeUtilization, it classifies nodes based on their actual load, effectively addressing the issue of node resource overheating.

The MigrationController plugin provides resource reservation and arbitration mechanisms (interception mechanisms) to ensure application stability when pods are evicted by descheduler.

This article only introduces the LowNodeLoad plugin, while the MigrationController plugin will be discussed in subsequent articles. This article is based on Koordinator v1.4 and Descheduler v0.28.1.