4 comments

  • compumike15 hours ago
    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.
  • fsuts9 minutes ago
    Not all heroes wear capes! Well done
  • rirze51 minutes ago
    Very cool. It's often daunting to contribute to such a well-established and recognizable project, but this is exactly how it should work.
  • CamouflagedKiwi32 minutes ago
    Nice find.<p>Can&#x27;t help but feel this is one of the subtle traps hidden beneath the advice that contexts aren&#x27;t supposed to be stored. I know it&#x27;s not always that easy, of course.
    • compumike3 minutes ago
      Thanks. I know there&#x27;s a `go vet` tool that&#x27;s run as part of Kubernetes CI, and one of its checks is:<p><pre><code> lostcancel: check cancel func returned by context.WithCancel is called </code></pre> I&#x27;m not 100% sure why `go vet` didn&#x27;t catch this issue, but storing the context in the struct is probably part of the reason.