关于 Virtual Kubelet 的一些想法
· 2 min read
最近迫于需要蛮看了一下 Virtual Kubelet，脑子里有些想法所以蛮写写。不想写那种没啥卵用的代码分析或者文档性质的文章，少少写点就好。
这是啥玩意
从名字「Virtual Kubelet」（下文称 VK）来看，这货是个「虚拟 Kubelet」（强行解释），按我的解释法：Kubernetes 虚拟节点。拿出官网那张图就知道是啥玩意了
简单说就是：VK 实现了大部分（并非全部）普通 Kubernetes Kubelet 的功能，例如说节点注册、节点生命周期、Pod 生命周期管理。它的重点就是在于 Pod 生命周期管理。 我们可以通过 VK 去模拟成一个符合 k8s spec 的节点，而实际部署的方式、拓扑都可以由我们来控制。举个例子，我们可以实现一个 VK 当有 Pod 需要部署的时候，直接调用 ECS 跑下 docker run 或者起一台独立的 ECS 都是可以的。 以符合 Kubernetes Kubelet Specification 为前提，实现自由的部署、管理方式。常见的我们可以见到各个大厂推出的所谓「Serverless Kubernetes」、「 阿里云 ECI」、「华为云 CCI」 等等。
VK 有什么优势
我认为的他最大的优势就是：实现任意拓扑结构的部署方式，而保持由 Kubernetes 管理、维护；一定程度上带来的成本优化。
灵活的部署方式
正如上面所说，我们可以给每个 Pod 分配一台 ECS 去部署。当然这块也可以自己去撸 CRI 来达到这个目的。所以这边不多说这事情
成本优化
在公有云的场景下，对用户来说 VK 类的产品带来的成本下降（字面上）还是挺诱人的。毕竟有了 VK 用户就不需要固定节点，在弹性场景下没有固定节点就没有那么多的成本顾虑。公有云产品提供按照 Pod 为准的计费方式，所以对用户来说可以认为是用多少算多少，也是蛮舒服的。
云厂有大量的冗余资源可以使用，所以通过这类产品可以让云厂的成本下降而且用户的成本也降了，所以是不错的一个产品（我觉得吧）。但要是私有云就别折腾了，打死几万台机器搞个这玩意，没差多少，还不如让使用者想办法评估好自己该用的机器量，别瞎鸡儿申请然后闲置就好了。
VK 有什么劣势
就目前的了解情况，有一个比较严重的局限：无法部署 DaemonSet。怎么说呢，这也不算是 VK 的局限吧，准确说应该是在现有各云厂实现中的「Serverless Kubernetes」 产品最终的部署形态是对应到多宿主（可能物理机可能 ECS）。而 DS 是 Node 相关，所以这种场景下完全没法兼容。而我们往往会有一些 agent 类型的服务可能是业务需要依赖的，那这样就很尴尬了。。
另一个点就是由于最终部署的拓扑对于用户是屏蔽的，所以出现一些比较棘手的问题的时候其实不太好去查。
还有就是不知道为啥大厂实现的 VK Provider 常常偷工减料比如不实现 logs 不实现 exec，这点让我很不爽。我只想用 kubectl 但你非逼我去用你们的 Console 或者付费产品，就很难受了（尤其是当这些又没做好的时候，那简直夭寿）
最后
从目前对一些基于 VK 开发的「Serverless Kubernetes」产品的使用来说：虽然有一定局限性，但是配合云厂的产品撸一些无状态服务还是挺爽的。
