今天凉风徐徐得阴天，这是一个钓鱼得好天气，但是我没有出去拍钓鱼视频。我正做在电脑前开始敲这篇文章，在想做自媒体得初衷，是否有正反馈，是否达到自己预期，是否适合自媒体，是否能坚持下去。

在没有做自媒体之前，以为自媒体门槛低比较容易做，但是尝试做了以后，做的确是很容易，做出高质量很难，做出有流量视频更难。

今天在v2ex上看到一个讨论副业的帖子，结合自己现在的境况，来聊聊自己的主业和副业。

我的主业已经消失，他们聊的副业都有可能是我的主业。这几年唯一能算副业可能是被动收入部分，这几年行情不好都是负收入😒，都没有动躺在那里。之前都把精力都放在提升主业收入的事情上，按照以前经验将时间投入主业性价比较高，现在看来这个做法不是很正确，时代变了。

程序员有两个极端的想法。第一种，万般皆下品唯有技术高，我要是不当程序员了，做其他直接秒杀降维打击。第二种，不当程序员，干什么都不行。

决定独立生存之后，我首先开始了视频自媒体的探索之路。首先就是选择题材，由于最近一直在钓鱼，同时一直在B站看了钓鱼up主视频，于是决定先尝试钓鱼题材。通过视频想表达一直悠然自得享受生活，身处快节奏的大城市人们，被生活赶者走，行尸走肉，没有自己的时间，压力巨大，他们向往自由自在的生活，希望看了视频之后能够身心放松，看到躺平之后的悠然自得生活态度。当然这要求我本来就是悠然自得心态，才能拍出这个感觉。

三月份被裁之后，找工作不是很顺利。这让我有时间停下来思考接下来的路该怎么走，之前工作时候想法是先扩大自己的技术影响力，觉得自己技术也不错还能靠技术生存，同时在工作时候思考如何独立生存。经过这几个月从刷题、背八股文到投简历面试，证明无法继续靠打工来生存了，需要考虑其他路。

很早之前我以前的同事告诉我要学会独立生存，直到2020年末才真正开始考虑如何独立生存。第一步行动就是写博客，宣传自己。而现在开始下一步，实践摸索。

由于调度器和descheduler是两个独立工作的组件，两个组件之间并没有任何通讯和协商机制，在descheduler执行pod驱逐后，由驱逐生成pod的调度和非驱逐原因生成的pod的调度（后面简称正常的pod）会存在资源抢占的问题。比如正常的pod和驱逐后生成的新pod需要相同的资源，且集群的剩余可以调度的资源紧张（或者资源碎片），且正常的pod在驱逐后生成的新pod之前调度，会出现pod驱逐后新生成的pod重新调度到原先的节点或无法调度的问题。

MigrationController插件通过Reservation资源跟koordinator scheduler进行通信，让koordinator scheduler进行资源预留，然后再执行驱逐pod，来解决上面这个问题。

仲裁机制是一种干预pod的驱逐过程的机制，它在 v1.4.0 版本中引入。它解决了应用变更维护过程中临时暂停应用pod的驱逐，比如deployment滚动更新的过程中同时descheduler执行pod的驱逐，会对这个应用的稳定性产生影响，甚至没有一个ready的pod。仲裁机制提供了一个方式，在驱逐pod时候增加一道审批的流程，能够进行批准、拒绝等操作。

最近我在买新的生产力工具，我想全方位评测一下新机器，但是windows 11初次开机后强制要求联网，联网会自动激活windows。虽然使用oobe方法（按Shift+F10或FN+Shfit+F10 快捷键，在弹出命令行输入oobe\bypassnro，然后回车，自动重启，重启后，在联网界面会有“我没有Internet连接”选项点击此选项即可跳过联网）可以跳过联网步骤，但是进入系统后依然不能联网，这样就不能愉快的体验新的机器。

在网上没有搜到任何能够联网不激活的有效方法。于是我想自己研究一下，看能不能解决这个问题。

问题总结为”如何在联网情况下，不自动激活windows”，这样就能享受七天无理由退货。

国内的电商平台都有七天无理由退货的服务，但是笔记本里windows激活后和厂家自带软件激活（即已激活/更改/卸载的机器）且没有质量问题是不支持七天无理由退货。如果不联网的情况下，验机就非常的麻烦，需要使用移动设备或者没有互联网的无线传输文件。

在 深度解析descheduler的highNodeUtilization和lowNodeUtilization插件的原理 中研究了kubernetes社区里的descheduler的两个Node utilization插件，而这两个插件用都存在使用request来计算节点的资源使用情况，无法解决节点过热（小部分节点的资源使用高于其他大部分节点）问题。而这篇文章介绍koordinator descheduler的LowNodeLoad插件就是解决这个问题的，它基于节点实际的资源使用值来区分高水位节点、正常节点和低水位节点。

koordinator descheduler兼容社区的descheduler，同时增加了两个插件MigrationController和LowNodeLoad（在Koordinator v1.1中增加的）。

koordinator的LowNodeLoad插件类似lowNodeUtilization插件，都是将高水位节点的pod驱逐到低水位节点上。跟lowNodeUtilization不同的是，它是基于节点的真实负载对节点进行分类，它能够真正解决节点资源过热问题。

MigrationController插件提供资源保留和仲裁机制（拦截机制），通过这两个能力保障descheduler驱逐pod时候的应用稳定性。

这篇文章只介绍LowNodeLoad插件，MigrationController插件后面文章会介绍，本文基于Koordinator v1.4版本和Descheduler v0.28.1。