Quickstart
Install NodeWright and run a hello-world package on a single node. Should take about five minutes.
This is the fast path. Installation covers private registries, image pull secrets, and uninstall in full.
Prerequisites
- A Kubernetes cluster you can
kubectlinto (v1.30+) - Helm 3.8+ (needed for native OCI support)
- A node you are willing to have NodeWright touch
- A clone of this repository, for the example manifest in step 3:
1. Install the operator
Pulling from a private registry? Create the image pull secret first, then add
--set imagePullSecret=node-init-secret to the command below — otherwise the
operator pod cannot pull and the wait in the next step times out. See
Installation.
This installs the latest chart, which is what you want here: the examples you
just cloned track the main branch, so both come from the same place. For a real
deployment, pin --version — see
Installation.
Wait for it to come up:
2. Pick one node
The example targets nodes carrying a label that nothing has yet, so applying it does nothing until you opt a node in. Pick one and label it:
Why this way. A NodeWright with an empty
nodeSelectorsmatches every node in the cluster. Starting from a label you apply by hand keeps the blast radius at exactly one node while you are finding your feet.
3. Apply the hello world
That is examples/simple/scr.yaml:
4. Watch it run
You are waiting for status to reach complete. While it works, the operator
creates a Job on your node for each stage:
To see the script’s output, read the log of the container named for the stage:
You should see Hello, config!. Finished Jobs are garbage-collected after a
while, so look reasonably promptly — or use
kubectl nodewright package logs, which retrieves them
for you.
The record of what ran lives on the node, not on the CR:
What just happened
The custom resource
Four parts of that manifest did all the work. Every field is covered in The NodeWright Custom Resource.
Two knobs you did not set are worth knowing before you go near a real cluster:
interruptionBudget defaults to 100% — every matching node at once — and
interrupt is what makes a package cordon and drain a node before it runs.
The lifecycle
The package moved through the install lane: apply, then config. Because
it declared no interrupt, it stopped there and the node was never cordoned or
drained. Lifecycle of a NodeWright has the whole
picture.
The part worth internalising is what your two configMap keys were:
Every work step has a paired check step, and the stage is not done until the
check passes. That is not a naming convention — the operator runs them as
consecutive init containers in the same pod, so Kubernetes itself stops at the
first one that fails. interrupt is the sole exception, having no check step.
Clean up
Deleting the CR does not undo what a package did to the host. This one only echoed text, so there is nothing to undo — but for real packages that is the distinction between removing a NodeWright and uninstalling its packages.
To remove the operator entirely:
Next steps
- Overview — what NodeWright is for and when to reach for it
- The NodeWright Custom Resource — every field
- Lifecycle of a NodeWright — how a rollout actually runs
- Interrupt Flow — cordon, drain, reboot
- Deployment Policy — shaping a rollout across many nodes
examples/— including an interrupt example with real workloads