(bright music)
- Hi everyone,
and welcome to a brand new skilling video.
Today we're going to be talking about,
a quick introduction to running stateful workloads
with Kubernetes on Azure.
My name is Vybava Ramadoss, and I'm a program manager
on the Azure Storage team.
On the agenda for today, we're going to be covering
a quick introduction for running stateful workloads
on containers.
We're then going to jump into the different storage options
that we have on the platform and your considerations,
as you think through your workloads.
And then we're going to cover
a number of recent announcements
on the platform, and then jump to a demo
to see some of the latest capabilities on the platform.
With that, let's get started.
Azure offers a plethora of options for running containers,
including services like Azure Kubernetes Service,
which offers simplified cluster management,
Azure Red Hat OpenShift, which provides you
a fully managed OpenShift environment.
Azure Container Instances, to elastically add virtual nodes
when your traffic spikes, as well as
our cluster API Provider, that allows you to run
a fully custom Kubernetes environment.
Kubernetes also has a rich and vibrant community,
in which Microsoft is a key contributor.
We work extremely closely with the other members,
to build great technologies with the community
and bring these open source technologies to you, our users.
Over the last few years,
we are seeing a significant increase
in the stateful production workloads that are running
at scale with Kubernetes on Azure.
These include workloads like databases,
including Mongo DB and MySQL, big data applications
like CassandraDB, machine learning workloads,
including Apache Spark or Kubeflow,
as well as a plethora of other applications
like messaging, CICD Systems or CMS Technologies.
These workloads leverage different types of storage
on the platform, including block, file,
or object storage options that can be leveraged,
using CSI drivers that are deployed
and configured in the Kubernetes environments.
When it comes to stateful workloads,
there are a few key considerations.
First up, reliability and availability.
It is super important for you to ensure
that you have data durability when it comes
to your production workloads.
With Azure, we offer a 0% AFR guarantee,
meaning that we never lose customer data.
Next up, performance and scale.
We offer a number of different storage options
that allow you to maximize your performance
for your IO intensive workloads,
and this could include IOPS and throughput,
as well as do this with sub millisecond latency.
Next, simplified management.
We offer you a very simplified and integrated way
for you to manage your applications,
including integrations for scale, monitoring,
as well as data resilience and protection.
We allow you to take snapshots and restore these snapshots
to your environments to ensure
that you always have data recoverability.
And last but not least, we offer built-in security options
that allow you to ensure that you have encryption,
not just in rest, but also in transit.
We allow customers to bring their own key,
so you have complete control on the encryption
in the environment.
Now, Azure Storage provides cloud storage that is durable,
highly available and massively scalable.
We offer a range of storage services
that can handle any of your data needs,
so you can choose the storage that best meets
your workload needs.
Here, you see the different storage options
that you can leverage with your stateful workloads.
If you're running a high performance database
or a big data application, you can leverage
our block storage option with Azure Disks.
If you're looking to create shared or user workspaces
or run a CMS system with a shared access,
Azure Files is a great option.
If you are running an analytics workload at a high scale,
or an HBC based application, you can leverage Azure Blobs
through a blob fuse or NFS based end point,
within your container based application.
And last but not least, if you're running
a high-scale custom application on NetApp,
you can leverage Azure NetApp Files
with your Kubernetes environments on Azure.
In addition to this, based on your workload requirements,
you can choose from different options,
improving static and dynamic provisioning options,
as well as different access modes,
whether it's read-write ones or read-write many.
We have announced a number of key capabilities
on the platform, that can really enhance
your container storage experience on Azure.
First up, we've announced the general availability
of the CSI drivers for Azure Disk, Azure Files,
as well as Azure Blobs.
We enable you to take volume snapshots,
as well as volume cloning, as part of these drivers
so that you can always have data protection and resiliency.
In addition, we also announced the GA
of our ZRS disc capability that allows you to deploy
a high availability application
that can handle zonal failures.
Next, we've enabled our larger file share options
with Azure Files, as well as announced a price drop
on Azure Premium Files.
This can really help you run production scale applications
with Azure Files.
Next we've announced NFS options for both Azure Blobs,
which is currently in GA as well as Azure Files,
which is currently in preview.
Now let's take an example of one of our announcements,
with zone redundant disks.
Zone redundant disks,
ensure that your disc persistent volumes
are synchronously replicated across three different zones
in any particular region on Azure.
This means that if you're running a multi zone AKS cluster,
your application will always be able to use
the persistent volume, independent of whichever zone
it's running on.
This means that if an entire zone is unavailable,
your application will still be available.
This works great for applications that don't really have
an app level of synchronization, and so you can now rely
on the platform to do the replication on your behalf.
This is now available with Azure Disk CSI driver in GA,
and can be used with a premium SSD and standard SSD skews.
You can try this now in four different regions on Azure.
With that, let's take a look at a demo
of the ZRS disc capability.
What you see on the screen here is that we've deployed
a Kubernetes instance, running on Azure,
and this is using the version 1.21.
Now, when we look at the storage tab,
we see a number of different PVCs that are running
in the environment,
associated with different stateful applications or pods.
We're going to switch over to workloads
and look at the stateful set that's being deployed
in this environment.
This specific stateful set has a pod,
and that has a corresponding persistent volume.
Now we can also see this on the command line
by issuing kubectl get PV,
which allows us to see the different PVs in the environment.
But we can see that this specific PV is configured
in the context of the stateful set and it's deployed
with the ZRS storage class.
Now just taking a look at this specific disc,
let's take a look at this in the portal.
So this disc, as we see is a standard SSD ZRS Disk,
which is configured with this application
and it is currently running on the VMSS node three.
We also see that the pod in the environment
is running on the same node as we expect.
Now, what we're going to do is we are going to issue
a drain on this node, so that we can then see
what happens to the application.
Now, when we issue a drain on the node,
it cordons off that specific node,
and then Kubernetes will move the pods
and any applications that are on that node,
in this case, node three, onto a different node
in the cluster.
Now, when we look at the different nodes in our node pool,
we see that we have a few different options here,
which include node two, three, and four.
And so since we actually did a drain from node three,
we will expect that the pod and the application
will show up either node two or node four.
Now let's give this a couple of minutes.
So here we see that the actual draining process is complete,
so let's go back to our workload and our stateful set.
Here we see that the container creating status
has changed to container creating,
meaning that the application's actively being moved.
And so when we look at this application and this pod,
we see that this is now on node four,
which is sitting in a different zone in Azure.
What we also expect to see, once this pod is actually up
and running, is that the volume
that was configured alongside this application,
which is basically the PVC with standard SSD ZRS
will also be on node number four.
We'll just give this a couple seconds to refresh,
make sure that our PC is actually up and running. All right.
So we see that this is live.
I'm going to refresh that page.
And there you go, it's actually, as you expect
on node four as well.
So what you've really seen here is that when you create
a multi-zone AKS cluster and you deploy an application
with a ZRS Disk configured,
independent of where your pod is scheduled,
whether it is on node one, two, or three,
your disk PV will be available to you to leverage
on that specific zone.
And there you have it.
With that, let's jump over to talk about
our partner ecosystem.
On Azure, we are deeply integrated with partners
that offer a number of different capabilities,
including core container storage
and container storage management,
as well as data protection and disaster recovery solutions.
We work extremely closely with these partners
and have integrated solutions on Azure for you to leverage
with your production workloads.
With that, thank you very much for your time
and for joining us today,
with this digital skilling session,
please check out our links to learn more
about container storage on Azure,
as well as please take our survey so we can continue
to improve our platform.
Feel free to reach out to us in case of any questions
and for any references to our net new features.
Thank you once again and have a great day.
(bright music)