| ▲ | Kubereboot/Kured: Kubernetes Reboot Daemon(github.com) | |||||||||||||||||||
| 15 points by ankitg12 6 hours ago | 7 comments | ||||||||||||||||||||
| ▲ | edude03 5 hours ago | parent | next [-] | |||||||||||||||||||
Insert the "No god no" meme here - you really shouldn't be updating nodes in place and thus shouldn't be restarting nodes. I'm aware bare metal exists and it's not always practical to just provision more servers, yet I think for most workloads you're not getting the benefit of Kubernetes if you have say 3 servers and lose 1/3 of your capacity to do software updates. | ||||||||||||||||||||
| ||||||||||||||||||||
| ▲ | adamtulinius 3 hours ago | parent | prev | next [-] | |||||||||||||||||||
Almost 3000 lines of code for automating draining nodes and rebooting it. And it requires that another component has already queued up an update that requires a reboot. Looking at the issues, people try to shoehorn a thousand unique behaviours into a general purpose tool, just to avoid a bit of old school sysadmin-ing. There's a guy wanting to change TZ of the running cluster, and want "Kured" to support that use case so it's only updated during night - in an ever changing TZ. | ||||||||||||||||||||
| ▲ | captn3m0 an hour ago | parent | prev | next [-] | |||||||||||||||||||
What’s the usecase where you are okay cordoning a node but not okay with just terminating it and starting a new one? Physical nodes where you have to reclaim them and don’t run any virtualisation ? | ||||||||||||||||||||
| ▲ | AntiUSAbah 4 hours ago | parent | prev [-] | |||||||||||||||||||
I like it. K8s should be more opiniated about this. Whats also missing is rebalancing of pods. Rescheduler | ||||||||||||||||||||