<p>We can use a declarative approach for creating and updating kubernetes resources using <code>kubectl apply -f</code> , how can we do the same for recyclying the resources that are no longer needed. </p>

<p>I have used <code>kubectl delete</code>  , but that looks like imperative , and sometimes we will need to delete things in proper order. </p>

<p>Is there a way to always use <code>kubectl apply</code> and it figures out itself which resources to keep and which to delete. Just like in <code>Terraform</code>.</p>

<p>Or we should conclude that currently the declarative approach works for resource creation and update only.</p>

<p><strong>Use case:</strong></p>

<p>For example , we have decided not to provide the K8S API to end users and instead provide them a repository where they keep and update thier yaml files that a bot can apply to the cluster on each update when the pull request is merged. So we need this declarative delete as well so that we don't have to clean up things after users. <code>Terraform</code> provider maybe the solution but in that case things will lock to terraform and users will need to learn one more tool instead of using the native k8s format.</p>

Ijaz Ahmad
<p>Truns out that they have added a declarative approach for pruning the resources that are no longer present in the yaml manifests:</p>

<pre><code>kubectl apply -f &lt;directory/&gt; --prune -l your=label
</code></pre>

<p>With too many cautions though.</p>

<blockquote>
  <p>As an alternative to kubectl delete, you can use kubectl apply to
  identify objects to be deleted after their configuration files have
  been removed from the directory. Apply with --prune queries the API
  server for all objects matching a set of labels, and attempts to match
  the returned live object configurations against the object
  configuration files. If an object matches the query, and it does not
  have a configuration file in the directory, and it has a
  last-applied-configuration annotation, it is deleted.</p>
</blockquote>
