One of my favorite values that Kubernetes provides
As a dev, you've experienced memory leaks from time to time, even sometimes within a mostly managed framework, since sometimes folks have to wrap some unmanaged object and forget to put a finalizer. They can be very difficult to track down sometimes...
So lets say that your code with the hidden leak was in a container. If you were to take that container, and write up a Kubernetes deployment template for it, you could ask that Kubernetes monitor its memory consumption. You can also specify that when it reaches some threshold (say 85%) that kubernetes is to start up a new instance.
What's really beautiful about this is that Kubernetes will start up the new instance, and wait for it to declare itself fully ready before it ever touches the old instance. And since all of your customer's traffic is routed through a Kubernetes service object (where the port connections are defined), it will only suddenly switch-the-traffic to the newly started container after it declares itself fully ready.
It will then even wait for all of the API calls still processing through the old container to finish before requesting that container to stop.
So, in a seamless way, and in a fully automated way, the issue with the memory leak had absolutely no consequences to your customer as you work to try to find and fix it.
To me, that's beautiful.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
One of my favorite values that Kubernetes providesAs a dev, you've experienced memory leaks from time to time, even sometimes within a mostly managed framework, since sometimes folks have to wrap some unmanaged object and forget to put a finalizer. They can be very difficult to track down sometimes...
So lets say that your code with the hidden leak was in a container. If you were to take that container, and write up a Kubernetes
deployment templatefor it, you could ask that Kubernetes monitor its memory consumption. You can also specify that when it reaches some threshold (say 85%) that kubernetes is to start up a new instance.What's really beautiful about this is that Kubernetes will start up the new instance, and wait for it to declare itself fully ready before it ever touches the old instance. And since all of your customer's traffic is routed through a Kubernetes
serviceobject (where the port connections are defined), it will only suddenly switch-the-traffic to the newly started container after it declares itself fully ready.It will then even wait for all of the API calls still processing through the old container to finish before requesting that container to stop.
So, in a seamless way, and in a fully automated way, the issue with the memory leak had absolutely no consequences to your customer as you work to try to find and fix it.
To me, that's beautiful.