DEV Community

Cover image for Kubernetes on AKS: From Zero to Production Workloads - Publishing to GitHub and Cleaning Up Azure Resources (Part 9/9)
Rahimah Sulayman
Rahimah Sulayman

Posted on

Kubernetes on AKS: From Zero to Production Workloads - Publishing to GitHub and Cleaning Up Azure Resources (Part 9/9)

#kubernetes #azure #devops #github

Introduction

Building a cloud-native environment is only part of the engineering process. A complete project also needs version-controlled implementation artifacts, a reproducible record of the work, and a deliberate cleanup strategy that prevents unused cloud resources from continuing to incur charges.

In this final mission, I published the Kubernetes manifests to GitHub, verified that the lab namespace could be removed, deleted the Azure resource group, checked the status of the associated resource groups, and removed the obsolete Kubernetes context from the local kubeconfig.

The objective was to preserve the implementation as portfolio evidence while ensuring that the temporary Azure environment was decommissioned.

What This Part Covers

  • Committing the Kubernetes manifests to Git.
  • Publishing the repository to GitHub.
  • Verifying namespace removal.
  • Deleting the Azure resource group.
  • Checking that the AKS-managed resource group was removed.
  • Deleting the obsolete Kubernetes context.
  • Confirming what remains available after the cloud environment is deleted.

1. Review the Kubernetes Manifests

The project contains nine Kubernetes manifest files covering the workloads and resources implemented throughout the lab.

The files are organized under the manifests/ directory:

ls manifests
Enter fullscreen mode Exit fullscreen mode

The output showed:

01-pod.yaml
02-deployment.yaml
03-service-clusterip.yaml
04-service-loadbalancer.yaml
05-configmap.yaml
06-statefulset.yaml
07-daemonset.yaml
08-job.yaml
09-cronjob.yaml
Enter fullscreen mode Exit fullscreen mode

The manifests capture the main resources from the project:

Manifest Resource
01-pod.yaml Standalone Pod
02-deployment.yaml Deployment
03-service-clusterip.yaml Internal ClusterIP Service
04-service-loadbalancer.yaml LoadBalancer Service
05-configmap.yaml ConfigMap
06-statefulset.yaml Headless Service and StatefulSet with persistent storage
07-daemonset.yaml DaemonSet
08-job.yaml Batch Job
09-cronjob.yaml Scheduled CronJob

Keeping these resources in version control preserves the configuration used throughout the lab. The manifests provide a reference for the implementation and can be reviewed independently of the Azure environment in which they were deployed.

2. Commit the Manifests to Git

I committed the workload manifests with a message describing the implementation:

git commit -m "feat: AKS workloads (pods, deployment, services, config, statefulset, daemonset, job, cronjob)"
Enter fullscreen mode Exit fullscreen mode

commit

Git confirmed the commit:

[main 610883d] feat: AKS workloads (pods, deployment, services, config, statefulset, daemonset, job, cronjob)
9 files changed, 206 insertions(+)
Enter fullscreen mode Exit fullscreen mode

The commit created the nine manifest files in the repository.

A descriptive commit message makes the change easier to identify in the project history. It also establishes a clear record of the implementation being preserved for the portfolio.

3. Configure the GitHub Remote

I configured the local repository to use the GitHub repository:

https://github.com/rahimahisah17/aks-kubernetes-lab.git
Enter fullscreen mode Exit fullscreen mode

The command used was:

git remote add origin https://github.com/rahimahisah17/aks-kubernetes-lab.git 2>/dev/null || git remote set-url origin https://github.com/rahimahisah17/aks-kubernetes-lab.git
Enter fullscreen mode Exit fullscreen mode

git remote add

This command adds origin when it does not already exist or updates its URL when the remote has already been configured.

Using a remote allows the local Git repository to publish commits to GitHub and maintain a shared record of the implementation.

4. Push the Project to GitHub

With the remote configured, I pushed the main branch:

git push -u origin main
Enter fullscreen mode Exit fullscreen mode

git push

The command completed successfully:

