Video Transcript:
-Coming up, we’ll take a look at the new hybrid deployment options for Azure Kubernetes Service enabled by Azure Arc. If you’re a developer, I’ll demonstrate how you can now deploy AKS on your Windows 10 or Windows 11 IoT devices at the edge, as well as improved integration with Azure AD for secure access to AAD-enabled resources. And for admins, I’ll show a few key updates, including Azure Fleet Manager as a single management view for your Kubernetes clusters, along with monitoring updates using managed Grafana and the Prometheus add-on for aggregated insights.
-So let’s get started. First, for context, if you’re new to AKS, while there are a lot of options and container distros available, Azure Kubernetes Service is unique in that, as a managed service, you can more quickly and easily spin up new Kubernetes clusters. It is deeply integrated with the most common DevOps and CI/CD tools that you’re probably already using today. AKS provides some of the highest security, policy, and identity controls. And plus, the cloud-managed service runs in more regions than any other cloud provider.
-Next, if you’re new to Azure Arc, it serves as a bridge to unify management across your data centers, edge compute, and across other clouds. This gives you freedom as a developer to create new workloads in the Azure cloud using cloud-native tools and then bringing what you build into production, including core Azure services, to on-premise infrastructure and even other clouds when you need to. In fact, AKS combined with Azure Arc is what gives you the ability to run AKS anywhere you need it.
-Now let’s make this real with an example using a retail store app that is currently running in AKS on Azure, and I’ll show you how you can deploy it to an Arc-enabled AKS cluster running on a Windows 11 client IoT device at the edge, and all using a shared GitOps flow. I’m in the Azure Portal, and in the resource group, you’ll see two types of AKS clusters, one deployed in Azure that is used for Contoso’s development and integration tests and another running on a Windows 11 based IoT device. This is a physical, small footprint machine running in local supermarkets. The AKS-IoT cluster running on Windows 11 is Arc-enabled, which allows for consistent software rollouts using GitOps and to support IT operational needs. Let’s take a look at the application itself now. On the left, we can see the non-production version of the app deployed to the AKS cluster in Azure and discoverable via a public IP address. And on the right, the production version of our application is running on our Windows client machine running AKS. It has local store cameras enabled, and it’s using a private IP address.
-Now, Contoso also regularly updates their inventory with new products. To do that, a new version of the supermarket application needs to be tested and then deployed into production on the IoT device. By having the same GitOps configuration and using the same GitHub repo for each, we can deploy our new app updates to both clusters. Let me show you the configurations for each one. I’ll start with the Azure-hosted AKS cluster for our non-production version of the app. The GitOps configuration is pointing to a GitHub repository, which is where the application’s Kubernetes manifest files are located and are used to deploy the Supermarket application onto the cluster.
-Switching to the production AKS cluster at the store, you’ll see the same GitOps configuration is pointing to the same GitHub repository. This ensures the software rollout is consistent across both. I’ll switch over to the Windows Terminal. Using the kubectl get nodes command on the top, you’ll see the AKS cluster nodes and, on the bottom, the Arc-enabled AKS single-node cluster deployed on Windows IoT. You’ll also see that the underlying image for the nodes on both clusters is running CBL Mariner, an open-source Linux distro created by Microsoft and now available for preview as an AKS container host.
-Now let’s say we want to create a new app version to add support for Contoso’s new toy business. Let’s take a look at the contosoPOS Kubernetes namespace and the pods deployed on both clusters so we can see the update in real time. To start the deployment, I’ll head over to Visual Studio Code. First, we’ll see that the local branch is pointing to the GitOps configuration remote branch URL. Now let’s take a look at our manifest files. The first YAML file is describing the application’s development version, which, again, is our non-production app that is currently deployed on AKS in the cloud. Notice the camera integration and the new toys category are currently set to False. On the second YAML file, for the in-store production version, we have the camera integration set to True and the new Toys category is currently set to False. To test the new Toys category and the updated application interface, I’ll first enable the new category for the development AKS cluster. This allows us to validate that new category is added to the updated interface is working. I’ll go ahead and commit and then push the changes to the GitHub repo.
-Now, as the new application pod is deploying, you’ll see that the old one gets terminated. I’ll just go ahead and refresh the browser, and notice the app controls have changed. A new Toys category was added, and you can also see a few of the toys added to the catalog. So now that we know it works, let’s apply this change to our production environment. Here, in the second YAML file describing the app’s production version, we’ll enable the new category. Since this is the production version that is deployed in the store, we’re also leaving the camera integration enabled. Like before, I’ll commit and push the updates to the GitHub repo. Now the new version is rolling out to the production AKS cluster in the store. I’ll go ahead and refresh the browser again, and you’ll see the in-store version matches our development environment UI, but with the addition of the local camera feeds.
-So you just saw how easy it was to iterate on new versions of our point-of-sales application across two different AKS environments running in the cloud and at the edge. This gives you the freedom to deploy your AKS clusters and apps wherever they need to run. Now let’s switch gears to highlight other important AKS updates that you can try out.
-First, for improved operational visibility, Azure Managed Grafana is now generally available with its great dashboarding capabilities. And for aggregated insights, you can use the Prometheus Add-on for AKS, which is now in public preview. Second, if you’re managing multiple clusters, we’ve recently made Azure Fleet Manager available in public preview, and among other capabilities, this gives you a single view and management service for all of your Kubernetes deployments and instances. And soon, Fleet Manager will even work with your existing third-party Arc-enabled container distros.
-Now, beyond management, we’re also increasing the maximum scale threshold for AKS from 1,000 nodes to 5,000 nodes, and we’re also improving workload security with a couple of service updates. First, to ensure that your workloads can securely authenticate and access Azure Active Directory protected resources, we’ve enabled Azure AD Workload Identity for Kubernetes. Notice here how the service account name and namespace match the federated credentials subject identifier that we just saw. In this case, we’re protecting access to secrets in Azure Key Vault, and you could use this for any other Azure AD-enabled resource. And as you can see, this is a Kubernetes-native approach, where you don’t need to store secrets like connection strings and primary keys in your containers. This is now more reliable and easier to deploy wherever your clusters are running, and it also fixes scale and performance issues when compared to previous approaches. And lastly, to help mitigate a common pain point for managing container images, AKS’s Image Cleaner, which we’ve just released in public preview, can automatically remove unused and potentially insecure container images cached in your clusters.
-Now, to try everything out for yourself, start deploying your own AKS clusters at aka.ms/AKSQuickstart. You can also check out aka.ms/AzureArc to start a trial, and you get up and running quickly using our Jumpstart at aka.ms/AzureArcJumpstart. Of course, keep checking back to Microsoft Mechanics for all the latest updates, be sure to subscribe, and thanks for watching.
