we're going to talk about Azure Arc
with cooperation with Kubernetes
and what you can do with that when it comes to GitOps flows.
To set the stage, Azure Arc is really about
extending the Azure control plane.
If you think about it, Azure Resource Manager is
the operating system of Azure and what we want to do with
Azure Arc is to stand
or stretch that resource manager control plane.
The way you want to think about Azure Arc is really
about trying to bring all the resources and
all the things that you have deployed outside of Azure and bring
those into Azure to be represented as first-class citizens.
If you look the diagram that I have,
you're going to start on the left as the Azure customer,
that using all the tools that he's familiar with,
the SDKs, the API,
PowerShell, and the UI.
From there, he's going to go into Azure to enjoy
all the reach manifest that we have when it comes to environments,
automation, access and security, organization, etc, etc.
From there, we're starting to look at what you
have on-premises and in other Clouds.
We want to bring those resources that you already have in
your multi-Cloud strategy and what you
have on-premises and bring those into Azure,
and again, represent them as first-class citizens.
The way we are doing this is by using Azure Arc.
Azure Arc extend the Azure resource manager control plane
to represent those resources as first-class citizens inside Azure.
To be more focused,
today we're going to talk about Azure Arc enabled Kubernetes.
Currently, we have three offerings when it comes to Azure Arc,
we have Azure Arc enabled Kubernetes.
We have Azure Arc enabled servers,
and Azure Arc enabled data services,
and we have more coming announcing in these Ignite.
When it comes to Azure Arc enabled Kubernetes,
it's all about taking all the Kubernetes clusters that you have
deployed outside of Azure and connect those into Azure Arc.
By doing so, you are starting the process of fleet management.
You have all your clusters in a single pane of
glass and everything is in the portal,
so you can start managing it.
From there, you're going to show some configuration.
You're going to apply those configuration as GitOps configuration,
which is what we're going to demo in a second here.
The third thing is about operations and monitor.
What you want to do after you get all these clusters into Azure,
you want to start managing those the same way as you're
doing in other Clouds or on-premises.
We are offering you the capability to connect
those clusters into Azure Monitor for containers and start
managing the pods and the containers inside those pods
the way you would have done in other Clouds.
The fourth thing is about governance and security.
What we want to do by you bringing
all these clusters into Azure Arc enabled Kubernetes,
we want to make sure that you have a way
to keep a baseline for those clusters.
We want to leverage Azure policy, for example,
to make sure that you are using
trusted container registries or making sure that you have
ingress controllers deployed on all of
your clusters in a standardized baseline.
We also want to make sure that you have
role-based access capabilities that
coming from Azure Active Directory,
applied on those clusters.
These are the four bullets that really highlighting
the value prop of Azure Arc enabled Kubernetes.
Specifically today, what we're going to focus and in the demo,
we're going to show is what you can do with
Azure Arc enabled Kubernetes and GitOps flow.
We're going to start with four clusters.
As you can see, I have a GKE cluster deployed in Google.
I have an Azure Kubernetes service on HCI,
which is our new Azure flavor of Kubernetes deployment.
You can see more details later on in this presentation,
how to get started, and also in
other section as part of this Ignite.
We also have Elastic Kubernetes Service,
EKS, deployed on Amazon,
and a Rancher K3s cluster deployed on top of VMware vSphere.
From there, we have those clusters already connected to Azure Arc.
Those clusters are now
represented as first-class citizens inside Azure.
We're going to apply GitOps configuration.
We're going to have two configurations,
one on the cluster level and another one on the namespace level.
We're going to touch on that in a second here.
The GitOps configuration are responsible for
deploying the Flux operator and in our case,
also the Helm operator.
The Flux operator and the Helm operator together will
create a handshake with the Git repository.
The Git repository is where you have
your application and the cluster baseline,
and this is acting as the source of truth
for your application and configuration of the cluster.
Now, once the Flux operator starting to
listen into the Git repository,
it will go and deploy the application
that is part of that Git repository.
We're going to consider that application as version 1.
This is the source of truth and
the desired state for this application.
Then we're going to make a change of that application.
That change will initiate the flow.
What will happen is that Flux will pick up the changes that are
happening on the Git repository and from there,
it will go and perform a rolling update for that application.
This will be the version 2 of
the application in the new desired state.
Let's move on to the demo and let me show you what we have.
To start off the demo,
we have a resource group deployed.
In this resource group, we have multiple Kubernetes clusters.
The first two clusters that we're seeing are AKS clusters.
These are no different than the clusters that you
are familiar with that you are deploying in Azure.
The third cluster that we have is an AKS on HCI Kubernetes cluster
that is actually presented as an Azure Arc enabled Kubernetes.
Now, this is our new Kubernetes flavor
that we are announcing in this Ignite,
which I'm going to share more detail
later on in this presentation.
We also have three clusters that are deployed outside of Azure.
The first cluster is an EKS cluster.
This is a cluster deployed on AWS and you can
see that this is actually the cluster that we are using.
The second cluster is Rancher K3s,
this is a Rancher cluster,
a single node cluster that is deployed on top of VMware vSphere.
You can see here in my vSphere client
that I have the virtual machine that deployed
with that Rancher cluster and you can see
here that this is actually the cluster that we are showing,
which is deployed with version
118.6s of Kubernetes and the K3s operating system.
The last cluster, which is the one that
we're going to use as part of this demo,
is the Arc-GKE demo.
This is a GKE cluster deployed in Google Cloud Platform
and we're going to show a full GitOps flow on top of that cluster.
This is the cluster that we have.
We're going to come back to that in a second.
If I go to the GKE cluster,
what you will notice is that this is actually the GKE cluster,
and this is an Arc enabled cluster.
But I'm going to go here to the configuration,
which is the meat of our demo.
I have a couple of configurations
already applied on that clustered.
The first configuration is
an Nginx configuration and it's deployed on the cluster level.
The second configuration is the hello-arc configuration,
which is applied on the namespace level.
What we were doing with the GitOps flow,
we're going to target those configurations into a Git repository.
That Git repository is holding a couple of Helm charts.
We have one for Nginx,
because we need to expose
the web application into
the outside world with an external service,
and we have the hello-arc application.
That application is the one that
we're going to manipulate and show
a live GitOps flow happening on the GKE cluster.
I'll zoom into the Nginx one and you can
see that these are the parameters that this configuration has.
You can see here that I have
the Git repository that I'm using and the release.
We're going to go back to that in a second.
If I'll go to the hello-arc configuration,
you can see that we are targeting the same Git repository,
but here, we are also pointing to a different release Helm.
This is the prod release.
Why two configurations?
You have the cluster configuration.
This will represent the applications that
you want to get deployed on all of
your clusters that are now projected
as Azure Arc enabled Kubernetes clusters.
A good example will be service meshes or
Ingress controllers, security applications.
So you want them to be on all of your clusters.
The namespace configuration represent your application.
This is the actual application that you are
deploying on a dedicated namespace on your cluster.
The Git repository that we're going to
use is the one that you're seeing right here.
This is a simple Git repository
holding a demo application that we created.
This is the hello-arc web application.
It's a simple Node.js application.
If I go to the code here,
you will see that I have two Helm charts,
one for the hello-arc application and another one for Nginx.
But more importantly, we also have releases and this is what
the Helm operator that we mentioned
is going to leverage as part of GitOps flow.
The one that I want to show you, first of all,
is the Nginx one and you can see that this is
just YAML file representing the release,
and you can see that the namespace for
this one will be cluster management.
I'll go back to the prod release and this represent
the hello-arc application and you can see
that this will get deployed on the prod namespace.
Also, you can see that I have
one replica for this application and the message.
Let's go ahead and see what we have.
I'll go back to the Kubernetes cluster deployed on
GCP and let's see what we have here in terms of services.
We have a service here that was
deployed as part of the Nginx deployment
that went through the configuration
of the GitOps that we applied on that cluster.
Let's go ahead and select that external service.
To show this demo, I really want to show it in
three screens because we are showing a rolling update.
So it's better to show that side-by-side. Here's the application.
We already deployed that, it's already configured,
and I have this small extension right
here that will go and refresh
the page every two seconds because
we want to show the update in real time.
I'm also going to go and show
the pods that we have on the cluster management.
The cluster management is the one that's holding
the Nginx deployments and the pods of it.
Also, now, I will show you the pods
that we have in the prod namespace.
I'm going to add a watch flag because we
want to show how we are making an update on
the application and how is that going to
translate on the GKE cluster.
Let's go ahead and do that.
This is the same application that I
showed you before and I'm going to
go here to the Releases and into Prod,
and we'll make a change on that application.
What I'm going to do, I'm going to change the number of
replicas and I'm also going to change the message.
Today, we have hello-arc GitOps demo,
you can see that on the right and let's edit for Ignite 2020.
I'm going to go ahead and commit those changes,
which is equal to merge in production.
I'm going to go ahead and commit.
Let's see what's happening on the left side.
On the left side, you can see that
the pods will start the rolling updates.
The Flux operator is listening to
that Git repository and capturing the change, and in a second,
you will see on the right that
the message is also changing to the one that we just did.
Hello-arc GitOps demo for Ignite 2020.
Also, it will deploy
more replicas of that pods because we changed it from 1-3.
So in a second, you will see the method starting to bounce,
because the load bouncer,
the Nginx that is deployed on that cluster is doing its thing.
It's basically load balancing between the pods.
You can see on the left that here,
we already have the pods running,
and in a second here,
you're going to see that the application is actually changing.
There you go. Hello-arc GitOps demo for Ignite 2020.
What is it that we did right now?
We applied a new configuration on a Helm release,
the Flux operator with the Helm operator,
captured those changes, and updated the application in real time.
Hopefully that demo showed you what is
the capabilities that we have with Azure Arc enabled,
Kubernetes with GitOps configuration.
We showed you a demo on
GitOps configuration with Azure Arc enabled Kubernetes,
but how do you actually get started?
We have a Jumpstart repository that holds 30 plus examples,
including the demo that I just showed on how to get started with
Azure Arc enabled Kubernetes with
bunch of automation and scenarios,
bootstraps scenarios, day 2 scenarios.
So please, go ahead and visit that Jumpstart repository.
To get started with our new AKS on HCI offering, again,
our own flavor of
Kubernetes in Azure that we are announcing in this Ignite,
go to the link that you see on the slide,
and to know more about
Azure Arc for servers, Kubernetes, data services,
and the other Azure Arc offering that are coming,
visit the third link that you see on the screen.
Thank you, everyone. This has been a great way to show you
what Azure Arc enabled Kubernetes with GitOps is all about.
Hopefully you enjoyed the session and the demo.
I hope you will have a great Ignite and stay safe, everyone.
[MUSIC]