(bright music)
- 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.
(bright music)