Support specifying node name to target for the hog scenarios

[chaitanyaenr]

Replicating the issue opened by @elib in Krkn: krkn-chaos/krkn-hub#262

Current hog scenarios use node-selector to pick the nodes to target. Users can benefit from being able to set the node-name(s) in case of targeting particular nodes.

Something along the lines of

duration: 60
workers: '' # leave it empty '' node cpu auto-detection
hog-type: cpu
image: quay.io/krkn-chaos/krkn-hog
namespace: default
cpu-load-percentage: 90
cpu-method: all
node-selector: "node-role.kubernetes.io/worker="
**node-name: "worker-0"**
number-of-nodes: 2
taints: []

[chaitanyaenr]

cc: @NarmalaSk @10sharmashivam @abhinavs1920 @jason810496 @Transcendental-Programmer This is a worthwhile issue to explore if it aligns with your interests.

[abhinavs1920]

Hey everyone, I was exploring around the CPU‐hog code and noticed we only let users pick nodes by selector. What if we add an optional node-name field? The idea is simple: if you set node-name, we schedule the chaos pod directly on that node; otherwise we fall back to the selector, and if neither is set, we keep picking a random node like it exists. It feels like a lightweight change that gives folks more control without breaking existing configs. Let me know what you think! @chaitanyaenr

Thanks!!

[Transcendental-Programmer]

Hey, quick check-in before I start implementing the node-name feature — just want to make sure we're on the same page with a couple things.

First, about handling multiple node names. Say a user passes something like node-name="worker-1,worker-2,worker-3" and also sets number-of-nodes=2. What's the right move there? My gut says if someone gives us explicit node names, we should honor all of them and ignore the number-of-nodes value — because at that point, they're clearly telling us exactly which nodes they want. Picking a random subset or throwing an error feels like overthinking it.

Second, the question of priority — if both node-name and node-selector are set, which one should we use? I'd argue for node-name taking precedence since it's the more specific instruction. That lines up with how Kubernetes tends to handle things — more precise constraints win. It's like saying "book me seat 12A" versus just saying "give me a window seat." The first one's pretty unambiguous.

@chaitanyaenr can you clarify if my reasoning is correct, meanwhile i will come up with an implementation plan.

Cheers,
Priyansh