Enumerating objects: 19, done.
Counting objects: 100% (19/19), done.
Compressing objects: 100% (18/18), done.
Writing objects: 100% (19/19), 3.70 KiB | 84.00 KiB/s, done.
Total 19 (delta 2), reused 0 (delta 0), pack-reused 0

To https://github.com/rahimahisah17/aks-kubernetes-lab.git
 * [new branch]      main -> main
branch 'main' set up to track 'origin/main'.
Enter fullscreen mode Exit fullscreen mode

The push published the branch and configured it to track origin/main.

The project repository is available here:

GitHub — aks-kubernetes-lab

Publishing the manifests ensures that the configuration remains accessible even after the cluster and its cloud resources have been deleted.

The repository also serves as portfolio evidence of the project implementation, including the manifest structure and version-control history.

5. Delete the Kubernetes Lab Namespace

After the GitHub push succeeded, I removed the namespace containing the lab workloads:

kubectl delete namespace k8s-lab
Enter fullscreen mode Exit fullscreen mode

Kubernetes returned:

namespace "k8s-lab" deleted
Enter fullscreen mode Exit fullscreen mode

I then inspected the remaining namespaces:

kubectl get namespaces
Enter fullscreen mode Exit fullscreen mode

The output listed the remaining namespaces:

NAME              STATUS   AGE
default           Active   5h9m
kube-node-lease   Active   5h9m
kube-public       Active   5h9m
kube-system       Active   5h9m
Enter fullscreen mode Exit fullscreen mode

delete ns

The k8s-lab namespace was no longer present.

Deleting a namespace removes the Kubernetes resources contained in it, subject to their deletion and finalization behavior. This removed the dedicated lab namespace and its namespaced workloads from the cluster.

However, deleting a Kubernetes namespace does not itself decommission the AKS cluster or remove every Azure resource associated with it. The Azure resource group therefore needed to be deleted separately.

6. Delete the Azure Resource Group

The Azure environment used the following configuration:

RESOURCE_GROUP=rg-aks-lab
CLUSTER_NAME=aks-lab
LOCATION=westeurope
NODE_SIZE=Standard_D2s_v3
Enter fullscreen mode Exit fullscreen mode

I first attempted to delete the resource group using the environment variable:

az group delete --name $RESOURCE_GROUP --yes --no-wait
Enter fullscreen mode Exit fullscreen mode

The command returned an error:

argument --name/-n/--resource-group/-g: expected one argument
Enter fullscreen mode Exit fullscreen mode

The variable was not populated in that shell because I switched to another terminal, so Azure CLI did not receive a resource group name.

I then supplied the resource group name explicitly:

az group delete --name rg-aks-lab --yes --no-wait
Enter fullscreen mode Exit fullscreen mode

delete resources

This issued the resource group deletion request.

The --yes option skips the interactive confirmation, while --no-wait returns without waiting for the deletion operation to finish. As a result, the command's return does not, on its own, establish that the resources have already disappeared.

For cleanup operations, verification is essential because Azure resource deletion can continue asynchronously after the command returns.

7. Verify the Azure Resource Group Cleanup

The AKS deployment had a primary resource group and an AKS-managed resource group. I checked for both using:

az group list --query "[?starts_with(name, 'rg-aks-lab') || starts_with(name, 'MC_rg-aks-lab')].name" --output tsv
Enter fullscreen mode Exit fullscreen mode

An initial check still showed:

rg-aks-lab
MC_rg-aks-lab_aks-lab_westeurope
Enter fullscreen mode Exit fullscreen mode

Initial deletion

This indicated that the deletion process had not yet removed both resource groups from the listing.

I repeated the check after the deletion process had progressed:

az group list --query "[?starts_with(name, 'rg-aks-lab') || starts_with(name, 'MC_rg-aks-lab')].name" --output tsv
Enter fullscreen mode Exit fullscreen mode

The subsequent output was empty, confirming that neither matching resource group remained in the returned list.

successful deletion

The verification covered both the main lab resource group and the resource group created by AKS to manage supporting infrastructure.

