Skip to content

feat(cocoonset): explicit not-ready/unreachable tolerations on managed pods#19

Closed
tonicmuroq wants to merge 1 commit into
mainfrom
feat/eviction-toleration
Closed

feat(cocoonset): explicit not-ready/unreachable tolerations on managed pods#19
tonicmuroq wants to merge 1 commit into
mainfrom
feat/eviction-toleration

Conversation

@tonicmuroq

Copy link
Copy Markdown
Contributor

Why

Managed pods only tolerate the cocoon taint, so the DefaultTolerationSeconds admission plugin injects the default 300s node.kubernetes.io/not-ready / node.kubernetes.io/unreachable NoExecute tolerations. Any window where a cocoon node stays NotReady longer than ~6 minutes (node-monitor grace + 300s) — a control-plane partition, a long vk-cocoon maintenance stop, an upgrade gone slow — ends with taint eviction deleting the pods for real, and vk-cocoon then faithfully removing the backing VMs once it syncs.

For stateful, host-pinned VMs eviction is never a valid recovery mechanism:

  • a recreated pod clones a fresh VM from the base image under the old VMName — snapshots are only consulted by the explicit hibernate/restore flow, never by a plain recreate;
  • so the automatic path can only produce garbage data under a stale identity, for snapshotted and non-snapshotted VMs alike.

The correct semantic is: pods on a dead/unreachable node wait in place; recovery is an explicit per-VM decision (restore from snapshot / declare loss).

What

  • newManagedPod stamps explicit Exists/NoExecute tolerations for node.kubernetes.io/not-ready and node.kubernetes.io/unreachable (admission only injects its 300s defaults when the pod has none).
  • New EVICTION_TOLERATION_SECONDS env on the operator: 0 or unset (default) = tolerate forever; >0 bounds the toleration for pools where eviction is acceptable; invalid values fail fast at startup.
  • config/manager/deployment.yaml documents the knob.
  • Tests pin both the forever default and the bounded variant.

Notes

  • Existing pods are untouched: podSpecMatchesAgent ignores tolerations, so no recreate churn on rollout. Tolerations are append-only mutable on running pods; the live fleet can be patched separately.
  • go build ./... && go vet ./... && go test ./... green.

…d pods

Managed pods only tolerated the cocoon taint, so DefaultTolerationSeconds
admission injected 300s not-ready/unreachable NoExecute tolerations. Any
control-plane window longer than ~6min (node NotReady grace + 300s) let
taint eviction delete the pods for real, and vk-cocoon then faithfully
removed the backing VMs. For stateful pinned VMs eviction is never a valid
recovery: a recreated pod clones a fresh VM from the base image under the
old VMName (snapshots are only consulted by the explicit restore flow), so
the automatic path can only ever produce garbage data under a stale identity.

- pods.go: newManagedPod stamps explicit Exists/NoExecute tolerations for
  node.kubernetes.io/not-ready and node.kubernetes.io/unreachable, so the
  admission default no longer applies
- EVICTION_TOLERATION_SECONDS env: 0 or unset (default) tolerates forever;
  >0 bounds the toleration for pools where eviction is acceptable; invalid
  values fail fast at startup
- deployment.yaml: document the knob with its default
- pods_test.go: pin the forever default and the bounded variant

Existing pods keep their current tolerations (drift detection ignores the
field, so no recreate churn); tolerations are append-only mutable and can
be patched onto the running fleet separately.
@tonicmuroq

Copy link
Copy Markdown
Contributor Author

close as 748e3f3 did a stricter implementation

@tonicmuroq tonicmuroq closed this Jul 19, 2026
@tonicmuroq
tonicmuroq deleted the feat/eviction-toleration branch July 19, 2026 03:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant