ANTHONY BUSHONG: Welcome to "Bit by Bit,"
a series where we highlight one thing you can do to optimize
and potentially run a bit better in Google Cloud.
Today's topic-, optimizing to start workloads fast.
In GKE, the faster containers in a pod can start,
the faster your workloads can carry out whatever
it is they're meant to do.
Using image streaming in GKE Standard,
you can get containers up and running faster
in your GKE clusters.
So let's get to it.
[MUSIC PLAYING]
In this demo, we're going to compare
the speed of deploying the same two-tier app to two
different GKE clusters.
One is called utah-a with image streaming enabled,
and the other cluster is called utah-b
without image streaming enabled.
And they're both in us-west3.
The image streaming helps us start our workloads
faster because it signals for GKE to use a remote file
system as a root file system for our containers.
And this basically means that containers
can start well before the full image is
downloaded to the node.
And it basically streams in data from this remote file
system as needed.
Now each cluster here has zero nodes
because we want to ensure our demo environment is clean,
so that we're not taking advantage of any locally
cached container images.
So let's scale both of these clusters up to three nodes.
And because these nodes are new, they're
going to mimic the behavior you might see when auto-scaling,
an event in which it's critical that workloads
start as fast as possible.
And with those nodes now created,
let's see what else our demo environment consists of.
For each cluster, we already have a precreated service type
load balancer with an external IP.
And right now, these load balancers
are sending traffic to nothing.
But they will send traffic to our two-tier apps
once they're deployed.
And I wanted to have them ready so
that the time it takes to create fresh load balancers
is accounted for when measuring the time it takes
for our workloads to be ready.
And this is for many reasons.
Sometimes, workloads don't need load balancers.
And often, cases of autoscaling, load balancers
will already exist.
So we don't want to measure that today.
And now let's take a look at our container images
that we're going to deploy for our two-tier app that are
stored in Artifact Registry.
And now, for image streaming to actually work,
the container images that you deploy must
be stored in Artifact Registry.
And the repo that they're in must
be in the same region of your GKE clusters.
Or in the case of multiregion repos,
the region in which our GKE cluster is must be included.
And we'll include a link to all other eligibility requirements
in the description below.
But in our two-tier app, we can see that there are three
container images--
one for the front end, one for the database, and one
for the database follower.
Now out of the three of these images,
the front end or app image is the worst offender
in terms of the size, coming in at roughly 300 megabytes.
And we should see a significant improvement
in pulling this with image streaming versus without.
And of course, the larger the image,
the better performance gain we'll see.
Now without further ado, let's see all of this in action.
So we can see here we have our app manifest in the two
services that we already precreated.
In the top-right pane here, we're
going to run a while loop and issue
requests to the load balancer for the cluster
with image streaming enabled.
And then, in the bottom-right pane
here, we're going to issue a request to the load balancer
without image streaming enabled.
And so we're getting a 000 back as our connection is being
refused by both load balancers.
And when our two-tier apps have successfully started,
we should see a 200 for our HTTP code,
which means that our app is successfully serving requests.
So we're going to deploy the same app
manifest to both utah-a and to utah-b.
And we're going to watch which cluster's two-tier app starts
up first and gives us our 200.
And as expected, our top-right pane
has gotten 200's first, which means
that our app is successfully serving
the requests in the cluster with image streaming enabled.
And now, almost 20 seconds later, our app
is successfully serving in the cluster
without image streaming enabled.
And so we can get our pods.
And let's take a look at the details in our front-end pod
to verify that this time difference came
from the container image pull time.
So if we look at the front-end pods from the cluster
without image streaming, we can see it took roughly 24 seconds
to pull the container image.
Now if we switch kubecontext over to our utah-a cluster
and we get our pods, we can grab details
from one of the front-end pods.
And this is a cluster with image streaming.
Run the same describe command.
And we can see that this container image took a shade
under 3 seconds to pull, which is why our app in this cluster
started up so much faster.
The best part about GKE image streaming
is that it's a turnkey feature that
can be enabled in your cluster via the console, GCloud,
or in your infrastructure as code.
And as we can see here, we can use the console
to update our utah-b cluster to also
have image streaming enabled.
Using image streaming in GKE helps
you deploy faster and auto-scale faster,
all because your workloads can start faster.
As always, you can learn more in the links in the description
below.
And we'll see you in a bit.
[MUSIC PLAYING]