[MUSIC]
Hi, I'm Scott Hanselman, it's Azure Friday.
We're here with Brendan Burns, and we're talking about Kubernetes.
We did a video before, a little 101 on creating a Kubernetes
cluster with Azure Container Service.
Let's dig in a little bit more and talk about how you would use and
maintain certain entities on Azure.
>> Sure, absolutely.
So I wanna start, I have a little very simple Node.js application here
in Visual Studio code.
Visual Studio code has really become my go to.
I'll close the terminal here.
It's really become my go to editor.
It's really great for a bunch of different things.
>> Mm-hm.
>> And I've taken this application and I built a Docker container out
of it, pushed that up to the Docker hub.
>> Mm-hm.
>> And now I'm running it inside of Kubernetes.
So if we go over here to the Kubernetes command line,
I can say kubectrl get pods.
So pod is that container.
It's kind of a whale joke.
Docker has sort of a nautical theme.
So there's my, there's this container running.
>> Mm-hm.
>> And what I've actually done here is, I can say get services.
And so what you'll see here is I have simple node service right here.
And that's actually a load bouncer that is load bouncing traffic down
onto that container.
Now there's only one of them right now.
What's also happening is,
when I created that service it's actually integrated with Azure.
So, it's created that external IP that you see there.
That's an Azure load balancer.
That's out on the pubic Internet, right?
>> Is that a special Kubernetes brand, or-
>> [CROSSTALK] No, Kubernetes calls
into the Azure API to create that load balancer for you.
So you can use the Kubernetes command line.
Say, I wanna expose these pods to the Internet.
Inder the hood, it'll set up the load balancer for you, and
just puts it out there for you to see.
So it's super easy- >> [CROSSTALK] That's a really nice
example, like a piece of open source software.
And Azure Cloud work well together and know about each other.
>> Exactly, and it has done a really good job, and I should say we've
done a bunch of work to make that integration work really seamlessly.
>> Yeah, it's very seamless, yeah. >> Exactly,
we don't wanna have this weird jenky,
it's the Kubernetes native experience, and then the Azure, no.
You want to have it be the native experience.
>> Yeah, it doesn't feel bolted on.
>> Exactly and it feels natural.
And actually, it feels magical at some level, right?
You were in this world and
you didn't even know it was connected to the Azure world.
And suddenly like it just it.
And so if we go over there, I can take the IP address here.
How about that?
>> You just hit Enter.
>> Yeah, I'm still learning- >> Still learning.
>> I'm still learning Bash on Windows.
>> Still learning on the dark side.
>> Yeah.
>> We'll talk later.
>> All right, yeah, I'm sure I should watch more of your videos.
I would learn all sorts of things.
>> Yeah, anytime I can avoid using the mouse.
Was it port 8000?
>> Yeah, that's right.
So there's the simple node service.
And I think what I want you to note is this host name that's right here.
>> Okay.
>> And so- >> Is that a generated host name?
>> That's a generated host name, right?
And so what you'll see here if we go back over, let's say that, we were
talking earlier about how sometimes things get busy at a service and
you just scale up.
Well, you can actually just say kubectl scale.
All right, and so at this point I've scaled up my deployment and so now-
>> Does that kick off a thing and
take's like five minutes and then the thing will scale up?
>> It kicks off a thing but, it doesn't take five minutes.
So now if we go back over here, let's say pods and
there's five of them.
And you can see two of them are now running,
three of them are in creation.
>> If you do it again- >> So they'll do it again.
Getting there hopefully.
We'll keep our fingers crossed.
So what's happening here is that
that container's being pulled down over the network.
So usually if it's slow, it's because-
>> [CROSSTALK] Cuz it's
coming from the docker hub.
>> It's coming from the docker hub.
It's coming down over the network onto those machines.
>> Okay.
>> So at that point, hopefully.
Keep my fingers crossed.
The one that came up fast I think landed on the same machine or
it had already been pulled.
>> Right, because I'm not thinking about the underlying
virtual machine.
>> Right, we're not really thinking about it.
And the scheduler is responsible for spreading them out, right?
Cuz you wanna make sure that if one machine fails or crashes or
whatever, like- >> [CROSSTALK] That's a very good
>> The load gets spread around
machines that doesn't so- >> [CROSSTALK I would not want six
of these or five of these on one virtual machine.
>> Exactly, right? You wanna spread them out.
And also because,
of course, you wanna minimize the load on the processor.
So now we're up to three.
The other one's popped in.
>> So this one is probably on another virtual machine.
>> Yeah, almost certainly, and we can actually find that out.
If we say -o wide, what you can see here is,
there's the machines that they're on.
And indeed, and now they're all running, right?
>> Yeah, but they're all running, and you were right.
The one that came up fast on the same virtual machine-
>> Yeah, exactly, so
those are on the same virtual machines.
And so you can see the nodes that they're running on there.
>> It's kinda nicely spread out.
>> Right.
>> That's amazing that you just brought up five web servers
like that.
>> Right, exactly, and they're, and they're spread out.
And the load balancer now is talking to all of them.
One of the cool things that, that you can do here is actually
I can actually run a proxy for the entire API.
Let's suppose that I don't actually wanna expose my service to
the Internet.
It's an internal service, it's not secured you know, but
I need to poke at it for debugging reasons for example, right?
>> Right. So I can actually
say q control proxy right here.
And what this is gonna do is this is gonna create a local running
web server.
And I can actually go up and I can start poking at it.
So I can say 120.
>> So you just tunneled from your local machine to-
>> [CROSSTALK] Yeah, so
I could say http:// 127.0.0.1/ and then I have to actually walk in.
So you're gonna actually see some of the under the covers.
>> Right.
>> We say /api/v1/namespaces/default/services- /simple-node-
>> This is a rest front end on your-
>> This is a rest front end on-
>> Close.
>> I need port 8001 >> Okay.
>> All right, so there's that same thing.
Now it's tunneling through, right?
Now it's not going through the public Internet.
It's tunneling down to the my local machine.
That means I can poke at that.
I can debug it for my local machine.
I could even set up run my client code on my local machine.
Connect through that proxy without having to worry about the security
of putting it on the public Internet.
And indeed, if you hit refresh a few times,
you'll see that that host name is changing, right?
We're moving between the various replicas in that service, right?
>> Wow. >> So that's the load balancer going
across all of the different replicas that we created.
>> So when you have this kind of control and this kind of speed,
when I can bring up five of something in less than a minute,
does, it really is up to me as the architect of the application.
Like if we talk about the example in the previous introduction video,
I had a product service and a shopping cart service.
That might be enough.
>> Right. >> But I could really go microservices
>> Yeah.
>> Off could be a thing and image serving-
>> Exactly, yeah, yeah, yeah.
>> It's totally up to me, right?
>> Exactly, definitely.
And I think the other thing you'll find is that over time you'll figure
out where the boundaries should've been, right?
And you'll split things apart, right?
>> Mm-hm.
>> It's kinda like the old analogy of not paving the sidewalks and
just waiting to see where people walk.
>> Mm-hm. >> Like over time you'll see how you
should split your service apart, and I think that's what we see.
You maybe start with two, and
then you realize that that one piece really should be two pieces.
You break it apart, you have three services, so on and so forth.
>> But if changing it takes a minute.
>> Exactly, no, exactly, and you can iterate through that change, right?
So you don't have to just destroy a bunch of machines and
create a bunch of machines in order to create the new thing.
You can sort of slowly bring up the pieces that you need on the service.
>> So I have two questions.
>> Sure. >> How do I know how many machines
I needed?
How do I know if my thousand containers have filled up those
machines?
So I guess I'm wondering
how do the containers know when I need more containers?
And how does the ground beneath them know that there's not enough ground?
>> Yeah, so we can actually say there's a command here,
we can say cube control top.
What was that?
This shows we can say cube control top node.
And what this is gonna do is, this is actually gonna tell us.
This is how much CPU, we're only using 2% of the CPU right now.
This is how memory.
We're using 21% of the memory over here.
So this actually gives us exactly that view of what's the overall,
if I'm a cluster administrator, what's the overall need?
Cuz I think we really think that those two roles are gonna become
separate.
Where there's a person who's responsible or
maintaining your Kubernetes cluster.
And there are application developers who are deploying applications
onto that cluster If you're a cluster administrator,
you don't care about the apps.
You just focus on how full the machines are and
if you need to add a new machine.
You slap a new machine down.
And eventually,
it's gonna be something where it's auto scale, right?
>> So you showed me in Azure the way you made all those different virtual machines-
>> Right.
>> But you made them all at once, you created a template.
I can add additional ones?
>> Absolutely, yeah. >> Or I can append them.
>> Exactly, so you using the same Azure command line,
you can scale up the cluster if you need to add any new resources cuz
hopefully your service is growing.
>> Mm-hm.
>> Exactly.
>> And this is telling me, each of these are virtual machines?
>> Correct.
Yeah, so this is telling you the overall usage of
the virtual machine.
Now I can actually flip around and I can say top pod.
So those were machines.
Now these are the containers.
And it's telling us how much.
We're not hitting that web server with any load, so
it's not using any CPU really right now.
>> Right. >> And that's real time, right?
It's not- >> So here's maybe a little bit of
overhead, they were kinda chilling.
>> Yeah. >> And really,
the node thing's doing nothing, clearly.
>> Yeah, so this node CPU,
there are things that are running that service the cluster, right?
That make sure these things are healthy and [INAUDIBLE] that's-
>> [CROSSTALK] And
that's why these numbers don't represent the Node app,
these tiny ones do.
>> Yeah, exactly, right.
So that's right, that's right.
>> And then this is running what operating system underneath?
Is it offline or- >> [CROSSTALK] This is running,
inside those containers?
>> Yes.
>> I don't actually know.
>> The docker file, what's that from?
>> It's from NodeJS.
[CROSSTALK] >> That's great, whatever.
I don't care about OS.
I just need node.
I don't think about necessarily the OS that's going on.
>> That's cool.
That also makes me feel like I could go and do that in a core?
>> Yes. Absolutely.
>> On a node and mix and match.
One of my services could be in one language, one could be the other.
>> Absolutely.
Even in an operating system you could have say, that Python one,
maybe it came from Redhat.
Maybe the node JS one is on top of the Bunto.
With Golang binaries, you don't even have really a OS image there,
it's just a scratch disk, right?
>> Yeah, yeah, yeah.
>> But yeah, you don't care right?
You're focusing on the application.
>> That's fantastic.
So where do you see this going?
How big can we possibly scale?
>> Well so right now, some of the biggest clusters I've heard are at
in the 5,000 node range, which is probably more than most people need.
And that's sort of per region, right?
So there's actually also a notion of federation.
So you deploy a cluster in US West, you deploy a cluster is US East.
You can actually kind of a sort of uber cluster that sits on top,
that allows you to administer both, right?
And will spread work between those two clusters.
>> Is this in Preview, or can people use this right now?
>> People can use this right now.
It is in preview.
The Kubernete's part is in preview.
Azure container service itself is GA.
But we just launched the Kubernete's part.
We need to give a little bit of a soak.
But I anticipate it going to GA pretty soon.
>> Very cool. Thanks so much for your time.
>> Yeah, no problem at all.
Thank you. >> We're learning all about
Kubernetes and containers and
Azure container service, here on Azure Friday.
[MUSIC]