>> Hey, folks. Welcome to KubeCon,
2021 in Los Angeles.
I'm Chris, and I'm joined with Jonathan.
We're both on the Azure Team who
are implementing GitOps as a Service.
Today, we're going to talk to you in this recording
about GitOps and Azure Arc and AKS.
To level set, what we're going to talk about today,
GitOps is a feature that we're enabling in
Azure Arc enabled Kubernetes
and the Azure Kubernetes Service.
We decided to make GitOps as
a service within Azure because it adds
another great tool to
your tool chest for managing your Kubernetes clusters.
With GitOps, you can manage
the cluster configuration and
the applications in all of your Cloud and
on-premise clusters with the same GitOps service.
Of course with GitOps,
you get security, efficiency,
observability, and the ability
to manage at scale across all your clusters.
With the GitOps service,
the fluxations that we use are
automatically updated and monitored
so you don't need to worry about that.
You can also enable GitOps at
scale with the services like Azure Policy.
We also use the latest CNCF Flux in our service.
Just to tell you what's going to show up
in the demo that Jonathan's going to give.
One, we're going to enable GitOps with
Flux2 in Arc and AKS clusters,
we're going to create Flux configurations,
and each of those clusters
pointing to the same repo to show you
that you're going to get
the same results across your clusters.
We're going to then verify that the state that was
declared in your Git repos is
going to be reflected in the clusters,
and finally, do the status of
the deployment. Over to you, Jonathan.
>> Thanks, Chris. I'm going to get out of this and head
over to the Git repository that we're
going to deploy to the cluster.
If I pull out of this, this is actually a Flux2 example
that you can find under the Flux2 project on GitHub.
But here, we're going to be deploying
an infrastructure piece and an application piece,
so we have two directories
that store these different things.
Under the Infrastructure directory,
we have Nginx and Redis.
Within these, we're actually
deploying a Helm release object,
that is a Flux Helm release objects,
so we're applying a Helm chart to the cluster.
Both Nginx and Redis are these Helm releases.
Then at the top level under applications,
we're deploying this podinfo application,
which has a base,
and then it has a customization overlay,
which in this case,
we're going to deploy the staging customization to
overlay to this base podinfo application.
Now, let's take a look at the cluster and look at
this specific command that
we're actually going to use to do this thing.
Pulling up the command here.
Taking a look at this command that we're going to use to
apply this configuration to the cluster
to connect that Git repository with
this Azure Arc connected cluster,
we're going to use az k8s-configuration flux
to actually create this configuration.
Here, we're going to specify the
resource group that the cluster is N,
the cluster name, the name of
this configuration that I want to deploy.
Because this cluster type
is an Azure or connected cluster,
we're going to use connected cluster as the cluster type.
We're going to specify cluster scope because we
want to deploy configurations across the cluster.
But if you wanted to deploy configurations in
a specific namespace and restrict access,
you can specify this as
a namespace scope configuration, but here it's cluster.
We're deploying this in the known host namespace.
The URL is the URL of
Git repository that I just specified,
and then because this is an On-prem Git server,
as well as it's a private repository.
We have referencing unknown host file known
has public key of this On-prem server,
and the private key file
to actually connect to the repository itself.
Then here is a improvement from Flux v1 into Flux v2.
We now have this concept of customizations,
which are essentially paths
within the Git repository source,
specified up here that we can deploy too.
In this case, as I showed in the Git repository,
we're going to attempt to deploy
the infrastructure path and the app/staging path.
Then interestingly enough here,
we can actually specify dependency
between these two paths and these two customizations.
Here, we're going to say that
the application customization depends
on the infrastructure customization.
Here, if we go ahead and execute this command,
it will start running, and in the background,
it's going to deploy this
flux configuration to the cluster.
But now, we can take a look at the cluster as
it's already been deployed.
I've already gone ahead and
provision to Flux configuration already.
If we take a look at the pods on this cluster,
we see some pods in the flux system namespace,
as well as the Helm releases
that we actually want to deploy.
Here at the top level, all of
the pods within the Flux system
namespace are part of the Microsoft.flux extension,
which essentially is all of
the Flux components that you need
to deploy your configurations.
When you first onboard to a Flux configuration,
it's first going to deploy an extension,
which is part of the extension platform on Arc.
Then additionally on top of that,
to bridge that connection between
the repository and the cluster,
you're going to deploy a configuration on top of that.
We can actually take a look on
the cluster at the extension configs,
which is Azure Arc CRD.
If we take a look at the extension config here,
we see that we have
deployed the Microsoft.flux extension.
Then if we take a look at
the flux configs on this cluster,
we should see a known host Flux configuration
that is deployed from that
URL and is in a succeeded state.
Specifically, the Helm releases
that we wanted to deploy to this cluster,
we can take a look at those as well,
which are the Flux2 CRDs.
Here, we see that the Helm releases
that we wanted to deploy from
my Git repository have
successfully reconciled with this cluster,
and that is the reason we're seeing
all the pods and
the charts that we wanted to deploy to the cluster.
Now, let's take a quick look at
how we're going to do the same process in AKS.
We can actually take the same command that we used above.
This az k8s-configuration flux create command,
we can use this same command and make
a few adjustments to it to deploy to an AKS cluster.
Here, we see that we
have originally used connected clusters.
We'll change this cluster type to manage clusters,
which is the AKS cluster type.
Then additionally, we can
change the cluster name as well because we
need to point this to AKS clusters on this instance,
I am deploying to
this AKS extension test cluster
that I've already provisioned.
That's it, that's all we change.
We change the cluster name and the cluster type.
I press "Enter" and deploy this.
In the background, it'll run
and deploy this known as configuration.
Then taking a look at the cluster itself,
let's change the context here
to this aks-extension-test cluster.
If we look at the cluster here,
we'll see the same Flux system namespace pods
are here with the Flux extension.
Again, if we take a look at the extension configs,
we'll see the Flux extension is deployed here.
Then again, we have the Helm release is
deployed in the Nginx,
podinfo, and Redis namespaces.
If we take a look at the Helm releases,
they've also deployed in the reconciliation succeeded.
Here, we can see that it's
a very consistent single plane of
glass scenario between the two cluster types,
and there isn't a whole lot of change that has to
occur between the two to install
the Flux2 agents as well
as get your Flux configurations connected with Azure.
With that, I'll hand it back to Chris,
and go back into the PowerPoint.
>> Awesome. Thanks, Jonathan. In summary,
what Jonathan was able to show you is
how you can leverage GitOps within Azure.
GitOps as a service for
your Azure Arc clusters and
your AKS clusters using the same service.
With GitOps, then you can
manage the cluster configurations and
the workload deployments using
the declarative GitOps approach,
and you get a single management plane
in Azure for the observability
across all of these different clusters
into the status of the deployments.
For further info, you can look at
resources here on GitOps,
learn more about Kubernetes in Azure,
and check up more demos. With that, thank you.
>> Thanks.