(bright intro music)
Coming up, we are going to talk about how you can bring
modern DevOps technique to actually deploy and manage
your applications running on Kubernetes clusters
in your hybrid and multi-cloud environments using Azure Arc.
I'm here with Jason Hansen, program manager
from the Azure Arc team.
Hi Jason.
Hey Thomas, really happy to join you today.
So Jason, we are here to talk about
Azure Arc enabled Kubernetes clusters
and how you can use that to manage applications
on top of that.
But first we have different organizations
and customers running Kubernetes clusters in Azure,
on premises, and in multicloud environment.
How can Azure Arc actually help us
or help our customers with that?
Yeah, that's a great question.
So, our customers are running applications,
infrastructure in lots of different locations.
It can be on-prem investments in your existing data centers.
It could be managed service providers
working with an ISV or systems integrator,
as well as running applications and infrastructure
on multiple clouds.
Now, what we want to do with Azure Arc is unlock the power
of the Azure platform and all of our management services
and really extend those capabilities
into those non-Azure locations.
And what that looks like for a cluster operator, Kubernetes,
that means you can register your Kubernetes clusters
with the Azure platform by deploying an agent.
It runs as a container in the Azure Arc namespace,
and those agents call into the Azure platform.
They establish a secure relationship with Azure
and allow you to see your Kubernetes cluster
in the Azure portal.
That cluster gets an MSI, a managed server identity.
It gets an Azure resource manager ID,
and as such can participate in the economy
of Azure services.
And by that I mean you can unlock capabilities
like Azure Monitor for containers, Azure Policy
for Kubernetes or Azure Defender for Kubernetes,
really giving you kind of full management capacity
from Azure to your Kubernetes clusters
no matter where they happen to be running.
So that means actually I can add Kubernetes clusters
which are running outside of Azure
and they kind of become a native Azure resource
and I can use the same management tools
for all my clusters independently
where they're actually running.
So this is great stuff.
Now, what does this actually mean?
So if I'm a, I spoke a lot to cloud architects
and if I'm a cloud architect,
how can I take leverage of that?
Yeah, that's a great question.
And I've got a little demo here, kind of in two parts.
The first is we'll walk through what it looks like
to connect a cluster to Azure.
And then second, once this cluster is connected,
I've got clusters spread all over,
how can I use Azure Arc enabled Kubernetes
to uniformly gain access to those clusters
to, say, interactively troubleshoot or debug an issue?
So let's go ahead and dig in.
All right, so starting from the Azure portal
I'm gonna go ahead and navigate to the Azure Arc center.
I'm going to add infrastructure and select Kubernetes
as my form factor.
Now by answering a few questions, selecting my subscription,
and a resource group, and giving this cluster a name,
and picking a region,
we're getting ready to tell the Azure platform
where this cluster is coming.
Now as an Azure resource, I can also use tags
and the platform generates a script around that
using the Azure CLI to onboard.
Now I'm gonna go ahead and switch to my terminal.
I've got local access to this Kubernetes cluster.
And I'm going to use the Azure CLI to go ahead and onboard.
Now, by running AZ connectedk8s connect,
the CLI command accesses the local cluster,
accesses Azure, and then deploys the agent,
connecting the two pieces together.
Now as this agent starts,
it's running as a standard Kubernetes workload.
So it's an operator in the Azure Arc namespace
and as a Kubernetes developer or a cluster administrator,
I can use all of my existing tooling
to interact with this agent.
So it should feel very good Kubernetes native.
Now this connection has been established
and the cluster is up in the portal.
And in the portal, we can see the name
and basic metadata about the cluster.
Now you mentioned that there's obviously more to it
what I can do now with that cluster, right?
Yeah, exactly.
And now that the cluster is attached,
if I want to be able to request access to that API server,
since I've got clusters everywhere
under different networking configurations,
it can be really difficult to access the cluster
and and use those native Kubernetes tools.
So we have a feature in the platform called cluster connect.
And what this allows you to do
is to use Azure role-based access control
and Azure Active Directory to allow your operators
or your developers to access the API server.
In doing so, you can request a secure connection.
It's authenticated, again, using Azure Active Directory.
And the transport to that cluster
is carried over Azure Hybrid Connections,
ensuring that you've got a secure end to end connection.
So let's go ahead and see what that looks like.
Now, I'm in my console
and I'm running AZ connectedk8s proxy,
which sets up the proxy, again,
authenticated through Azure Active Directory.
And then at the top of my terminal,
I'm using standard Kubernetes tools to access the clusters.
So listing cluster information,
navigating and listing the resources.
And the nice thing about this
is that since we're using standard Kubernetes mechanisms,
any tool that uses a kubeconfig can work.
And so here we're using k9s,
which is an interactive tool to navigate
and troubleshoot in a Kubernetes cluster.
And here, I'm going through the Azure Arc namespace
and looking at the workloads that are deployed
as a part of the agent.
And this is a great building block for native access,
but can also compose on top of other CI/CD pipelines
that you might have or other troubleshooting, monitoring,
and debugging tools that you have
in your broader Kubernetes ecosystem.
Okay, this is pretty cool
because this will obviously make a lot of IT pros
and developers very happy
that I can actually use these tools
and I can actually take advantage of the Azure control plane
and Azure Active Directory to get that role-based access
and using that proxy to actually run commands
on these clusters without needing to think
about network connectivity like VPNs and stuff like that.
So this is awesome.
So speaking of developers,
one thing which also is one of the challenges we see often
is now I obviously want to deploy applications
to these Kubernetes clusters.
And again, they can run in multiple places.
They can run at retail stores, branch offices, and so on.
So this can also make it very tough for me
to actually deploy these applications
to all of these clusters.
Can Azure Arc help me with that as well?
Yeah, that's a great question
and I think you've really nailed one of the challenges
that customers have
as they continue to scale their infrastructure.
And that's really, you know, I've got lots of these things
running in lots of different locations.
How do I make sure everything is up-to-date
and configured appropriately?
And really with Arc, there are two pieces
that we can really pull on.
One is that we can use a GitOps based workflow
to take configuration from our cluster operators
and application configuration from our development teams
and apply that configuration to one, 10, or even hundreds
of Kubernetes clusters.
The GitOps workflow makes sure that those clusters
are kept up to date and our developers
and our cluster operations teams use a Git-based workflow
to add, update, or delete resources from those clusters.
Now we can pair that with Azure Policy,
and the power that comes from this is that we can use
the Azure Policy framework to, say,
all right, I want my infrastructure
in these subscriptions or these resource groups
to always have these applications deployed
or to always have these cluster configurations applied.
And Azure Policy will monitor
the entirety of our infrastructure by Policy
to ensure that everything is kept up to date.
And so what that means is as a cluster registers
with a platform or de-registers with a platform,
or as those policies change over time,
we can get a single place to go view
that all of my clusters are configured appropriately.
And if any of those clusters should drift,
either by configuration, GitOps will repair that cluster,
or by policy, Azure Policy will alert
and drive remediation activities, all again from Azure.
I love how we can actually combine it
with our native Azure capabilities
and then connect resources wherever they are running.
Can you show me that in a quick demo?
Yeah, let's go ahead and dig in
now that we kind of understand very high level
what what GitOps and Policy are doing.
Let's go ahead and start in the portal here.
And I've got a cluster that we have attached
to the platform.
And we're gonna go ahead and navigate to the GitOps section
for this cluster on the left-hand side, you can see GitOps.
In here that we can see that I've got two configurations
attached to this cluster,
one for a security baseline,
which is across the whole cluster,
and a second configuration team application here,
which is focused just on my application team
and dedicated to, or deployed to a specific namespace.
Now let's go ahead and take a look
at what this Git repo looks like
for this specific configuration.
Here, we're in GitHub and we've got a repository
with all of the resources that we need for our application.
And in this case, it's pretty simple.
It's a service and a deployment.
And as you can see,
it's standard Kubernetes manifests material
that lives in this repository.
Any valid Kubernetes resource can be deployed
by our GitOps system.
As well, since this is a Git-based workflow,
if I want to change or update something,
like for example bump an application version,
my team does it by opening a pull request.
Now the power of this means that I can also back
this pull request with GitHub actions, for example,
where I can check the validity of the manifests
or I can assert business logic
in terms of CI testing and rollout.
As well, the conversation around this poll request
can all be tracked here in Git.
So let's go ahead and take a look at this application
as deployed in my Kubernetes cluster.
And we'll go ahead and merge the pull request.
Now this pull request is merging
and the GitOps system deployed to all of our clusters
are monitoring this repo for change.
And once the change is detected,
configuration will be updated in the cluster.
And here we can watch the application rollout
to the latest version.
Now the power of this is that it's not just one cluster,
but it can be 10 or hundreds,
meaning that the configuration is staged, tested,
and when merged, begins rollout across my infrastructure.
And there are lots of knobs and dials under handles
that you can pull on in terms of how you structure
that rollout for safe deployment in terms of regions, rings,
repos, branches, a lot of flexibility here,
which means we can generally tackle
any of your business requirements
around a deployment pipeline and workflow.
Now, from an at-scale scenario,
coming to the portal and configuring
all of these configurations manually
is probably going to let a few slip through the cracks.
So as I mentioned before,
let's use the Azure Policy framework
to define what I want my clusters to look like.
So here, we've got a policy that says,
hey, any cluster that's attached to my infrastructure
needs to be running that baseline secure configuration.
And we can assign an additional policy
for that team-based application
by navigating, selecting the appropriate policy,
and configuring it appropriately.
Again, this config and all of these requirements
are given to the Azure Policy platform.
As clusters come and clusters go,
the Azure Policy engine will kick in
and deploy the applications and configuration,
or if those applications and configurations are removed,
alert and allow cluster operators and owners to remediate.
Again, giving you a single pane of glass to make sure
that all of your stuff is kept up to date.
Okay, so this is super awesome,
especially if I need to manage my clusters
at a certain scale, but also, I mean even if I have
a small amount of clusters, I can still take advantage
of this to actually manage all of that.
I like the way we can actually go in
and not just to apply the GitOps,
the policy for the cluster configuration,
but then actually use Azure Policy to make sure
that they're actually assigned.
So whenever I join a new cluster,
it automatically goes into that configuration.
It automatically gets all the application configurations
and so on.
And then I guess soon as I remove a cluster,
obviously this is just gone.
Really, really cool stuff.
Now for me, obviously I want to learn more about this.
So where can I find more about that?
Yes, great question.
So we have a number of resources to help folks get started.
I would say the first place to start
is our documentation site.
So Azure Arc enabled Kubernetes doc tree
has a number of quick starts, concepts guides
to get you started.
The second is the Azure Arc jumpstart repository.
And this is really focused at folks
who want to get up and running very quickly
with the demo environment so they can kick the tires.
And we've got a number of scenarios documented there
including stuff like Terraform scripts that allow you
to help you provision a cluster,
and again, attach it to Azure.
Last but not least, we have the MS Learn modules
that really take you from zero to hero
to get additional knowledge in this area.
Okay, this is awesome.
Thank you very much, Jason.
And for you watching, if you want to learn more
about hybrid and multicloud architectures,
check out our cloud adoption framework
at the Azure Architecture center.
(vibrant outro music)