MARK MIRCHANDANI: All right.
Just set it down right over there.
Yeah.
ANTHONY BUSHONG: I'm exhausted.
MARK MIRCHANDANI: You said it.
Building all of these applications is tough work.
I don't know what I'm going to do
when they need to be stateful.
ANTHONY BUSHONG: You know, Kubernetes on Google Cloud
Platform is a great way to host stateful applications
with high availability.
MARK MIRCHANDANI: That would save me a ton of headaches.
ANTHONY BUSHONG: Sounds great.
Let's jump in to a demo and show you how quickly
we can get this all set up.
[MUSIC PLAYING]
Let's start with an application running
on GKE that requires state.
A simple example would be the popular blogging platform,
WordPress.
So this is our WordPress architecture
as represented by Kubernetes Objects.
We have two key pods--
the WordPress pod, which runs a WordPress
container, and MariaDB pod, which
runs the backend database.
Both of these pods are controlled
by deployments and replica sets which can be scaled up.
Kubernetes services give us a stable method
of accessing these pods no matter the count of replicas.
The MariaDB pod is fronted by an internal service, type cluster
IP, while the WordPress pods are exposed
to the public via an external service type load balancer.
This is where we want to focus our demo today.
Both of these pods require state.
WordPress needs to store assets in its file system and MariaDB
stores post and user data.
So we have a storage class that defines
the type of persistent volume that each pod will get.
In our case here, we will want to create a storage
class for the regional persistent disk.
Each pod will then have a persistent volume
claim for their respective persistent volumes.
Now let's take a look at how the world worked
before regional persistent disks were available.
Let's start with a single zone GKE cluster.
In this case, we have GCE persistent disks
scoped to a single zone mounted to the nodes
where our pods are running.
If there's any level of failure on these nodes,
we're fortunate to have Kubernetes Self-Healing kick
in.
These pods will migrate to healthy available nodes,
and the disk, due to persistent volume claims,
will be able to migrate to the new nodes, retaining
state for our pods.
All is well.
But this isn't everyone's setup.
More and more, we're looking for reliability
in our applications, which means we
want to spread across multiple failure domains.
So in GKE, customers are adopting regional clusters,
which means that control plane is replicated
across multiple zones, as are the nodes that the applications
run on.
In this demo, we will have nodes running
in us-west1-b and us-west1-c.
With the persistent disk scoped to a zone,
we'll run into issues to get the high availability we desire.
If there is a zonal failure, pods
will continue to migrate to a different zone
with healthy nodes.
But, because the persistent disk is scoped to a single zone,
the state cannot follow.
Enter regional persistent disks.
In the same scenario, we can now migrate the state
to a different zone as it was being synchronously replicated
by the regional PDs.
Let's jump into the demo and see it in action.
So here is our regional Google Kubernetes Engine cluster.
It's running in us-west1, with nodes in zones b and c.
Let's use Kube Control to actually look
at the pods, deployments, and service objects
that comprise our WordPress application.
So as you can see, we have one of each pod for WordPress
and MariaDB, and we also have an external load balancer
fronting the WordPress pod.
So if we actually throw that into the browser,
we'll see our WordPress blog, and it's titled, "Hello Take5."
We'll see that if we dive into the blog section,
we actually have one blog post titled, "Nice Blog, Take5."
And so we can see that our state is actually
stored on the persistent volumes mounted to the MariaDB
and the WordPress pods.
And we can actually use Kube Control to look
at those objects as well.
So we'll look at the persistent volumes, the persistent volume
claims, and the specific storage class that defines
the regional persistent disk.
So we can see that our claims actually represent
bounded persistent volumes.
And if we actually dive into and describe our storage class,
we'll see that we've created a very specific type
for regional persistent disk.
We'll see here, defined in the parameters,
that we have replication, type regional persistent disk.
We'll see that it's a persistent disk standard.
And it's running in zones, or it's
replicated across the zones us-west1-b and us-west1-c.
So now, we will want to see the high availability in action
with regional PDs by simulating a zonal failure.
This script, titled "Big Red Button,"
has a command at the end that will actually take out
one of the zones where my nodes are
running for this GKE cluster.
So once I execute that script, the script
will actually identify where both the MariaDB
and the WordPress pods are running.
So now we see the actual node that the pod is running on,
and we see that that node is located in us-west1-b.
And so we are now going to simulate that failure
in us-west1-b, and we will have to answer yes to that prompt.
And now we will perform a watch to see what actually happens
with our pods when they are moved into the node running
in us-west1-c.
OK?
And now we've actually sped through the zonal failure
to see that our pods have successfully
rescheduled from the node in us-west1-b
to the node in us-west1-c.
Now, to see if state actually followed into the new zone,
let's jump into our WordPress blog.
So if we refresh the page, we actually
see that our blog is still there with the same title.
And let's look at that blog post.
"Nice Blog, Take5" is still present,
and nothing has changed about it.
MARK MIRCHANDANI: Great.
So we can see how easy it is to use Google Kubernetes
Engine to host stateful, highly available applications.
ANTHONY BUSHONG: Absolutely.
Don't forget to like, comment, and subscribe.
MARK MIRCHANDANI: And if you'd like to get in contact with us,
click on the link in the description.
[MUSIC PLAYING]