The "atomicity" (a misleading term, I agree, but I couldn't think of a better one as I was writing the comment) I was referring to was its ability to do a destructive diff/patch. In other words, if you apply state (A+B+C), then (A+B), it will remove C.

With plain "kubectl apply", there's the "--prune" flag, which is supposed to be able to track upstream resources via annotations. But it's still considered experimental alpha functionality, as least according to the "kubectl --help" for Kubernetes 1.11.9.

Yeah I read your reply above and I do see your point. For our own services that we continuously deploy this really just doesn't come up. If we have an http or rpc service it's going to have a deployment, a service, and maybe an ingress for pretty much all of time. If we needed to remove a thing in that scenario it might be the ingress if we change architecture, but it would be a big enough deal that cleaning up manually wouldn't be an added burden.

Deletion is definitely less common, but we do this all the time. It keeps cruft from accumulating when people forget to delete resources.

It's also nice to be able to do "helm del myapp" and know that everything is wiped. You can do this with "kubectl delete -R -f", but I believe you need the original files. You can of course do something like "kubectl delete -l app=myapp", but this requires consistent use of a common label in all your resources.

You can also use kubectl patch locally to apply a label to a set of manifests locally before piping into kubectl apply, eg:

  kubectl patch -f input.yaml --type merge -p '{"metadata": { "labels": {"key": "value"} } }' --dry-run -o json | kubectl apply -f - --prune -l key=value