This distinction matters because AKS can create Azure resources outside the visible workload definitions in the Kubernetes manifests. A complete cleanup check should account for the managed infrastructure, rather than checking only the primary resource group.

8. Remove the Obsolete Kubernetes Context

With the AKS environment decommissioned, I removed its local Kubernetes context:

kubectl config delete-context aks-lab
Enter fullscreen mode Exit fullscreen mode

The command returned:

warning: this removed your active context, use "kubectl config use-context" to select a different one
deleted context aks-lab from /home/rahimahisah/.kube/config
Enter fullscreen mode Exit fullscreen mode

delete context

The context had stored the connection configuration used by kubectl to access the aks-lab cluster.

Removing it cleans up the local kubeconfig after the cluster has been deleted. The warning also notes that the removed context had been active, so another context would need to be selected before using kubectl against a different cluster.

This step removes the local connection entry; it does not delete the local repository, manifests, or GitHub project.

9. What Remains After Cleanup?

The cleanup separates the cloud environment from the project artifacts.

Component Final state
k8s-lab namespace Deleted
Main Azure resource group rg-aks-lab No longer present in the verification listing
AKS-managed resource group No longer present in the verification listing
Local aks-lab kubeconfig context Deleted
Local project directory Preserved
Kubernetes YAML manifests Preserved locally
Git commit history Preserved in the repository
GitHub repository Published and available

This separation is important for cloud labs. The resources used to demonstrate the implementation can be removed without discarding the configuration, documentation, and version-control history that make the work reproducible and useful as portfolio evidence.

Although the Azure resource groups were removed from the verification listing, the final Azure bill remains the authoritative source for confirming any outstanding or previously accrued charges. Deletion stops the continued use of the deleted resources, but it does not erase charges already incurred.

10. Operational Takeaways

This final mission brought together version control, cloud resource lifecycle management, and verification.

The main takeaways were:

  • Version-controlled infrastructure: Kubernetes manifests provide a durable record of the resource configuration used in the lab.
  • Repository publishing: Pushing the project to GitHub preserves the implementation beyond the lifetime of the AKS cluster.
  • Namespace cleanup: Removing the lab namespace deletes its dedicated Kubernetes workloads and resources.
  • Azure resource cleanup: Deleting the primary resource group initiates removal of the cluster and related Azure resources.
  • Asynchronous deletion: Commands using --no-wait require a separate verification step to confirm the resources have disappeared.
  • Managed-resource awareness: AKS can create a separate managed resource group that should be included in cleanup verification.
  • Local configuration hygiene: Removing an obsolete kubeconfig context prevents local configuration from retaining an unnecessary connection entry.
  • Cost awareness: Cloud cleanup should be verified rather than assumed, and actual billed amounts should be checked independently.

Conclusion: From Cluster Provisioning to Decommissioning

The nine-part series brought together AKS provisioning, Kubernetes workloads, networking, configuration, persistent storage, batch processing, scheduled automation, and cost optimization.

In this final mission, I committed the nine workload manifests, pushed the project to GitHub, deleted the k8s-lab namespace, issued the Azure resource group deletion request, verified that the primary and AKS-managed resource groups were no longer listed, and removed the obsolete Kubernetes context.

The result is a preserved project repository without the temporary cloud infrastructure used to run it.

The central operational principle is straightforward: infrastructure work is not complete until its implementation has been preserved and its temporary resources have been deliberately decommissioned. Version-controlled manifests retain the engineering evidence, while verified cleanup helps prevent unnecessary ongoing resource consumption.

This article is Part 9 of the nine-part series, “Kubernetes on AKS: From Zero to Production Workloads.”

Top comments (1)

Collapse
 
rahimah_dev profile image
Rahimah Sulayman •

A successful cloud project should demonstrate not only how infrastructure is deployed, but also how it is maintained, documented, and safely decommissioned. This final mission brings the full workflow together: preserving Kubernetes manifests in GitHub, verifying Azure resource cleanup, and removing obsolete local cluster configuration. The infrastructure may be deleted, but the repository remains as portfolio evidence of the implementation. A clean teardown is part of responsible cloud engineering.