Change:
What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubelet RBAC Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG Kubernetes version (use ): Environment: Cloud provider or hardware configuration: GCE Install tools: make quick-release && go run -up What happened: I upgraded the cluster with After which the master node was not ready. What you expected to happen: I expected the master node to be ready. How to reproduce it (as minimally and precisely as possible): Anything else we need to know: In the api server logs: In the kubelet logs:
cc since you were running into this.
cc
c.f. it seems wrong for the node to delete itself
In the case where a kubelet starts up and sees a mismatch between the externalid field and its own idea of what its external id is, it is trying to delete itself. Questions I have: what can make the external id mismatch occur (in cloudprovider and non-cloudprovider cases)? is it even safe for a kubelet to summarily delete itself (as it is trying to do today), or can that mess up apiserver/controller logic around node cleanup, like the attach/detach controller, etc? can we limit the node to reporting the mismatch by updating node status and stay in the tryRegisterWithApiServer loop, and let something like the node controller remove a node that gets in this situation instead? cc
happens in both GCE and GKE upgrades. who can update node status. I would view this as strictly worse than giving kubelets node delete privileges.
If a node instance is recreated with the same name, it will register as the same node. This apparently also happens in tests (). AFAIK, attach/detach controller annotates the node object to keep states. If the node is backed by a new (VM) instance, it is probably safe/better to recreate the node object and start afresh. Of course, upon any node update/delete/add events, the detach/attach controller should examine and reconcile the status. Hm......AFAIK node controller also does not coordinate with other controllers (e.g., detach/attach). I am not sure how this would help the second point you made.
would you be ok with adding delete permissions for kubelet because it has them and uses them today, and then taking the argument about whether it should be done another way to it's own issue?
yeah, convinced me that if the node is the authority of the spec during self-registration cases, update/delete permissions are reasonable, and we'd need to figure out how to scope those to update/delete self in the future, just like we do for update status
see

Discussion:
rbac.NewRule("create", "get", "list", "watch").Groups(legacyGroup).Resources("nodes").RuleOrDie(), // TODO: restrict to the bound node once supported rbac.NewRule("update", "patch").Groups(legacyGroup).Resources("nodes/status").RuleOrDie(), <ins> rbac.NewRule("update", "patch", "delete").Groups(legacyGroup).Resources("nodes").RuleOrDie(), </ins> // TODO: restrict to the bound node as creator once supported rbac.NewRule("create", "update", "patch").Groups(legacyGroup).Resources("events").RuleOrDie(),

- apiGroups: - "" resources: <ins> - nodes verbs: - delete - patch - update - apiGroups: - "" resources: </ins> - events verbs: - create