<p>The professional solution is something like fluxcd. This will automatically &quot;apply&quot; any .yaml files that you commit to your git repo, and also automatically remove those resources if it tracks that they have been deleted from the repo.</p>
<p>The problem with what you are asking for, is that kubernetes needs a way of knowing <em>which</em> resources you want it to delete. (For example, you may be using a shared cluster, and not want to inadvertently delete other applications and system pods, even if they are not explicitly mentioned in your private local working directory.) That said, if you <em>have</em> diligently labelled the specific resources you want to manage, then the feature <em>does</em> exist: use the <code>--prune</code> argument to <code>kubectl apply</code> as described in the <a href="https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune-l-your-label" rel="nofollow noreferrer">docs</a>.</p>

CC BY-SA 4.0
2022-12-30T00:04:14.203Z
2022-12-30T00:04:14.203Z
benjimin
<p>I feel like I have a terrible knowledge gap when it comes to managing the resource states within Kubernetes.</p>
<p>Suppose I have 2 deployments in my cluster, <code>foo1</code> and <code>foo2</code>. They are both defined in separate <code>yaml</code> files, <code>foo1.yaml</code> and <code>foo2.yaml</code> that are both inside a <code>my-dir</code> directory and have been applied with <code>kubectl apply -f my-dir/</code></p>
<p>Now I want to make a third deployment, but also delete my second deployment. I know that I can do this in 2 steps:</p>
<ul>
<li>Make another <code>foo3.yaml</code> file inside the directory and then do <code>kubectl apply -f my-dir/foo3.yaml</code></li>
<li>Run <code>kubectl delete -f my-dir/foo2.yaml</code> to get rid of the second deployment.</li>
</ul>
<p>My question is, can I do this in one shot by keeping the &quot;desired state&quot; in my directory. i.e. Is there any way that I can delete <code>foo2.yaml</code>, create a new <code>foo3.yaml</code> and then just do <code>kubectl apply -f my-dir/</code> to let kubernetes handle the deletion of the removed resource file as well? What am I missing here?</p>

<kubernetes><kubectl>
Kubernetes apply to get to desired state
Murali Varma
# Kubernetes apply to get to desired state

(Asked by: username_0 on 2022-12-29)

I feel like I have a terrible knowledge gap when it comes to managing the resource states within Kubernetes.

Suppose I have 2 deployments in my cluster, `foo1` and `foo2`. They are both defined in separate `yaml` files, `foo1.yaml` and `foo2.yaml` that are both inside a `my-dir` directory and have been applied with `kubectl apply -f my-dir/`

Now I want to make a third deployment, but also delete my second deployment. I know that I can do this in 2 steps:

* Make another `foo3.yaml` file inside the directory and then do `kubectl apply -f my-dir/foo3.yaml`
* Run `kubectl delete -f my-dir/foo2.yaml` to get rid of the second deployment.

My question is, can I do this in one shot by keeping the "desired state" in my directory. i.e. Is there any way that I can delete `foo2.yaml`, create a new `foo3.yaml` and then just do `kubectl apply -f my-dir/` to let kubernetes handle the deletion of the removed resource file as well? What am I missing here?

**Tags:** kubernetes, kubectl


---

## 1 answers

### Answer by username_1 on 2022-12-30. Score: 1

The professional solution is something like fluxcd. This will automatically "apply" any .yaml files that you commit to your git repo, and also automatically remove those resources if it tracks that they have been deleted from the repo.

The problem with what you are asking for, is that kubernetes needs a way of knowing *which* resources you want it to delete. (For example, you may be using a shared cluster, and not want to inadvertently delete other applications and system pods, even if they are not explicitly mentioned in your private local working directory.) That said, if you *have* diligently labelled the specific resources you want to manage, then the feature *does* exist: use the `--prune` argument to `kubectl apply` as described in the [docs](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/#alternative-kubectl-apply-f-directory-prune-l-your-label).


---

