Skip to content

7. CR status never written / CR status stale#

Symptom. VerifyEtcdState or ResetControllers fails with verdict CR status never written (VerdictCRStatusNeverWritten) or CR status stale (VerdictCRStatusStale). Both are hard fails on an add pre-check, a remove pre-check, and inside ResetControllers.

What it means. Both say the same thing: the EtcdMember CR cannot be trusted to describe this member, so MKE refuses to make a membership decision from it.

  • CR status never written — the CR exists but carries no conditions[type=Joined] at all. k0s writes that condition immediately after creating the object; its absence means the create landed and the status update did not.
  • CR status stale — etcd counts the member, the CR says Joined=False, and spec.leave is false. Nobody asked it to leave and it has not left, so the status contradicts etcd.

Neither is dangerous on its own — the member is still voting normally. What is missing is the bookkeeping the removal path drives through.

Diagnose.

kubectl get etcdmember <node-name> -o yaml    # status.conditions, status.memberID, spec.leave
sudo k0s status                               # on the affected host
sudo journalctl -u k0scontroller --since -30m # look for apiserver write failures

Repair. Both recover the same way, and only this way: restart k0s on the affected host.

sudo systemctl restart k0scontroller   # on the AFFECTED host, not the helper

On start, k0s re-resolves its own member ID from its local etcd and rewrites the CR — setting status.peerAddress, status.memberID and Joined=True. Confirm before re-running:

kubectl get etcdmember <node-name> \
  -o jsonpath='joined={.status.conditions[?(@.type=="Joined")].status} memberID={.status.memberID}{"\n"}'

Then re-run the original mkectl node add / mkectl node remove.

If the restart does not fix it, the host's k0s cannot reach the kube-apiserver, or cannot resolve its member ID from its local etcd. That is case §2 — resolve that first. Do not delete the CR to force a clean recreate while the member is still in the raw list: see the warning at the end of §4.