>> Hi. In this video,
I'm going to talk about virtual node on Azure Kubernetes Service.
Virtual node on Azure Kubernetes Service
is a way for you to deploy
workloads without having to add
additional infrastructure to your AKS clusters,
which means you don't need additional VMs to get
extra capacity inside your clusters.
It gives you fast provisioning and it gives you
the ability to pay per second for
the pods that you execute and run.
Now, virtual node integrates
Azure Container Instances in Azure Community Service seamlessly
by enabling you to schedule pods from your AKS cluster
onto the Azure Container Instances
infrastructure with virtual node.
So let me show you how this
is going to be enabled inside your Kubernetes cluster.
First, I'm in the Azure portal and what I've done
here is I've added an additional subnet
for my Azure Container Instance hosted pods.
So create a subnet,
make sure you delegate it to
the Container Instance container group resource.
The next thing you need to do is you need to enable
the virtual node add-on inside your cluster.
Now, the command to run is az
aks and then enable add-on and you need to pass
an information about the cluster you want
to enable the add-on to the actual add-on you want to enable,
and then a reference to the subnet which we just created.
Now, already done this in my cluster here.
What you can see above is if I
go and ask for the nodes I have inside my cluster,
I now have a virtual node ACI Linux node in here,
which is based on Virtual Kubelet.
So let's go and take a look at
a deployment that we can put into our cluster utilizing this.
So going over to Visual Studio Code,
I created a simple web server deployment using a Nginx.
I have a single replica running.
What I've done in here is I've added
a toleration and a node affinity to
help the Kubernetes scheduler use my resources in an optimal way.
Now, the virtual node that was added to
my cluster is by default tainted so that you
need to specifically say which workloads you want to
enable to be scheduled onto ACI through virtual node.
In this case, because I want to allow this workload together,
I add a toleration
so that it's able to be scheduled onto the tainted node.
The other thing I'm doing is I'm also adding a node affinity.
I'm using a preferred during scheduler node
during execution affinity here,
which means that this is going to be evaluated at
the time where a pod needs to find a node to run on,
but it will not be evaluated
if changes happen and pods are already up and running,
meaning basically possible not be
removed during execution or during run-time.
What I'm doing here is I'm saying, well,
I want to put a preference onto nodes who doesn't
have a label that says Virtual Kubelet,
where the type is Virtual Kubelet,
which means that I want to make sure that I
fill the VMs that I already have in
my cluster before starting scheduling out to the Virtual Kubelet.
So let's take a look at how this all works in action.
So let's head over to the terminal again.
What you can see I have in
my lower pane here is I already have the deployment running.
I have a single instance
of my container running on single replica.
You can see it's scheduled onto my regular nodes in here.
So let's go ahead and scale this up to 20 replicas.
What you can see in the lower pane is that you
start to see a lot of these pods go onto virtual nodes,
but you also see some of these pods stay within
the cluster and using the VMS that I already have.
So it's simply because of the fact that as my VMs
get filled up and all the resources being used,
we start scheduling out to virtual node.
As you'll see, these pods start running inside ACI,
they all have IPs and you'll be able to
communicate with these pods from within your cluster.
Now, I also want to show you that if I go ahead and
scale this down to only two replicas,
we should see that the scheduler is now preferring to
keep the two replicas that I want to have running inside my nodes,
and not using those extra resources in ACI.
So here you see I've scaled
back down to two web servers and they keep
running inside my clusters and I'm not using
those extra resources that I only needed for my burst.
So the great scenarios or good set of scenarios that fit
well for virtual node is if you have this kind of temporary burst
of capacity needed for
either REST APIs or web servers that you host,
you can do similar for what I did,
what I just showed with deployment by simply adding
a horizontal pod autoscaler on top of this deployment.
By having the node affinity in the deployment,
you automatically see how you can continuously scale
as there are no more resource available inside your cluster.
Another scenario is that you need to go
and process objects on-demand,
and you have a very big change in demand over time.
So some scenarios here we see
customers bills is how you do queue processing and you can
use something like the Kubernetes event-driven autoscaler
together with an Azure Functions Framework.
The Kubernetes event-driven autoscaler, or KEDA,
enables you to scale down to zero pods,
meaning that you will only start running these pods and
spin them up as there're actually things to be processed.
The third scenario where
virtual node is very helpful is if you need to
securely isolate the processing of certain pods.
Those scenarios could be if you have
untrusted code in your solution.
Maybe you host code
that your customers other than your users provide.
By running these in virtual nodes,
we have the virtual node,
the Azure Container Instance
infrastructure that is backing virtual node,
is built in a way so that it's multi-tenant secure.
Now, virtual node is built in
the open sourced Virtual Kubelet technology,
which has been donated to
the Cloud Native Computing Foundation and is
currently a Sandbox Project in there.
I've added a GitHub link to the projects.
You can go and take a look.
Currently, virtual node supports Linux pods inside AKS.
There are actually ways to implement
your own Virtual Kubelet and AKS clusters
to also get Windows pod support.
Finally, I've added a link here to
a great sample of how you can see an end-to-end set up with
a website who is using
comatose metrics as scaling
mechanism to scale out to virtual node.
The same way I showed it here,
but with a more end-to-end integrated story.
This is a great sample to go and learn more about how to use
this technology. Thanks for listening.