在理解virtual-Kubelet之前，咱们先理解下什么是Kubelet。
Kubelet 是在每个Node节点上运行的次要 “节点代理”。在Kubernetes集群中每个节点都会启动一个kubelet过程，kubelet基于PodSpec来工作。每个Pod Spec是一个形容Pod的YAML或JSON对象。Kubelet承受通过各种机制（次要是通过Apiserver）提供的一组Pod Spec，并确保这些Pod Spec中形容的容器处于运行状态且运行状况良好。同时Kubelet还通过cAdvisor监控容器和节点资源，定期向上报以后节点的衰弱状态以及资源应用状况，能够把Kubelet了解成[Server-Agent]架构中的Agent。
Virtual-Kubelet是基于Kubelet的典型个性实现，向上伪装成Kubelet，从而模拟出Node对象，对接Kubernetes的原生资源对象；向下提供API，可对接其余资源管理平台提供的Provider。不同的平台通过实现Virtual-Kubelet定义的办法，容许节点由其对应的Provider提供(如ACI，AWS Fargate，IoT Edge，Tensile Kube等)反对，实现Serverless，或者将其扩大到如Docker Swarm、Openstack Zun等容器平台中，也能够通过Provider纳管其余Kubernetes集群，甚至是原生的IaaS层平台(VMware、zstack、openstack)。
最好的形容是Kubernetes API on top，programmable back。
Virtual-Kubelet如何治理虚拟机是本文探讨重点。
Virutal-Kubelet的架构
Virtual-Kubelet 模仿了Node资源对象，并负责对Pod调度到Virtual-Kubelet假装的虚构节点之后，对Pod进行生命周期治理。
以后反对原生Kubernetes个性：
创立，删除和更新Pod
Container的日志，治理和监控
获取单个Pod或多个Pod状态
节点地址，节点容量，节点守护程序端点
治理操作系统
携带公有虚构网络
Virtual-Kubelet如何治理虚拟机？
虚拟机生命周期治理
Virtual-Kubelet在虚拟机调度和操作方面能够复用Kubernetes原生的资源对象，但Pod在Kubelet治理下的生命周期仅存在创立、运行和销毁，理论对于虚拟机的开关机、备份和迁徙等操作无奈实现映射关系，因而对于简单的生命周期治理，须要通过自定义CRD形式反对不同类型的IaaS平台，每一个VM-CR对应一个IaaS层VM实例。
对于VM-CR操作次要能够分为两类：
对VM运行状态变更
创立和销毁：能够对应一个VM-CR的create/delete
VM启停操作对应VM-CR replicas数量的变更:开机0→1关机1→0
VM规格变更：批改VM-CR Spec资源定义
kubectl logs/exec VM-pod：实现对Pod的拜访
对VM进行备份/迁徙
VM备份采纳创立对应Backup-Job对象，通过与VM-CR实例pod亲和形式，将Backup-Job调度置VM理论节点所运行的Virtual-Kubelet节点上，备份状态与Job执行状态统一
VM迁徙采纳Kubernetes原生的节点调度形式，IaaS平台每一个负载VM的物理机对应一个Kubernetes集群内的Virtual-Kubelet，VM-CR实例Pod的调度由Kubernetes管制面治理
虚拟机存储管理
因为Virtual-Kubelet中Pod仅作为逻辑概念，IaaS层存储无奈与Kubernetes集群专用，但可形象为Kubernetes原生定义的PV/PVC，PV的access mode能力依赖IaaS层能力，并须要实现对应平台和底层存储的Provider和Provisioner。
Virtual-Kubelet如何实现容器与虚拟机交互
容器和虚拟机互通
Virtual-Kubelet对应的Node会上报节点上Pod的Endpoint，假设Kubernetes集群和IaaS层平台部署在同一个二层网络下，则集群内容器Pod能够拜访VM-Pod，但容器Pod对于VM-Pod不可见；
针对上一点能够通过Macvlan等网络插件，将容器-Pod，降维至二层网络上，实现容器-Pod和虚拟机互通，有肯定硬件要求。
如何实现一套集群下虚拟机与容器的混合调度与资源隔离
Virtual-Kubelet提供的是一个虚构节点用来向Kubernetes上报Node对象和Pod的状态和资源状况，虚拟机资源和集群内节点资源齐全隔离；
在引入Virtual-Kubelet的状况下，须要对Virtual-Kubelet节点配置Taint和Tolerations，保障容器-Pod和VM-Pod调度拆散。
服务发现
Virtual-Kubelet，通过Provider实现的API将IaaS层VM信息形象成对应Pod对象的信息的形式来上报Endpoints，能够通过给CR增加no selector Service，待VM-Pod拉起后补充address至对应的Service。
Virutal-Kubelet实用场景
实用场景
Virtual-Kuberlet适宜在已有IaaS层治理平台和Kubernetes集群环境下进行二者的买通，实现在Kubernetes集群上对立治理容器和非容器平台，同时因为Virtual-Kubelet在Serverless和纳管其余已有容器平台(Openstack Zun，Docker Swarm)方面也具备很高适配性，Virtual-Kubelet能够提供一套对立的API，不便开发者买通全流程。
Virtual-Kubelet的优缺点
长处
一个开源的Kubelet实现，应用Kubernetes源语，使构建、部署更简略
提供Kubelet典型个性接口，Provider仅需实现对应服务治理平台资源到Node和Pod对象个性的实现，不须要思考如何拜访Kubernetes
灵活性高，Severless实际、对接现有容器平台、对接现有IaaS平台均有肯定前景
Virtual-Kubelet设计将virtual-kubelet和Provider高度拆散，Virtual-Kubelet使对于异构服务平台具备很高的兼容性(不同架构如：ARM、S390x，不同CRI如：Kata、PodMan)，不光是能够纳关IaaS平台对于其余Kubernetes集群也能够实现治理
毛病
将非集群内资源形象成Node和Pod对象对资源应用上有肯定局限性，很难提供超出原有kubelet和IaaS平台能力领域，IaaS深度整合须要自行实现CRD
仅能作为转换器，用于容器和虚拟机对立治理时还是须要依靠已有的平台能力，无奈像Kubevirt等计划作为一个独自的Iaas治理平台应用
Virtual-Kubelet开发及部署
开发自定义的Provider
Virtual-Kubelet我的项目自身并不提供Provider,而是提供一系列定义Kubelet典型操作的接口，开发者须要依据利用场景实现对应的Provider。使Kubernetes能够进行按需和简直即时的Container的计算、调度，而无需治理VM根底构造，同时仍可利用可移植的KubernetesAPI。
实现遵循以下三个准则：
提供必要的后端管道(back-end plumbing)，以在Kubernetes的Context中反对Pods，Containers和相干资源的的生命周期治理
合乎Virtual-Kubelet以后提供的API
没有拜访Kubernetes APIServer的权限，通过实现具备定义良好的回调机制来获取Secrets或Configmap之类的数据
创立一个新的Provider次要须要通过调用Virtual-Kubelet提供的库实现如下三个接口：
PodLifecylceHandler：用于Pod生命周期的治理
type PodLifecycleHandler interface {
// CreatePod takes a Kubernetes Pod and deploys it within the provider.CreatePod(ctx context.Context, pod *corev1.Pod) error// UpdatePod takes a Kubernetes Pod and updates it within the provider.UpdatePod(ctx context.Context, pod *corev1.Pod) error// DeletePod takes a Kubernetes Pod and deletes it from the provider.DeletePod(ctx context.Context, pod *corev1.Pod) error// GetPod retrieves a pod by name from the provider (can be cached).GetPod(ctx context.Context, namespace, name string) (*corev1.Pod, error)// GetPodStatus retrieves the status of a pod by name from the provider.GetPodStatus(ctx context.Context, namespace, name string) (*corev1.PodStatus, error)// GetPods retrieves a list of all pods running on the provider (can be cached).GetPods(context.Context) ([]*corev1.Pod, error)}
PodNotifier：该接口容许Provider提供异步告诉Virtual-Kubelet无关Pod状态更新的信息，如未实现该接口的话，Virtual-Kubelet会定期检查所有Pod的状态，在打算运行大量Pod的场景中强烈推荐实现该接口
type PodNotifier interface {
// NotifyPods instructs the notifier to call the passed in function when// the pod status changes.//// NotifyPods should not block callers.NotifyPods(context.Context, func(*corev1.Pod))}
NodeProvider：NodeProvider负责告诉虚构小程序无关节点状态更新的信息。Virtual-Kubelet将定期检查节点的状态并相应地更新Kubernetes，如果不打算额定定义Node个性，能够间接应用Virtual-Kubelet提供的NativeNodeProvider
type NodeProvider interface {
// Ping checks if the node is still active.// This is intended to be lightweight as it will be called periodically as a// heartbeat to keep the node marked as ready in Kubernetes.Ping(context.Context) error// NotifyNodeStatus is used to asynchronously monitor the node.// The passed in callback should be called any time there is a change to the// node's status.// This will generally trigger a call to the Kubernetes API server to update// the status.//// NotifyNodeStatus should not block callers.NotifyNodeStatus(ctx context.Context, cb func(*corev1.Node))}
API Endpoints：用于实现kubectl logs和kubectl exec
部署
Provider部署简略仅须要在要增加指标集群的主机中增加二进制程序并依据IaaS层配置启动即可：
./bin/virtual-kubelet --provider="hc-vmware-provider" --exsi="X.X.X.X"