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.
안녕하세요.
저는 Brendan입니다. 오늘은 서버리스 Kubernetes와 Kubernetes에서 서버리스 실행에 대해 말씀 드리겠습니다.
서버리스의 정직한 컨테이너와 기술 분야의 다른 많은 단어에 대한 논의에서 단어 자체가 반드시 특별히 설명적인 것보다 더 큰 의미를 가지고 있다고 생각합니다.
따라서 서버리스라고 할 때 의미하는 바에 대해 이야기하는 것이 가장 중요합니다.
오늘날 클라우드에서 서버리스에는 두 가지 뚜렷한 의미가 있다고 생각합니다.
하나는 실제로 서버가 없다는 것입니다.
분명히 서버가 사라졌고 코드가 어떻게 든 클라우드에서 실행되고 있습니다.
그러나 서버 자체는 보이지 않습니다.
자, 분명히 그것은 단순히 증기로 작동하지 않습니다.
어딘가에 서버가 있지만 클라우드 추상화가이를 숨기도록 선택했습니다.
우리가 보는 서버리스의 다른 정의는 서비스 또는 FaaS로서의 기능 개념이라고 생각합니다.
이것은 실제로 내가 함수가 있다고 말하는 프로그래밍 모델이며, 클라우드 어딘가에 정의되어 있으며, 해당 함수를 호출하고 HTTP 요청에 대한 응답으로 실행하거나 git push 또는 클라우드에서 발생할 수있는 다른 종류의 이벤트.
나는 이것들이 매우 다른 두 가지라고 생각합니다.
하나는 작업을 숨기고 응용 프로그램 개발자가 생각하고 관리해야하는 작업의 복잡성을 줄이는 것입니다. 다른 하나는 실제로 프로그래밍 모델이며 어떤면에서는 더 쉽고 어떤면에서는 응용 프로그램을 구성하는 방법입니다. 응용 프로그램을 개발하는 것이 더 복잡해집니다.
이 두 개념이 Kubernetes와 상호 작용하는 방식은이 두 가지 다른 아이디어와 관련이 있다고 생각합니다.
그래서 이전에 Kubernetes API가 실제로 머신을 숨기도록 의도 된 방식에 대해 논의했습니다.
여기에 서버가 있고 여기에 VM이 있다면 여기에서 서버리스 Kubernetes 또는 노드없는 Kubernetes에 대해 이야기 할 때이를 그릴 수 있습니다.
이것이 바로 Kubernetes 노드입니다.
노드없는 Kubernetes는 어떻게 만들 수 있습니까? 그렇다면이 기계들이 더 이상 존재하지 않는 세상을 어떻게 만들 수 있을까요? 이를위한 첫 번째 선구자는 컨테이너를 서비스로 제공하거나 클라우드에서 서버리스 컨테이너를 제공 할 수있는 것입니다.
따라서 Azure 컨테이너 인스턴스와 같은 것을 보면 Azure 컨테이너 인스턴스로 이동하여 "이봐, 여기 내 컨테이너가 있습니다.
실행하십시오. "물론 해당 컨테이너는 Azure 데이터 센터의 서버 어딘가에있는 서버에서 실행되지만 실제로는 해당 서버를 볼 수 없습니다.
우리는 당신을 위해 그것을 관리하고, 그것이 안전한지 확인하거나 최신 상태인지 확인합니다.
사용자 관점에서 보면 Azure의 인프라에서 실행되는이 서버리스 컨테이너가 표시되고 비용이 지불됩니다.
우리는 정말이 아이디어가 떠오르는 것을보고 있습니다.
사실, 다른 많은 퍼블릭 클라우드에서 복제되거나 온 프레미스 환경의 일부 사람들에게도 복제되고 있습니다.
이제 문제는이 서버리스 컨테이너 인프라를 어떻게 Kubernetes API와 결합 할 수 있는가입니다. 우리가 실제로이 작업을 수행 한 방법은 Virtual Kubelet 프로젝트라는 것을 통해서입니다.
따라서 Virtual Kubelet은 오픈 소스 프로젝트입니다.
GitHub에 있습니다.
실제로 CNCF 샌드 박스로 이동합니다.
이 작업은 Microsoft, Amazon, VMware, Kubernetes에서 서버리스 컨테이너를 연결하는 방법에 대한이 개념에 관심이있는 다른 많은 제공 업체가 작업했습니다.
그것이하는 일은 실제로 가상 노드를 만드는 것입니다.
이것이 Virtual Kubelet 부분입니다.
현재 구현 된 Kubernetes는 실제로 거기에 노드가 있어야하기 때문입니다.
따라서 Kubernetes의 API 자체는 시스템과 사용자를 분리하지만 Kubernetes API가 구현되는 방식은 실제로 노드가 있다는 생각에 연결됩니다.
따라서 가상 Kubelet은 Kubernetes API가 알고 있고 서버리스 컨테이너 인프라에 바인딩 된이 가상 노드를 제공합니다.
따라서 "Kubernetes API 위에서 포드를 실행하고 싶습니다."라고 말하면 해당 포드는 궁극적으로이 가상 노드에 예약됩니다.
그러면 Virtual Kubelet은“오, 알았어요.
Hey, Azure Container Instances, 최종 사용자를 위해이 컨테이너를 실행 해 주시겠습니까? "이제 컨테이너의 실행 버전이 있기 때문에 웃고 있습니다.
물론, 내가 kube 제어 로그라고 말하면 로그 요청을 가상 노드를 통해 인프라에서 실행중인 컨테이너로 라우팅하여 로깅 정보가 최종 사용자에게 다시 돌아 오도록하는 것과 같은 작업도 수행합니다.
따라서 실제로 서버리스 및 노드리스 Kubernetes 제공에 대해 이야기 할 때 실제로는 클라우드가 구축하고 사용자에게 제공하는 서버리스 컨테이너 인프라를 활용하기 위해 Kubernetes API 구현을 조정하는 것입니다.
이제 Kubernetes에서 서버리스 실행에 대해 이야기 할 때는 Kubernetes API를 가져와 서버리스 프로그래밍 모델을 제공하는 것으로 변환하는 것이 전부입니다.
그래서 우리는 솔직히 말해서 특별히 훌륭한 개발자 경험이 아닌 Kubernetes API가 있습니다.
인프라 구축에는 좋지만 빠르고 쉽게 함수를 배포하려는 초보자에게는 좋지 않습니다.
또한 사람들은 Kubernetes를 기반으로하는 서비스로서의 기능 구현을 구축하고 있습니다.
따라서 귀하와 이것이 사용자가 상호 작용할 수있는 새로운 API를 제공 할 때.
따라서 사용자가 들어 와서 "이봐, 서비스로서의 기능, 여기 내 기능이 있습니다."라고 말하면 서비스로서의 기능은 내부에 기능이있는 컨테이너로 패키징 한 다음 Kubernetes API 및 컨테이너가 실제로 실행되는 방식은 Kubernetes API가 관리하는 이러한 노드 중 하나에서 다운되거나 Virtual Kubelet에서 제공하는 가상 노드 일 수도 있습니다.
이 기능을 Kubernetes 위에 구현 된 서비스로 사용하는 것의 좋은 점은 물론 서비스 환경으로서의 기능으로 제한 할 필요가 없다는 것입니다.
다른 애플리케이션을 단독으로 실행하려는 경우에도 여전히 서비스로서의 기능을 보유하고 다른 애플리케이션, 서비스로드 밸런서를 호출 할 수 있으며 Kubernetes의 다른 모든 오케스트레이션 인프라를 애플리케이션에서 계속 사용할 수 있습니다.
프로그래밍 모델과 이벤트 스트림 만 취했습니다.
따라서 이벤트는 또한 서비스로서의 기능을 트리거하며 Kubernetes 클러스터를 사용하는 최종 사용자가 해당 프로그래밍 모델을 사용할 수 있도록했습니다.
이것이 서버리스 컨테이너 기술 위에 서버리스 Kubernetes를 제공하는 방법과 Kubernetes 클러스터 위에 서버리스 프로그래밍 모델을 구축하고 배포하는 방법에 대한 설명이 제공되기를 바랍니다.
감사.
Add Comment