Hi, I'm Bill Maxwell,
Director of Product Management for
the Rancher platform here in Susa,
and I've been in the Kubernetes
ecosystem now for several years.
I've been with rancher pretty much
since the beginning and so bend
in the container ecosystem for
quite awhile and today I'd like
to talk about enabling consistent
Kubernetes cluster operations
across your environment everywhere.
And so today I'd like to talk about
consistent cluster operations and why
that's important for your organization.
As you embrace Kubernetes,
I'm going to talk about some of the
challenges and pitfalls you could run into,
and then we'll talk about a strategy
to implement to avoid those pitfalls,
and then we'll take a look at a
demo of a potential solution to
all of those challenges.
So why are we talking about
consistent cluster operations today?
Well,
as your organizations embracing Kubernetes,
it's probably to help you deliver
software to multiple different locations.
Whether you're using it as a strategy
to move from on premise to the cloud,
whether you're taking your applications
and moving them to your branch
offices or some smaller device,
you're going to run Kubernetes and you
want to be able to deliver applications
as quickly and safely as possible,
and so Kubernetes is a great tool for that.
But it does require some strategies,
as you embrace it to make sure
that it delivers on that promise.
And So what you're going to want
to do is stamp out each Kubernetes
cluster to be the same, right?
You're going to want your dev,
test, and production environments,
although look very,
very similar and have a very consistent
path from your development environments
to your production environments,
and so it accomplish that you're
going to need automation in place
to make sure that you're building
consistent clusters,
regardless of where they are.
And then you're going to need to have
operations elements for each of these
clusters you're going to have to upgrade.
You're going to have to.
Scale your Kubernetes clusters and
you're going to need to do backups in
the case something bad happens and you
have to recover from a previous state.
And ultimately,
because you're going to have
a lot of clusters,
potentially you're going to want
to have a single place to go to
to view that the health and the
status of each of those clusters
you're going to want that single
pane of glass in order to be able
to operate all of your clusters,
regardless of where they're running.
Organizations that are embracing
Kubernetes often have different
environments in which they run,
and they have different goals in
what they're trying to accomplish,
and so Kubernetes can run anywhere.
And so you just have to be able to.
Make sure that you're picking the
right solution for the environment
that you're operating in,
so you can be running Kubernetes
on premise or start there and
have it as part of your strategy
to deliver applications quickly.
You could use it to move to the cloud
and there you have different choices.
You could run your own
Kubernetes clusters on VM,
so where you could leverage the hosted cloud
providers managed Kubernetes services.
There's tradeoffs to each,
but both really viable solutions as you
go to the cloud, and then you might.
Experience so much success with Kubernetes
that you want to deliver applications
to even more places using Kubernetes
and so whether that's branch offices,
cell phone towers,
windmills, satellites,
the back of trucks with small
compute farms in the back,
Kubernetes is really going everywhere,
and so each one of them has a
different way of provisioning
and getting a Kubernetes cluster,
and so you're going to want to make
sure that as you embrace Kubernetes,
you have the tooling in place and the
operations in place to do the backups
and scalability and upgrading and a way
to just maintain those clusters overtime.
And so,
because Kubernetes can run everywhere,
you have a lot of choices when you
go to deliver Kubernetes in those
environments and in the ecosystem
there are 67 Kubernetes distributions,
48 hosted Kubernetes platforms,
and 21 different Kubernetes installers.
So wherever you're running,
you have options.
But if you go down this do-it-yourself path,
you're potentially becoming
an integrator yourself,
'cause you're going to need to
write automation around each
one of these provisioning tools.
If you're picking like a specialized one
for on Prem versus a managed provider,
you're going to need to have a
way to do backups.
You're going to have to do how are you
going to scale and all of this is doable,
but your operations teams are going
to be taking on more and more of an
operational burden on dealing with
these separate different processes for
building out these Kubernetes clusters.
And so as you're looking to run these
Kubernetes systems in multiple places,
you want to make sure that you're
focusing on solutions that will.
You kind of tie a few of them
together for you,
and so that you're not the one that
has to necessarily do all of the
integrations bids 'cause there's a lot
of choices and a lot of flexibility in
how you run these clusters everywhere
the CNCF ecosystem is booming,
there's lots of tools out there to help you,
but just keep in mind that the
more that you're doing yourself to
kind of glue these pieces together,
potentially the more operational
burden your teams are going to have.
And the other challenge is,
as you embrace different tools
in different environments,
you end up with sort of a fractured
view of the world.
You're going to the cloud portal to look
at your hosted Kubernetes solution.
You're going to your on premise
virtualization platform to look at
the VM health of those clusters,
and you're going to a Kubernetes dashboard,
which could be multiple view what's
going on in the Kubernetes clusters
and see if these different panes
of glass
that you need to.
You know, keep in mind and visit in
order to operate these clusters,
and it's also you know your end users
of the Kubernetes clusters are going
to need access to these systems.
And how do you manage who
has access to these?
These different environments potentially
adds a lot of overhead to your environment,
and then as you're automating
out these environments,
you know you're dealing with multiple
APIs and so each automation is its
own integration in its own effort.
So that's just something to keep in mind.
As you're going down this path of
running Kubernetes everywhere in your
environment that it's easy to end up
with with multiple views of the same thing.
So we've been talking about a few
of the pitfalls and challenges
of do-it-yourself solutions,
or running Kubernetes across
multiple environments,
and all of the available tools,
and how you would have to kind of pull
these together to achieve a consistent
set of operations for your Kubernetes
clusters in every environment that
you're going to be operating in.
So what I'd like to do now is talk
about a potential solution to realizing
consistent Kubernetes cluster operations.
So how do we achieve
consistent cluster operations?
We want to have that automation layer,
so we want to have something that
provides a consistent provisioning
API because you're going to most
likely be running on premise in a
virtualized environment or bare metal,
you're going to be running in the cloud
again with virtual machines or on a
hosted or managed Kubernetes solution.
Or you could just be running on a
small edge device in a branch office.
You know that's like a Raspberry Pi,
and so when you are doing that,
you're gonna want to have a way to
normalize the operation so you're
not writing a separate integration
for every location that.
You're going to be running in and
you're going to want something that
helps with the day-to-day operations,
and so a tool like Rancher provides
a consistent provisioning API,
an inconsistent distribution of
Kubernetes that enables you to
do backups and manage that all
through a single pane of glass,
which makes it very powerful in being able to
ensure that you're consistently deploying,
managing,
and operating your Kubernetes clusters
the way that you would expect.
Without adopting a lot of operational burden.
So now that we have clusters
across all our environments,
provision the way we want them to
backed up and scan for security in
the next layer up is how do we ensure
a consistent set of security policy?
How do we ensure a set of applications
are running on these Kubernetes clusters
to enable infrastructure as code or
Git OPS in the Kubernetes ecosystem?
And so a tool like Azure Arc for
Kubernetes really helps here because
it brings all of your Kubernetes
clusters to your Azure portal
and so if you've been operating.
In Azure,
for a long time this is just a
natural extension of the tooling and
operations that you've already got in place.
But for Kubernetes it also allows you
to apply policies to your clusters,
and managing that scale
it brings in getups tools.
So you can deploy your applications
in a consistent way across your
environment and it also gives
you a centralized control plane.
That single pane of glass to visualize all
of your clusters and the applications and.
Policy is being applied to them.
And so when you bring
the two stacks together,
they are quite complementary because
you now have a full stack visibility
of all of your Kubernetes clusters.
You have consistent policy applied
to each of them.
You have consistent set of automation
tooling that enables you to provision,
upgrade, scale out and back up all
of your Kubernetes clusters.
You can do monitoring and logging
of all your applications and your
Kubernetes clusters into Azure
and you get workload management
and consistent way to deploy those
applications through Git OPS.
And so now you have a fully automated
stack for your Kubernetes environments,
and you're able to just have this
nice consistent set of operations
and a consistent,
easy way to do things across
the Kubernetes environment.
And so now I'd like to take you
through a demo of what the solution
looks like and so we'll start
with provisioning in cluster.
We will upgrade that cluster through
automation and then we will take
a look at some of the operational
elements that are available to you,
and then we will add one of those
clusters to Azure arc for Kubernetes and
deploy an application to it through Git OPS.
OK,
let's take a look at a demo of installing
Rancher or installing a Kubernetes cluster.
Within rancher.
So here we're going to use Terraform
for as our infrastructure as code to
provision a new cluster on V sphere,
and so in the lower right hand.
Corner you'll see that I've got
the Terraform module.
Above is the web UI of the rancher
platform and on the left we're
going to do our Terraform apply.
Now I'm going to speed up the
replay speed as it takes awhile.
To provision.
So here behind the scenes,
what's happening is.
We're creating a node pool for the
rancher Kubernetes control plane.
An inode pool for the worker nodes,
and so all in total,
will have four nodes in this cluster.
We're provisioning and you can
see that we're pulling down
all the available images and
bringing new cluster up to speed.
Then the nodes are starting to
register and we've deployed our agents
so that the agent can register the
cluster back into ranch here now
that the cluster is gone active,
you'll see it is now able to
be used within Rancher,
and so you can perform operations on it or.
You take a look at what's
going on in the cluster.
So you'll notice here that
I've installed Kubernetes 117.
Now it's common that you'll want
to upgrade Kubernetes versions.
As they come out and so let's
go through what that looks like
on the lower right hand corner.
I'm editing my Terraform module so
that I can upgrade the Kubernetes
version to 118.
Now I will apply that through Terraform.
And you can see that as it's going,
it's now being applied.
The first thing that happens
is it pulls all the images,
it updates the control node,
and then it'll update each
of the worker nodes one at a
time to minimize the impact
to your running applications.
You can see it takes a few minutes
to do this, but it's still going
through and updating each one
of these nodes one at a time.
Hard so that they can be brought up.
You'll now see that we're
now running ranchers,
reporting Kubernetes 118,
and for that cluster.
Let's take a look at the live system.
And see what kind of operations we
can perform to edit this cluster.
And here you can see I've
created my two node pools,
one for the control plane and
one for the worker nodes.
And I can select different
Kubernetes versions and so I could
upgrade from here if I chose to.
But down here in the advanced
options you can see a few more of the
operational elements of the cluster.
Here I can configure my backups for at CD.
Right now we're taking local backups
that are reoccuring every 12 hours
and we're keeping six of them.
We can also back these store these
backups in an S3 compatible storage.
We can also then set up security scans
on our cluster so we can periodically
scan our cluster and ensure that
we are configured as we expect.
So within the confines of the CIS benchmark.
So these are just a couple of the
operational elements that you can do.
Other things like rotating the certificates
in the cluster are also possible.
And there's a lot that you can accomplish.
But let's take a look now at
registering a cluster into Azure Ark,
the first thing we're going to do is
register the provider for communities.
So we'll run a couple commands
and verify that we've registered.
So now we are registered with the Azure arc.
Next we're going to connect our
Kubernetes cluster to Azure Arc.
And so you can see I'm running
the easy command here.
And it's being connected in.
Now what's happening behind the
scenes is Azure is deploying
a helm chart under my cluster.
We're deploying some application to
connect it back into the Azure portal
so you can see I've created it's
created in Azure Arc Namespace an it's
done a few deployments into that.
Namespace to connect back in and control
different elements of the cluster.
So now we can take a look at adding
an application through Git OPS.
This is one of the more powerful features
of Azure Arc for Kubernetes is the
ability to deploy applications and ally.
Communities manifest through
infrastructure as code.
This is all doable from the Azure Arc portal,
and so we'll go through a demo
of that and so here.
I'm adding in the configuration I'm
going to pick it the namespace that
it's going to deploy the application to.
I'm going to get the URL.
Of our repository and set it to public.
I'm going to set it to cluster scope
and then add that configuration.
So you can see I can check some status,
I get a message from the cluster.
I refresh that and if I go to the cluster
and through cube control I can see that
I have a container being created in
the cluster config namespace as I said.
Now you can see that there's a few
deployments that are coming online.
And in a few moments,
we'll see that the cluster will
communicate back up to the Azure portal.
An register the application installed.
And so now we've seen here is an
application being you are the full stack,
are clusters provisioned and managed
and upgraded through one common
control plane through rancher.
And then we can use the Azure arc
for Kubernetes Portal to deploy
applications policy and other
things onto the cluster and so.
This is a really powerful set of tools
at your disposal and I hope you'll
take a deeper look on your own time.
So I just want to say thank you today.
We've talked about consistent Kubernetes
cluster operations and how we can
accomplish that using Rancher and Azure Arc.
If you have any follow up questions,
please reach out to Azure at susan.com
and we'll get back to you with an
answer is because we can thank you.