<p>I'm attempting to write some integration tests that setup a deployment and an ingress and then make web requests, effectively curl commands, against the ingress to test the configuration of the ingress.  Backends and services are also created to gaurantee that the ingress is correctly routing and proxying to the backends.</p>
<p>However, tear down of the setup, to run a new set of tests is slow.  By 'teardown' here I mean I simply delete the namespace in which all of these deployments live.  This can take quite a while.  Why is that?  And what are the best ways to quickly tear down such a setup?</p>

lucidquiet
<p>Kubernetes works largely through controllers, which loop endlessly looking for small pieces of work to do (like schedule a pod somewhere, unschedule a pod, remove an ingress route, etc); this makes it highly reliable but sometimes comes at the cost of relatively high latency for your operations. Namespace deletions require bringing down all the resources in a cluster, which requires a lot of small steps and therefore can take a while to finish.</p>
<p>There is a <code>--force</code> option for <code>kubectl delete</code>, but it comes with some scary-sounding warnings:</p>
<pre><code>--force=false: If true, immediately remove resources from API and
  bypass graceful deletion. Note that immediate deletion of some
  resources may result in inconsistency or data loss and requires
  confirmation.
</code></pre>
<p>So, this probably isn't advisable as a regular thing to do (perhaps someone more familiar with its behavior can add on to this).</p>
<p>Another option is to let the delete proceed asynchronously and just not block your CI jobs on it. The <code>--wait=false</code> flag (by default, set to true)  will make sure the request is entered successfully but won't block kubectl from exiting while the delete actually happens. Your namespace will enter the <code>Terminating</code> state and eventually get deleted (unless something prevents it from coming down).</p>
<pre><code>kubectl delete namespace my-test-namespace-1 --wait=false
</code></pre>
<p>This does mean that your next CI run may find the namespace is still there. To avoid a conflict, you could use a random suffix or incrementing counter for the namespace's name.</p>
