If something goes wrong¶

Ordered by how often they occur.

My node is not in the list when I try to assign it¶

Three causes, in order of likelihood:

Wrong project. The project dropdown is top-left. It must say SA-Craig-Smith. Everything in Palette is project-scoped, and a node in another project simply does not exist as far as this screen is concerned.
Profile cloud type is not Edge Native. Only Edge Native profiles can consume a registered edge host. This cannot be changed after the profile is created — you would need to rebuild it.
Node already claimed. Check Clusters → Edge Hosts. If the Cluster column has a value, it belongs to that cluster already.
You picked the wrong host. Three hosts in this project are unclaimed, but only edge-06396f804bc511eb80001ceec94be53d is healthy and yours. The March-dated edge-3931... is unhealthy and dumnmy is unpaired — neither will build.

The cluster sits in Provisioning forever and never errors¶

Symptom. Palette shows Provisioning indefinitely — no error, node Healthy, agent running.

Cause. The networking: block in the PXK-E layer landed in the wrong place in the YAML, usually nested under etcd: instead of alongside it. That is still valid YAML, so nothing turns red — but Kubernetes never sees your pod and service ranges, never assigns the node a pod range, and Cilium waits forever for one that is never coming.

Confirm it. Ask whoever has access to the node to run:

kubectl get node -o jsonpath='{.items[0].spec.podCIDR}{"\n"}'
# empty -> no pod range was ever assigned. This is the one.

grep service-cluster-ip-range /etc/kubernetes/manifests/kube-apiserver.yaml
# shows 10.96.0.0/12 instead of your serviceCIDR -> the networking block was ignored

Fix. In the profile's PXK-E layer, move networking: so it starts in the same column as etcd: and scheduler: — see Edit 2. Save a new profile version and redeploy. The pod network is set when the cluster is built and cannot be changed afterwards.

Do not change the Cilium IPAM mode to work around this

Leaving it on kubernetes is correct — Kubernetes assigns the range and Cilium reads it. Switching to Cluster pool papers over the real problem and diverges from every other deployment we run.

The cluster sat in Provisioning and then failed¶

Check the deployment tried to reuse the existing OS rather than install a new one:

Profiles → dane-agent-basic → BYOS Edge OS layer → presets. It must say Agent Mode.

If it does not, that is the cause. The profile tried to lay a fresh operating system onto a machine that already had one. Fix the preset, save a new version of the profile, and redeploy.

Everything says Healthy but nothing can talk to anything¶

The symptom of the missed Cilium edit. Kubernetes is handing out addresses from one range and Cilium from another.

Check Profiles → dane-agent-basic → Cilium layer:

    clusterPoolIPv4PodCIDRList: ["{{.spectro.var.podCIDR}}"]

If it still reads ["10.0.0.0/8"], that is it. This one cannot be fixed in place on a running cluster — the pod network is set at build time. Fix the profile and redeploy the cluster.

A pod is stuck Pending forever¶

Usually the Cilium For 1-node cluster preset was not selected, so Cilium asked for two copies of a component and the second has no machine to run on.

Profiles → dane-agent-basic → Cilium layer → presets → select For 1-node cluster, save, and redeploy.

The cluster failed and the error mentions an invalid CIDR or a bad IP¶

A variable reference does not match a declared variable, so Palette passed the literal text {{.spectro.var.podCIDR}} through to Kubernetes.

Check the spelling and capitalisation in all three places against the Profile Variables panel. podCIDR is not the same as podcidr or podCidr.

Errors scrolling past during deployment¶

Normal for the first 10–15 minutes. Components start in a dependency order and retry until the thing they depend on exists. Messages about the kubelet not being ready, a missing kubeconfig, or localhost:8080 being unreachable are all expected early on.

Worry when the cluster makes no forward progress for 20+ minutes — the status has not changed and the event feed has stopped producing new messages. Errors that keep changing are progress.

Node health flipped to Unhealthy¶

Palette has lost contact with the agent. Almost always the machine is powered off, has lost its network path, or the agent service has stopped. Not fixable from the Palette UI — flag it.

When to ask rather than retry¶

Ask Craig if:

The node shows Unhealthy and you cannot reach the machine
The cluster has failed twice with the same error
The Edge Hosts tab is empty entirely
Anything asks you to delete something you did not create