[MUSIC] >> Hi.
I'm Brendan and I'm going to talk to you today about serverless Kubernetes and running serverless on Kubernetes.
I think in any discussion of serverless and really honestly containers and many other words in the technological sphere, the words themselves have taken on a larger meaning than necessarily is particularly descriptive.
So, it's first really valuable to talk about what we mean when we say serverless.
I think actually there are two distinct meanings for serverless in cloud today.
One is actually that there are no servers.
Obviously, server has disappeared, your code is running in the cloud somehow.
But the server itself is invisible to you.
Now, clearly, it doesn't simply run on vapor.
There is a server there somewhere but the cloud abstraction has chosen to hide it from you.
I think that the other definition for serverless that we see is the notion of functions as a service or FaaS.
This is really a programming model where I say I have a function, it's defined in the cloud somewhere, and I have an event-driven way of calling that function and having it execute possibly in response to an HTTP request, or in response to a git push, or any other kind of event that might occur in the cloud.
I think these are two very distinct things.
One is all about hiding operations from you and reducing the complexity of what you as an application developer need to think about and manage, and the other is really a programming model and a way of constructing applications that in some ways makes it easier and in some ways makes it more complicated for you to develop an application.
I think the way in which these two concepts interact with Kubernetes has to do with those two different ideas.
So, previously, I had discussed how the Kubernetes API is really intended to hide the machines from you.
So, if you have servers here, VMs here, when we're talking about serverless Kubernetes or nodeless Kubernetes since these here, I can draw it.
These are the nodes Kubernetes.
How can I create a nodeless Kubernetes? So, how can I create a world where these machines have ceased to exist? The first precursor for doing this is something where you can provide containers as a service or serverless containers in the cloud.
So, if you look at something like Azure Container instances, I can go to Azure Container instances and I can say, "Hey, here's my container.
Please run it." Of course, that container executes in a server somewhere in a server in an Azure data center, but you don't actually see that server.
We manage it for you, we ensure that it's secure, or we ensured that it is up to date.
From a user perspective, what you see and what you pay for is this serverless container that is running on Azure's infrastructure.
We're really seeing this idea take off.
In fact, it's being replicated in many other public clouds or even with for some people in an on-premise setting.
Now the question then is, how do I take this serverless container infrastructure and marry it up to the Kubernetes API? The way that we've done this actually is through this thing called the Virtual Kubelet project.
So, the Virtual Kubelet is an open source project.
It's up on GitHub.
It's actually going into the CNCF Sandbox.
It's worked on by Microsoft, by Amazon, by VMware, by a bunch of other providers who are interested in this notion of how do I bridge serverless containers in Kubernetes.
What it does is it actually creates a virtual node.
That's the Virtual Kubelet part.
That's because Kubernetes as it currently is implemented really needs to have nodes there.
So, the Kubernetes' API itself separates you from the machines, but the manner in which the Kubernetes API is implemented really is attached to the idea of there being nodes.
So, the virtual Kubelet provides this virtual node that the Kubernetes API knows about and that is bound to the serverless container infrastructure.
So, when you come along and you say, "I would like to run a pod on top of the Kubernetes API," that pod is ultimately scheduled onto this virtual node.
The Virtual Kubelet then is responsible for saying, “Oh, okay.
Hey, Azure Container Instances, would you please run this container for the end-user." It's now smiling because they have a running version of their container.
Of course, it's also responsible for doing things like if I say kube control logs, routing the logs request through the virtual node down to the container that's running in the infrastructure so that logging information comes back to the end user.
So, really when we're talking about delivering serverless and nodeless Kubernetes, it's really about adapting the implementation of the Kubernetes API to take advantage of serverless container infrastructure that clouds are building and providing to their users.
Now when we're talking about running serverless on Kubernetes, it's all about taking the Kubernetes API and transforming it into something that supplies the serverless programming model.
So, we have here the Kubernetes API, which in all honesty is not a particularly great developer experience.
It's good for building infrastructure, not really great for beginners who want to quickly and easily deploy functions.
So on top of that, people are building implementation of functions as a service that is based on Kubernetes.
So, when you and this supplies a new API that users can interact with.
So, when a user comes in and says, "Hey, functions as a service, here's my function," this functions as a service is responsible then for packaging that up as a container with your function inside, and then scheduling that container using the Kubernetes API, and how that container actually executes is probably then down on one of these nodes that is being managed by the Kubernetes API or it could possibly even be a virtual node supplied by the Virtual Kubelet.
The great thing about using this functions as a service implemented on top of Kubernetes is, of course, you don't have to be limited to the functions as a service environment.
If you want to run other applications by themselves, you can still have your functions as a service, make a call out to those other applications, service load balancers, all of the other orchestration infrastructure in Kubernetes is still available to your applications.
You've merely taken the programming model and the event streams.
So, the events are also triggering your functions as a service and you've made that programming model available to end users who are using your Kubernetes cluster.
I hope that's given an illustration of both how we can deliver serverless Kubernetes on top of serverless container technology, as well as how you build and deploy the serverless programming model on top of any Kubernetes cluster.
Thanks.
[MUSIC]