Mischa van den Burg
Tags:
In this blog we will explore application deployment in AKS on Azure Local. Our goal is to find out if there are any significant differences between our trusted AKS on Azure experience and the local experience.
One of the compelling reasons to use Azure Local is that we get the same experience that we are used to when managing AKS through the Azure Portal. The value proposition for Azure Local is that we can have the same ease of management for on-premises hardware. In this blog we will find out if this is truly the case.
We have an AKS cluster deployed on our Azure Local instance. I need to be able to reach the Kubernetes cluster which is running inside a logical network in the datacenter. I can connect to that network using a VPN solution, or use a management machine that is connected on that network. In our case, we are using ZeroTier as a VPN solution.
Zerotier provides a secure software-defined network that allows us to connect to our private infrastructure as if it were on the same local network. This eliminates the need for complex VPN configurations while maintaining security and ease of access.
When examining the Kubernetes cluster with kubectl, we can see that we have 3 worker nodes, a control plane, and a default storage class installed. This storage class is able to provision persistent storage on the nodes of the Azure Local cluster. At this point, we don’t have any custom workloads deployed yet.
When we inspect further, we can see that there are several deployments on the cluster which are necessary for running the cluster and connecting to it. These include core Kubernetes components like CoreDNS for service discovery, Calico for our CNI and network policies, and Azure-specific components that enable integration with Azure services and management interfaces.
The Azure portal provides a convenient way to visualize these deployments through the Workloads pane. This interface looks identical to what you would see when managing a cloud-based AKS cluster, reinforcing Azure Local’s promise of providing a consistent experience.
Now I don’t think I need to demonstrate that I can run an nginx pod using kubectl, we have seen that trick often enough. I am only interested in deploying applications using methods that follow the industry standards for running workloads on Kubernetes. In other words, I need to be able to use GitOps to deploy my infrastructure workloads and applications.
GitOps is a methodology that uses Git as the single source of truth for declarative infrastructure and applications. With GitOps, any changes to your infrastructure are made through Git, providing versioning, audit trails, and the ability to roll back changes if needed.
Fortunately, the GitOps integration works exactly the same as it does on Azure AKS. We can simply open the GitOps pane and install the Flux extension for the Kubernetes cluster.
Flux is a popular GitOps operator that ensures the state of your cluster matches the configuration stored in Git. It continuously monitors your Git repository and automatically applies changes when they’re detected, making it a powerful tool for maintaining consistent deployments.
This pane will walk us through setting up our kustomization for the cluster. For this example, I have created a simple containerized application: the DevOps Study tracker. It is written in Python and consists of a backend and a frontend container.
The backend container manages the application’s data and business logic, exposing an API that the frontend can interact with. The frontend container provides the user interface, allowing users to interact with the application through their web browsers. Both containers are packaged as Docker images and deployed to the Kubernetes cluster as separate services.
In order to make our application run properly, we have to perform some patches to the base layer. We need to adjust the type of service and make sure we are targeting the right service when connecting from the frontend to the backend.
Kustomize is a powerful tool for customizing Kubernetes manifests without modifying the original files. In our case, we’re using it to:
These patches are defined in YAML files and referenced in our kustomization.yaml configuration. This approach allows us to maintain a clean base configuration while applying environment-specific changes.
We point our GitOps configuration to the apps/prod directory to sync our patched Kubernetes manifests to our Azure Local cluster. This directory contains our production-ready configurations, including all the necessary patches and environment-specific settings.
Once configured, Flux will monitor this directory for changes and automatically apply them to the cluster. This eliminates manual deployments and ensures that your cluster always reflects the desired state defined in your Git repository.
After setting up GitOps, we can monitor the deployment progress through the Azure portal or using kubectl commands. Flux provides detailed logs and status information about the synchronization process, allowing us to troubleshoot any issues that might arise.
After a while, we see that the required pods and configurations for Flux have been applied automatically to the cluster for us:
The Azure portal’s GitOps view shows the status of our configurations, including when they were last synchronized and whether there were any errors during the process. This gives us a quick way to verify that our deployment is running as expected.
From the CLI we can verify that our workloads are deployed:
And they are available in the Workloads pane as well:
Once the deployment is complete, we can access our application by navigating to the service endpoint. Since we’re using ClusterIP for our services, we’ll need to either use port forwarding or an ingress controller to access the application from outside the cluster.
For testing purposes, we can use kubectl port-forward to temporarily expose the frontend service:
kubectl port-forward service/frontend -n study-app 3500:22111
This will allow us to access the application at http://localhost:3500 in our web browser.
Our exploration of AKS on Azure Local has shown that the experience is remarkably similar to using AKS in the cloud. We were able to set up GitOps-based deployments using the same tools and interfaces that we’re used to with cloud-based AKS.
The key advantages we’ve observed:
Azure Local delivers on its promise of providing a consistent management experience for on-premises Kubernetes deployments. This consistency makes it an attractive option for organizations looking to maintain hybrid cloud deployments or those with specific requirements that necessitate on-premises infrastructure.
Gerelateerde blogs
