>> Hello there and thank you very much for joining us
today in this new Azure Portal How-To video. Today we'll
learn about improvements to the portal experience that
will help you to manage your Kubernetes application.
And for that we have Jenna Netland, who's going to show
us all about that. So, thank you very much for joining
us, Jenna.
>> Yeah. Thanks, Leon, it's great to be back. I'm excited
to show you all the
improvements we've made, so let's
dive right in.
So, here I have a cluster that I just deployed. You may
already notice some updates to the experience, but the
one that I'm looking at today is the Kubernetes resources
section. This is a new area where you can actually view
Kubernetes resources that are running inside of your
cluster. We have things like namespaces, a variety of
workloads, including
deployments, pods, replica sets, and
more, and services and ingresses to help you out with
networking. Now this is not
a full set of services, but we're
going to keep adding more as we go through.
Today though, I want to actually add a new deployment.
So, I'm going to go to the workloads menu and I'm going
to click add. From here if I have a manifest file already, I
can just copy it directly into this editor. If I don't happen
to have a manifest just lying around on my desktop, I can
actually borrow the one from the AKS team, which is what
we're going to do today.
This sample application from AKS is going to give us four
pieces—a backend deployment; a backend service, which
will make sure our front end can talk to our backend; the
actual front end deployment to run the front end; and then
finally a front end service
that will make sure our front end
is accessible from the internet. I'm going to go ahead and
copy this and paste it right here into this window and hit
add. And here you can see we are, in fact, creating four
resources, two of which you can already see here. These
are the two deployments that I showed which are the
backend and the front end. And if I refresh, they’re
actually, already ready to
go. If I take a closer look, I can
actually see some basic
properties about this deployment,
and I can see the pods and even replica sets that are part
of it. There's more tabs that
we’ll explore a little bit later.
For now, let's go look at the services.
So, we expected two services and we should get exactly
two services. Here they are—a front end and a backend.
You'll notice something special about this front end
service, which is that it has an external IP address. This is
because we wanted our
application to be accessible to the
public internet, so we made it a type load balancer. If I
click this link, it'll take us to
our brand new application that
we just deployed where we can vote on whether or not
we prefer cats or dogs. So within a few minutes, we've
gone from having a brand new cluster to having our very
own sample application up and running. Now things go
pretty smoothly when you're using a sample application,
but we know that's not always the case in the real world.
So, we've also built in some debugging capabilities that
you can use to try to identify and fix any issues with your
application. This is supposed to be a web server that my
teammate and I are working on, and we're supposed to
demo it later today, so I really need to figure out what's
wrong and try to get this
fixed. It's running on this cluster
and from the looks of it this cluster is doing fine, so there
may be something that we've missed in our configuration.
I'm first going to check our service that's exposing this
application to make sure everything looks good. There's a
lot of services that are here by default, and I only want the
ones that are part of my team's namespace, so I'll go
ahead and filter this list. I'm checking and the external IP
addresses seem to match and Kubernetes is saying that
the service is okay. So, maybe it's something wrong with
our deployment. Let's go check on our deployments and,
once again rather than
looking at all the deployments, I
only want the ones from my team's namespace, so I'm
going to filter to just my team.
And it looks like something's wrong. So, let's go
investigate. If I open up that deployment, I can look at
again the details of this
deployment, but I can also see the
pods. And it looks like both pods are experiencing the
same issue, so let's dive even deeper. This seems like
there's something wrong with my deployment, but I'm
going to go into the pod to try to debug this.
From the pod view, I once again get a detailed information
about some of the different properties. I get another piece
of information about the status and why things might be
wrong. But in this case, I want to dive even deeper, so I'm
going to go into the list of events that have happened on
this pod. From here I can
see a record of different actions
that have been taken and whether or not they were
successful. This message in particular is standing out to
me as something that I might want to look at in more
detail, so by clicking on it I can actually bring up the full
response from Kubernetes with a detailed message about
what might be going wrong.
In this case, I'm getting a message that says the
repository does not exist, which could mean that I
mistyped my image name and it’s trying to reference
something that doesn't exist. And if I look at the image,
yep, looks like we found the problem. My teammate and I
were talking about this and I mentioned that we should
use the web server engine X. Unfortunately, this isn't how
it's spelled. So now that we know what's wrong, let's go
ahead and fix it. I mentioned that both pods were
experiencing the same error. So, it seems like this is an
issue that we should fix at the deployment level. So, I'm
going to go back to my deployment, and I'm going to go
ahead and go to this YAML tab. From here, I can see the
full definition of this deployment and I can even make
quick edits inline. So, here I can see where this error is
happening with this image name and I'm going to go
ahead and fix this to the correct spelling of NGINX.
I can review my changes to make sure that only what I
wanted to change is changed and everything else stays the
same, confirm them, and then save. My deployment will be
updated. Let's go see how that's going.
So, you can see that already Kubernetes is going to be
making some updates to these pods. The pods that were
broken were already being terminated, and my new pods
are coming up with the actual correct image. If I refresh,
everything looks good to go. So, let's go back and check
on our application. We're going to refresh it and perfect.
Everything is now back up and running. We’ll be good to
go for a demo later today.
So, today we've gone from having no application deployed
on our Kubernetes cluster to having an application up and
running, and we've managed to save our demo by making
a quick fix to our running Kubernetes application.
>> This is great, Jenna. Thank you very much for showing
us that.
And thanks, every one of
you, for watching. Please try this
out and let us know what you think. Leave us a comment,
follow us on Twitter, and look forward seeing you in the
next video. Thank you very much for watching.