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.

In the context of reducing costs and increasing efficiency, the concept of FinOps aligns well with this demand. FinOps is a best practice methodology that combines financial, technical, and business aspects, aiming to optimize the cost, performance, and value of cloud computing resources. The goal of FinOps is to enable organizations to better understand, control, and optimize cloud computing costs through prudent resource management and financial decision-making.

The stages of FinOps are divided into Cost Observation (Inform), Cost Analysis (Recommend), and Cost Optimization (Operate).

Typically, an enterprise’s internal cost platform includes cost observation and cost analysis, analyzing IT costs (cloud provider bills) based on service types and business departments.

Cost Optimization (Operate) is divided into three stages from easy to difficult:

1. Handling idle machines and services, making informed choices on services and resources, including appropriate instance types, pricing models, reserved capacity, and package discounts.
2. Applying service downsizing, reducing redundant resources (changing from triple-active to dual-active, dual-active to cold standby, dual-active to single-active, personnel optimization).
3. Technical optimization (improving utilization).

This article focuses on the technical optimization stage of cost reduction, specifically in the context of cloud-native cost reduction strategies under Kubernetes.

Recently, I encountered an unexpected phenomenon. After scaling down the replicas of a deployment to 0, the evicted pods were not being deleted. Typically, when there are replicas in a deployment, evicted pods are not deleted, which aligns with my expectations. This article discusses topics related to the removal of evicted pods.

In 2023, I overall feel like I’m continuously struggling in adversity, but gradually seeing a glimmer of hope. It’s like climbing uphill with faltering steps, looking up to see the hilltop. I feel that I’ve accumulated some expertise in the cloud-native field, allowing me to gradually share my knowledge and thoughts while enhancing my technical influence.