Change:
<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: /kind bug /sig auth What happened: Testing a daemon-set spec, I deleted/recreated it multiple times. At one of the recreations, the daemon-set was not scheduled anymore, and the number of desired pods went to 0 (on a 3 nodes cluster): The kube-apiserver stderr logs shows: The kube-controller stderr logs shows: The (default) permissions for the cluster role are: Seems to be missing a permission for the resource. I edited manually the cluster-role adding the permission and then the daemonset was scheduled again. What you expected to happen: The cluster role default permissions should allow getting the resource. How to reproduce it (as minimally and precisely as possible): I tried to reproduce it again, but I'm unable to find the exact pattern to reproduce it. Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g. from /etc/os-release):Kernel (e.g. ): Install tools: Others:
Same here (5 node cluster, k8s version 1.9.3, Ubuntu 16.04 LTS, 4.4.0-109-generic). Deamonset we were trying to create/delete is part of official elastic yaml for metricbeat installation. Problem is specific to daemonset part, other parts of manifests behave correctly on deletion/creation. (). On 1st create - all 5 nodes were populated (kubectl create -f metricbeat-). On 1st subsequent delete followed by create we were stuck with desired 0 and error in scheduler log (E0405 14:09:46. 1 ] kube-system/elk-metricbeat failed with : failed to construct revisions of DaemonSet: "elk-metricbeat-" is forbidden: User "system:serviceaccount:kube-system:daemon-set-controller" cannot get in the namespace "kube-system"). However if we changed name of deamonset (metricbeat-v1 for example) it would bring pods on 4 nodes (master missing), setting desired to 4 (instead of 5). Again if deleted, neither that name or any previously used name would work (desired 0), while new name would spawn 4 pods (desired 4 instead 5 master missing). No stucked pods or jobs, all other not-affected deamonsets (wave-net, kube-proxy, weave-scope) all work fine.
why did this not happen in all of the recreations and only once did it fail with RBAC issue ?
maybe this is related: "However if we changed name of deamonset (metricbeat-v1 for example) it would bring pods". New name of deamonset would spaws pods, but any subsequent retry with any of previous names would fail (until we change to new name again). Once we get to we were able to spawn pods with previously given names as well, so it might be related...
DaemonSet controller only calls GET ControllerRevisions when there's ControllerRevision name collision when DaemonSet tries to create a new ControllerRevision. This is only called when the ControllerRevision cache store is stale or due to hash collisions.

Discussion:
rbac.NewRule("list", "watch").Groups(legacyGroup).Resources("nodes").RuleOrDie(), rbac.NewRule("list", "watch", "create", "delete", "patch").Groups(legacyGroup).Resources("pods").RuleOrDie(), rbac.NewRule("create").Groups(legacyGroup).Resources("pods/binding").RuleOrDie(), <del> rbac.NewRule("list", "watch", "create", "delete", "update", "patch").Groups(appsGroup).Resources("controllerrevisions").RuleOrDie(), </del> <ins> rbac.NewRule("get", "list", "watch", "create", "delete", "update", "patch").Groups(appsGroup).Resources("controllerrevisions").RuleOrDie(), </ins> eventsRule(), }, })

verbs: - create - delete <ins> - get </ins> - list - patch - update