Serverless isn't just about programming models, it can
also be infrastructure. Virtual nodes enable you to
deploy containers at scale more rapidly into a KS
without worrying about your cluster size. Brendan Burns
is here to show us how today on Azure Friday.
Hey everyone Donovan Brown here with another episode of Azure
Friday. I'm here with Brendan Burns. We're going to talk about
virtual nodes so virtual nodes tell me what these are about.
Well, you know, with Kubernetes, traditionally, the entire system
is built on top of virtual machines, so you have virtual
machines to run the API servers. All of the control plane
components. You have virtual machines that are running the
worker nodes, but you know when you're using a carbonated API,
you actually are really just
thinking about containers. And you're thinking about the
control plane API. You don't really care about the virtual
machines in many cases that are actually a liability, you have
to Patch them. You have to worry about is the operating system,
the operating system that is approved for compliance or
whatever else. And so with Azure what we're really trying to do
is make the communities of experience to server list as
possible. Because I was always concerned too when I was
building it, like how many nodes do I need. And here I am trying
to figure out how much do workloads I'm going to need and
that becomes a pain point for me. It's figuring out should it
be 4, five, 6 and am I getting too many or they? Yeah yeah it's
definitely the case. That's one of the things I think server
list. Enables you to do beyond just not thinking about the
operating system is actually to not necessarily have to think
about scale. Gotcha right. Whether you're overpaying by
buying too many virtual machines or you're worried that if
there's a burst of traffic you might have under scaling, or
maybe it's that your developers go home at five o'clock, 6:00
o'clock tonight, and they leave a virtual machine running all
night and you're paying for it while they're not working.
There's a lot of reasons why you want to be able to produce
cluster where you can scale with the last Ecity an only pay.
When the containers are running, and that's what virtual nodes
enabled. So if you take a look, as we bring serverless into
Azure Community service, we run the master control plan for you
serverless control plan with virtual nodes. We replace a
bunch of your worker nodes, the elastic part of your pool, with
serverless, containers were still in the process of making
it creates fully server list it wasn't built with Serverless
Inventure, and so there are still some places where you need
virtual machines, and so we still see customers running.
Both virtual machines in virtual nodes, but our long-term
trajectory is towards you know nothing but virtual nodes and
serverless everywhere got it so as of today you can start adding
virtual nodes to your existing cluster, but there might be
scenarios where you're still going to need those VMS to be
able to Mount discord, be able to sit behind a load balancer,
or something like that. Yeah, so you need a few nodes to act as
sort of bastion inputs for the load balancer, and then the
Azure container instances which powers the virtual nodes doesn't
support Azure Disk today.
All these things are being developed perfect, but if you
need Azure files it works with server list containers. Got it
so in the future what we're hoping to have is a KS
completely service where all I have is a control plane that is
controlled by Microsoft and a virtual know that's going to be
the target for all my workload. That's exactly right, and that
is definitely the North star is I think that's what people want.
They want to focus on containers and leave the running of the
infrastructure dot perfect, and then I don't have to pay for
those ones that were running 24 by 7 simply because I needed
behind a load balancer. Now aside and I only pay for them
when I need. Exactly exactly, yeah, absolutely. So will take a
look at what this looks like. I wanted to mention of course.
Also that serverless actually extends beyond the communities
API itself. It extends to things like Azure Monitor with their
container insights container registry. Really trying to make
sure that there are no virtual machines anywhere for you as
much as we can, because I remember when I start playing
with ACR I didn't realize that I could actually have a CR build.
The image for me too. I always thought of ACR is just a place
where I store it, but you can actually say no. Go build it, go
do. You can do your developer. You can do the whole thing in
Azure cloud shell. You have a shell at the serverless shell.
You have a server. List the communities serverless,
everything right, and I think that is most people. I mean, I
think for most people the ability to just do it from a web
browser to do it from an environment where I can throw it
away and find the next environment. It's really optimal
cool, so let's see how it works. Alright cool, let's take a look.
Alright cool, so we're going to take a look at Kubernetes
cluster in a KS with virtual nodes attached. The first thing
we can look at here is the nodes and. This is using the vscode
extension but the same commands are available with control on
the command line. In fact, that's what's being used under
the hood. Got it pretty or visualization and all that and
what you see here is we've got three nodes back with the MSS
and virtual node here. What's interesting about the virtual
node is you're never going to have more than one for any
particular operating system. You might have one for Windows and
one for Linux. But you don't need to add more nodes to add
more scale. Got it, the containers just go into that
node and it just grows affectively. It's virtual
anyway, but it grows in order to accommodate new container.
Deployment over here and we can take a look at this deployment
and it's got three pods running inside that deployment.
If I say, you know I want to scale up right, I'm going to
come along here and I'll take this to four.
And then will apply that.
This shows off a little bit of the extension as well. It
actually is just showing me the difference that I'm going to do,
so it's highlighting the replicas from three to four so I
can choose to apply that. Now I'm going to try and scale up to
four, and we've scaled up now.
And what you can see here is I have my three pods running, but
the new one, the scale up one, is stuck in pending. Yeah, the
reason it stuck in pending is because I've used up all the
capacity on my physical machines. Yeah, but you were
over there. You showed me that you actually had a virtual node,
so I would expect that one just to start running on that one,
right? So we've actually made a design decision here with the
product, which says that as an end user you need to explicitly
opt into using virtual nodes. So even though it's a part of my
cluster, that's not enough, is not just adding one, it's also
adding one saying. I also now want to use that right? So
community says this notion. What's called Taints and
toleration's, and basically it's a way of saying, like this node
has a little bit of a difference or something like that. And then
you have to say, well, I tolerate that difference and if
I do then I'll get scheduled on to that. And if I don't it could
be used for something like hey we think the memory might be
slightly bad or a disk went bad, but in this case it's saying hey
the infrastructure is a little different. You should know that
you're getting scheduled out into this ACI because of course
you could imagine. Well, I created a cluster and it costs 3
virtual machines and it's a fixed cost with virtual nodes.
If you scale really big, you're going to start paying
more, and that's maybe a little bit different than with
somebody's expecting. So we want to make sure that the
user explicitly, as I want that perfect, and that's where
we are now, is that we have the node, but we haven't told
our cluster to use that node, right? And we have to add an
annotation, and so we go back over. Here we will close all
then.
My files, so if we take a look at this one, what you can see
here is I've added this.
Got it so this is the same deployment you had before with
just this portion added to it right. It's the same deployment,
but this little portion gets added, which basically says I'm
going to tolerate the fact that I'm a virtual cubelet and that's
going to allow me to then schedule and so if I now this
one has going to change that to four also. So if I apply this.
There's a lot of differences the cluster has when you create
something in the communities cluster. Ads like the creation,
timestamp and stuff, but it should just work. So now let's
see what happened. If I go back over and I search for any
pending pods. They're all gone, and so that last pod has been
scaled out to the virtual node now and obviously I can go even
bigger if I want. I could scale up to 10 that can scale up to
the number of virtual containers that I can add to my
subscription, so I see, yeah, so we're not. We're no longer bound
by the nodes that we have is we talked about earlier. My biggest
concern is I either have two fewer too many nodes and now I
have always just the right amount of nodes because I can
burst out and then it will shrink back in right? When
you're only playing for the containers that you have active,
not the node itself, the virtual
node. Is always free. Gosh perfect cool cool. Alright so
we're learning all about virtual nodes here on Azure Friday.