3 ms·

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 strat

by cfors 7y ago

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-object-kubectl-patch/#notes-on-the-strategic-merge-patch https://kubernetes.io/docs/tasks/run-application/update-api-...

bacongobbler 7y ago
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.
- cfors 7y ago
  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.
  - bacongobbler 7y ago
    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-strategic-merge-patches https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-st...
    - mfer 7y ago
      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.

by cfors 7y ago

bacongobbler 7y ago

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.

cfors 7y ago
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.
- bacongobbler 7y ago
  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-strategic-merge-patches https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-st...
  - mfer 7y ago
    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.