Deleting a Django Application from a Multi-Site Kubernetes Cluster

Recently, a client requested that we delete a website that was no longer used. The Kubernetes cluster was managed by an engineer who is no longer with the company, making the cluster feel like a concealed box. All I had was the website’s name. Since we use Ingress Nginx and Nginx as a web server, I figured the answer to my query could be found there. So I ran:

kubectl get ingress --all-namespaces | grep website-url-to-delete.com

And there it was:

target-ns-prod   ingress       <none>   website–url-to-delete.com      r0n4r9ca4e18004896b794ecd83b6cacb-14b8740e8ejf9fna.elb.us-east-2.amazonaws.com   80, 443   5y185d

The correct production namespace, target-ns-prod, was identified. Next, I dug a bit deeper to confirm it was indeed the correct namespace(ns) and to see which other namespaces were associated with the site:

> kubectl get ns | grep target-ns

This returned:

NAME                           	   STATUS   AGE
   target-ns-prod ✅                   Active   2y178d 
   target-ns-prod-hosting-services ✅  Active   723d 
   target-ns-qa ✅                     Active   2y178d

After compiling a list of relevant namespaces, I started by deleting the deployments—since they act as controllers managing the pods. I listed all target deployments with:

kubectl get deployments --all-namespaces | grep target-ns

I began with the staging environment, ensuring one final time that it was the correct site:

kubectl delete deployment deployment-name --namespace target-ns-qa

After that, I deleted the corresponding namespace:

> kubectl delete namespace target-ns-qa

This command took the correct staging environment down. I then repeated the same steps for the remaining deployments and namespaces.

Deleting the website from Kubernetes is only the first step; several additional tasks must be completed:

• Delete the DNS entry to prevent domain hijacking and other security concerns.
• Remove any Infrastructure as Code (IaC) files associated with the site from your repository.
• Remove any databases associated with the site.
• Optimize resource usage (This step is not a must). However, since the removed site was highly resource-consuming, I decided to reduce the number of nodes in the cluster.