介绍
Virtual Kubelet是Kubernetes kubelet的二次实现。它会伪装成一个kubelet以便使用者可以连接到其他API，这些API的入口被成为Provider。VK的主要方案是将Kubernetes API扩展到无服务器容器平台。Virtual Kubelet是插件式的，即插即用，非常灵活方便，并且使用的是kubernetes原语。
Virtual Kubelet 不是用来实现集群联邦的手段。它是用来扩展node属性到一个容器平台上。
当前支持功能如下：
- 创建，删除和更新Pod
- 容器 logs, exec, and metrics
- 获取单个Pod或多个Pod状态
- 节点地址，节点容量，节点守护程序
- 自定义虚拟网络
virtual-kubelet架构图
目前的社区的virtual kubelet 不具备任何生产能力，但是提供了一个library，可以给各家公有云厂商，用来构建自己的virtual kubelet 版本。virtual kubelet 的代码总体比较简单，没太必要详解了。
virtual kubelet 在启动的时候，会马上创建一个Node 出来
node 背后的provider 提供接口查询相关node 信息
它会同时watch node 和 pod 的事件，也就是要有两个控制器，用于更新node 的信息
针对分配到该节点上的pod，增加消息处理
消息处理的过程，是把消息放在另一个队列里
provider的worker 去处理，这里会作深度拷贝
处理完以后，更新pod 的status
优点
- 对原生Kubernetes集群无侵入
- 提供Kubelet典型特性接口，Provider仅需实现对应服务管理平台资源到Node和Pod对象特性的实现
- 扩展 Kubernetes 集群：Virtual Kubelet 允许将外部平台作为 Kubernetes 集群的计算资源，从而扩展 Kubernetes 的应用场景和规模。
- 跨云平台和边缘计算：Virtual Kubelet 可以将云平台和边缘设备作为 Kubernetes Node 节点，实现跨云平台和边缘计算的 Pod 调度和管理。
- 节省成本：使用 Virtual Kubelet 可以将临时性工作负载等低优先级应用调度到外部资源上，节省 Kubernetes 集群的成本和资源占用。
缺点
将非集群内资源抽象成Node和Pod对象对资源使用上有一定局限性，很难提供超出原有kubelet和IaaS平台能力范畴，IaaS深度整合需要自行实现CRD
仅能作为转换器，用于容器和虚拟机统一管理时还是需要依托已有的平台能力，无法像Kubevirt等方案作为一个单独的Iaas管理平台使用
安全性问题：Virtual Kubelet 可能会将 Pods 调度到不同的云提供商或边缘设备上，需要采取相应的安全措
解决了什么问题？
弹性能力、免容量规划、按需使用按需计费。集群资源不足调度时，VK将Pod调度到第三方集群中（如阿里ECI、华为CCI）
-
碎片资源整合（将多个集群碎片资源整合成一个大的资源池，需要比较重的Scheduler开发）- tensile-kube
- 一个作业需要N个资源，但是现有集群A、B、C等所剩资源都不满足N，而集群A、B、C资源总和又能满足N。
-
便捷化运维集群（类似KOK，多集群调度方案） - tensile-kube
- 当我们进行单个集群升级、变更时，往往需要通知业务迁移、集群屏蔽调度等，在此设计下，我们只需要将virtual-node设置为不可能调度。这样后期单个集群升级、替换，可以只在运维层操作，用户不用从旧集群迁移至新集群、无感知。
Virutal-Kubelet适用场景
Virtual-Kuberlet适合在已有IaaS层管理平台和Kubernetes集群环境下进行二者的打通，实现在Kubernetes集群上统一管理容器和非容器平台，同时由于Virtual-Kubelet在Serverless和纳管其他已有容器平台(Openstack Zun，Docker Swarm)方面也具有很高适配性，Virtual-Kubelet可以提供一套统一的API，方便开发者打通全流程。
已提供的实现者（provider）
| 支持类型 | 云容器实例 | |
|---|---|---|
| Alibaba Cloud ECI Provider | ECI | |
| Azure Container Instances Provider | ||
| AWS Fargate Provider | Amazon ECS | |
| OpenStack Zun Provider | ||
| Tensile Kube Provider | ||
| HUAWEI | 无状态负载（Deployment）、有状态负载（StatefulSet）、普通任务（Job） | CCI |
新的提供者需实现
案例
当前有两个集群，左侧集群是含有VK节点的集群，右侧集群则是我们期望Pod实际使用资源的集群，也就是在左侧集群创建一个指定pod.spec.nodeName=virtual-kubelet节点的Pod，实际上运行在右侧集群上。
问题
- 以VK启动在其他平台的Pod，网络互通形式？
- 考虑资源同步问题 configMap/pvc/pv/字典、镜像
- 日志收集
- sidecar(filebeat + logstash + elasticsearch)
- 资源回传
限制
Severless容器服务，用户不感知Node，所以不支持hostpath挂载以及DaemonSet部署
