Hacker News Reader

Comment by mfer | Hacker News Reader

To add context, when updating objects in place a strategic merge is how the Kubernetes docs tell you to do and they they provide a kubectl example [1]. If this is not the right way to do it I would suggest that conversation would be good to have in the Kubernetes project itself.

[1] https://kubernetes.io/docs/tasks/run-application/update-api-...

View on HN

I am aware of that, and here is one the of the issues I have with the strategic patch strategy:

> The patch you did in the preceding exercise is called a strategic merge patch. Notice that the patch did not replace the containers list. Instead it added a new Container to the list. In other words, the list in the patch was merged with the existing list. This is not always what happens when you use a strategic merge patch on a list. In some cases, the list is replaced, not merged. [0]

This seems like a lot of cognitive overload. I understand there are some use cases for this but really, all I want is to have my K8s resources all tracked with a git commit reference and then that is what is deployed exactly.

[0] https://kubernetes.io/docs/tasks/run-application/update-api-...

This is not how things work in reality. Many last-mile objects are merged into your Kubernetes resources at the last minute. Service meshes inject sidecar containers into your deployments. The Kubernetes API can update a Service's virtual IP addresses which can change over time. All of these object updates need to be taken into consideration during an upgrade, or you risk disrupting resources running in production.

I'm not saying there isn't a use case for this, it's just that for the most part I prefer dumping what I have from an immutable git commit into the Kube API. If something needs to happen after the fact for governance or injecting sidecars, so be it but that is out of the scope of what I am deploying.

Then that's fine. If no updates were made to the resource since the last update, then the patch will not look at the live state.

I highly suggest re-reading the FAQ front-to-back on this subject. I spent a lot of time explaining the details on this subject. If you have any questions/concerns, we are always happy to discuss further on github.

https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-st...

To take a step back... we're discussing a personal opinion on how to manage things compared to what k8s has documented and what's happening with other tools like service meshes.

I respect what someone has as an opinion. I just would like others to know where the opinion differs from the docs and tools out there. People can make their own choices.

Reply on news.ycombinator.com