赛博赶羊战术：不改 YAML 强制定向调度 Pod

在赛博堡垒的日常巡检中，我们偶尔会萌生一些“非分之想”：我想把正在运行的 Headlamp 面板，强行从 01 节点挪到 03 节点上去。

按照正规军的做法，我们应该去修改 Deployment 的 YAML 文件，加上 nodeSelector 或节点亲和性。但如果这仅仅是一次临时测试，为了这么点小事去改核心图纸，未免太兴师动众。如果给 01 和 02 节点打 NoSchedule 污点，又会像“核弹打蚊子”一样误伤集群里的其他无辜业务。

今天，包工头教你一招极客圈里经典的“障眼法”——利用节点封锁 (Cordon) 机制的“赛博赶羊战术”。

---

🐑 战术核心：关上多余的门，只留一条路

Kubernetes 提供了一个专门用于节点临时维护的命令：kubectl cordon（封锁）。 当节点被 Cordon 后，它会被打上 SchedulingDisabled 的标记。这就像给节点挂上了“暂停营业”的牌子：已经在里面吃饭的顾客（运行中的 Pod）不受影响，但绝对不接待新客（新创建的 Pod 无法调度进来）。

我们的战术逻辑极其简单：把不想去的节点全封锁，然后把 Pod 杀掉让它重生。K8s 大脑环顾四周发现只有一台节点“开着门”，就只能乖乖把 Pod 丢进去。

---

🛠️ 实机演练：四步微操指南

假设我们要把 kube-system 命名空间下的 Headlamp 强行赶到 k3s-master-03 节点。

第一步：封锁非目标节点 (关门)

我们要逼迫目标去 03，所以先把 01 和 02 的大门焊死：

kubectl cordon k3s-master-01 k3s-master-02

验证：此时敲击 kubectl get nodes，你会看到 01 和 02 的 STATUS 变成了 Ready,SchedulingDisabled。

第二步：击杀当前 Pod (放狗咬羊)

直接删掉当前正在运行的 Headlamp Pod。由于它是由 Deployment 管理的，K8s 会瞬间拉起一个新的替代品。

kubectl delete pod -l app.kubernetes.io/name=headlamp -n kube-system

第三步：查收战果

去看看新重生的 Headlamp 落在哪了：

kubectl get pods -n kube-system -o wide | grep headlamp

因为大脑别无选择，你会发现新的 Pod 已经精准无误地降落在了 k3s-master-03 上！微操成功！

第四步：光速解除封锁 (极其重要！)

羊已经进圈了，赶紧把 01 和 02 的大门重新打开，否则你后续部署的任何新业务都会因为找不到节点而卡在 Pending 状态。

kubectl uncordon k3s-master-01 k3s-master-02

验证：再次 kubectl get nodes，SchedulingDisabled 标记消失，集群恢复常态。

---

⚠️ 架构师的灵魂拷问

虽然这套连招玩起来行云流水，极其酷炫，但我必须提醒你：它终究是一张“体验卡”。

Kubernetes 的核心信仰是声明式架构(Declarative)。Cordon 大法只是一次性欺骗了调度器。如果明天 03 节点重启了，或者 Headlamp 意外崩溃了，K8s 大脑在重新调度时，面对三扇全开的大门，依然会随机把 Headlamp 扔回 01 或 02。系统并没有记住你的真实意图。

总结：

• 临时测试、排查干扰：用 Cordon 大法，干净利落。
• 永久固化、生产要求：请务必遵守纪律，老老实实去写 nodeSelector 或 nodeAffinity。这才是让 Tech Fortress 坚不可摧的终极规范。