I just made something pretty pointless!
I’m excited about the virtual-kubelet that the amazing Microsoft team announced at KubeCon last week. It lets something appear like it’s a node running a kubelet, when in fact there could be anything behind the virtual-kubelet. Anything, such as a container instance, a VM, or — as I’m demonstrating here — practically nothing.
The virtual-kubelet provider interface is really straightforward. Perhaps the most important thing it does is accept a request to start a pod. The silly provider I’ve just put together accepts those requests and then, well, it does almost nothing with them.
Not quite nothing — it keeps a list of the pods it’s supposed to be responsible for and you can query that list from a local web server.
Recording of the silly virtual-kubelet in action
I thought it would be fun to (a) explore the interface and (b) think about what you could do with Kubernetes other than run containers. It’s distributing all this state and metadata about objects around a cluster — could that be useful in and of itself? The answer might be ‘no’, or it might be a different way of using Kubernetes as a ‘distributed operating system’.
To be honest, I’m not entirely sure where this is going. One idea is that it might be fun to use something like this to drive, say, smart lightbulbs (turn more on if there are more pods! Use the pod definition to set the lighting colour!)
I’d quite like to extend this so you can add multiple virtual-kubelet nodes all running locally (perhaps each lightbulb has its own node?)
What else? Where would you take this next? Let me know in the comments?