Deployment of resources needs to use kubectl apply semantics

[jessesuen]

The way we are updating resources is not correct. kube.go::ApplyResource() is doing a simple Update() but it needs to do a Patch() using 3-way strategic merge like kubectl. Kubectl achieves this by storing last-applied-configuration as an annotation and incorporate that into the calculation. We need to do the same.

[jessesuen]

Some reference points:

Declarative Management of Kubernetes Objects Using Configuration Files
https://kubernetes.io/docs/concepts/overview/object-management-kubectl/declarative-config/

Advanced Configuration Management (kubectl apply reboot)
https://docs.google.com/document/d/1q1UGAIfmOkLSxKhVg7mKknplq3OTDWAIQGWMJandHzg/edit

Server side apply design sketch:
https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/kubernetes-sig-api-machinery/OxLyMNp8I6A/s_L6bToZAgAJ

v2 API proposal "desired vs actual"
kubernetes/kubernetes#17333

Apply v2
https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cli/apply_refactor.md

[jessesuen]

For the record, a helm upgrade will do a 2-way strategic merge patch.

[jessesuen]

Given the complexity of the topic, I'm proposing that we just submit manifests literally just using the kubectl apply CLI. There's very little to be gained in any attempt to copy/re-implement kubectl's 3-way patch logic, other than having a pure go implementation, and not having to deal with forked processes.

On the other hand it provides the following benefits:

1. meets users' expectation
2. easy to explain -- the behavior of kubectl apply is very well documented
3. it allows management of the application outside of Argo CD (e.g. users can perform a kubectl apply from their workstation)
4. related to point 3, it enables Argo CD to adopt existing deployment pipelines which have been built using kubectl apply.
5. needs no testing or code maintenance, since this logic is deferred to kubectl
6. quick/easy to implement. we can move on to other features