Author here! If you're running a Kubernetes cluster, I recommend you check `kubectl version` and see if you're running "Server Version: v1.36.[0,1,2]". If so, you may want to use the one-liner at the end of the article to check your "process_resident_memory_bytes" on each node, and consider restarting kubelet as a temporary workaround to tame the memory leak until v1.36.3 is released.
by CamouflagedKiwi
1 subcomments
Nice find.
Can't help but feel this is one of the subtle traps hidden beneath the advice that contexts aren't supposed to be stored. I know it's not always that easy, of course.
by rirze
0 subcomment
Very cool. It's often daunting to contribute to such a well-established and recognizable project, but this is exactly how it should work.
by lanycrost
0 subcomment
Nice finding, golang and kubernetes toolset is always surprisingly enough and friendly for doing such debuggings. Currently me to running this version so kudos to you!
by fsuts
0 subcomment
Not all heroes wear capes! Well done
by __turbobrew__
1 subcomments
A good reason to health check the kubelet process and restart it when the checks fail.
by jeffbee
1 subcomments
Given that this happens on the main loop, one wonders how this escaped release quality checks. Is there another contributing cause that narrows the impact?
Hacker News