HAMi vGPU 原理分析 Part2：hami-webhook 原理分析

上篇我们分析了 hami-device-plugin-nvidia，知道了 HAMi 的 NVIDIA device plugin 工作原理。

本文为 HAMi 原理分析的第二篇，分析 hami-scheduler 实现原理。

为了实现基于 vGPU 的调度，HAMi 实现了自己的 Scheduler：hami-scheduler，除了基础调度逻辑之外，还有 spread & binpark 等 高级调度策略。

主要包括以下几个问题：

• 1）Pod 是如何使用到 hami-scheduler，创建 Pod 时我们未指定 SchedulerName 默认会使用 default-scheduler 进行调度才对

• 2）hami-scheduler 逻辑，spread & binpark 等 高级调度策略是如何实现的

由于内容比较多，拆分为了 hami-webhook、 hami-scheduler 以及 Spread&Binpack 调度策略三篇文章，本篇我们主要解决第一个问题。

以下分析基于 HAMi v2.4.0

1. hami-scheduler 启动命令

hami-scheduler 具体包括两个组件：

• hami-webhook

• hami-scheduler

虽然是两个组件，实际上代码是放在一起的，cmd/scheduler/main.go 为启动文件：

这里也是用 corba 库实现的一个命令行工具。

var (
    sher        *scheduler.Scheduler
    tlsKeyFile  string
    tlsCertFile string
    rootCmd     = &cobra.Command{
       Use:   "scheduler",
       Short: "kubernetes vgpu scheduler",
       Run: func(cmd *cobra.Command, args []string) {
          start()
       },
    }
)

func main() {
    if err := rootCmd.Execute(); err != nil {
       klog.Fatal(err)
    }
}

最终启动的 start 方法如下：

func start() {
    device.InitDevices()
    sher = scheduler.NewScheduler()
    sher.Start()
    defer sher.Stop()

    // start monitor metrics
    go sher.RegisterFromNodeAnnotations()
    go initMetrics(config.MetricsBindAddress)

    // start http server
    router := httprouter.New()
    router.POST("/filter", routes.PredicateRoute(sher))
    router.POST("/bind", routes.Bind(sher))
    router.POST("/webhook", routes.WebHookRoute())
    router.GET("/healthz", routes.HealthzRoute())
    klog.Info("listen on ", config.HTTPBind)
    if len(tlsCertFile) == 0 || len(tlsKeyFile) == 0 {
       if err := http.ListenAndServe(config.HTTPBind, router); err != nil {
          klog.Fatal("Listen and Serve error, ", err)
       }
    } else {
       if err := http.ListenAndServeTLS(config.HTTPBind, tlsCertFile, tlsKeyFile, router); err != nil {
          klog.Fatal("Listen and Serve error, ", err)
       }
    }
}

开始初始化了一下 Device

这个后续 Webhook 会用到，等会再看

device.InitDevices()

然后启动了 Scheduler

sher = scheduler.NewScheduler()
sher.Start()
defer sher.Stop()

接着启动了一个 Goroutine 来从之前 device plugin 添加到 Node 对象上的 Annotations 中不断解析拿到具体的 GPU 信息

go sher.RegisterFromNodeAnnotations()

最后则是启动了一个 HTTP 服务

router := httprouter.New()
router.POST("/filter", routes.PredicateRoute(sher))
router.POST("/bind", routes.Bind(sher))
router.POST("/webhook", routes.WebHookRoute())
router.GET("/healthz", routes.HealthzRoute())

其中

• /webhook 就是 Webhook 组件
• /filter 和 /bind 则是 Scheduler 组件
• /healthz 则用作健康检查。

接下来在通过源码分析 Webhook 以及 Scheduler 各自的实现。

2. hami-webhook

这里的 Webhook 是一个 Mutating Webhook，主要是为 Scheduler 服务的。

核心功能是：根据 Pod Resource 字段中的 ResourceName 判断该 Pod 是否使用了 HAMi vGPU，如果是则修改 Pod 的 SchedulerName 为 hami-scheduler，让 hami-scheduler 进行调度，否则不做处理。

MutatingWebhookConfiguration 配置

为了让 Webhook 生效，HAMi 部署时会创建MutatingWebhookConfiguration 对象，具体内容如下：

root@test:~# kubectl -n kube-system get MutatingWebhookConfiguration vgpu-hami-webhook -oyaml
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  annotations:
    meta.helm.sh/release-name: vgpu
    meta.helm.sh/release-namespace: kube-system
  labels:
    app.kubernetes.io/managed-by: Helm
  name: vgpu-hami-webhook
webhooks:
- admissionReviewVersions:
  - v1beta1
  clientConfig:
    caBundle: xxx
    service:
      name: vgpu-hami-scheduler
      namespace: kube-system
      path: /webhook
      port: 443
  failurePolicy: Ignore
  matchPolicy: Equivalent
  name: vgpu.hami.io
  namespaceSelector:
    matchExpressions:
    - key: hami.io/webhook
      operator: NotIn
      values:
      - ignore
  objectSelector:
    matchExpressions:
    - key: hami.io/webhook
      operator: NotIn
      values:
      - ignore
  reinvocationPolicy: Never
  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'
  sideEffects: None
  timeoutSeconds: 10

具体效果是在创建 Pod 时，kube-apiserver 会调用该 service 对应的 webhook，这样就注入了我们的自定义逻辑。

关注的对象为 Pod 的 CREATE 事件：

  rules:
  - apiGroups:
    - ""
    apiVersions:
    - v1
    operations:
    - CREATE
    resources:
    - pods
    scope: '*'

但是不包括以下对象

  namespaceSelector:
    matchExpressions:
    - key: hami.io/webhook
      operator: NotIn
      values:
      - ignore
  objectSelector:
    matchExpressions:
    - key: hami.io/webhook
      operator: NotIn
      values:
      - ignore

即：namespace 或者 资源对象上带 hami.io/webhook=ignore label 的都不走该 Webhook 逻辑。

请求的 Webhook 为

    service:
      name: vgpu-hami-scheduler
      namespace: kube-system
      path: /webhook
      port: 443

即：对于满足条件的 Pod 的 CREATE 时，kube-apiserver 会调用该 service 指定的服务，也就是我们的 hami-webhook。

接下来就开始分析 hami-webhook 具体做了什么。

源码分析

这个 Webhook 的具体实现如下：

// pkg/scheduler/webhook.go#L52
func (h *webhook) Handle(_ context.Context, req admission.Request) admission.Response {
    pod := &corev1.Pod{}
    err := h.decoder.Decode(req, pod)
    if err != nil {
       klog.Errorf("Failed to decode request: %v", err)
       return admission.Errored(http.StatusBadRequest, err)
    }
    if len(pod.Spec.Containers) == 0 {
       klog.Warningf(template+" - Denying admission as pod has no containers", req.Namespace, req.Name, req.UID)
       return admission.Denied("pod has no containers")
    }
    klog.Infof(template, req.Namespace, req.Name, req.UID)
    hasResource := false
    for idx, ctr := range pod.Spec.Containers {
       c := &pod.Spec.Containers[idx]
       if ctr.SecurityContext != nil {
          if ctr.SecurityContext.Privileged != nil && *ctr.SecurityContext.Privileged {
             klog.Warningf(template+" - Denying admission as container %s is privileged", req.Namespace, req.Name, req.UID, c.Name)
             continue
          }
       }
       for _, val := range device.GetDevices() {
          found, err := val.MutateAdmission(c)
          if err != nil {
             klog.Errorf("validating pod failed:%s", err.Error())
             return admission.Errored(http.StatusInternalServerError, err)
          }
          hasResource = hasResource || found
       }
    }

    if !hasResource {
       klog.Infof(template+" - Allowing admission for pod: no resource found", req.Namespace, req.Name, req.UID)
       //return admission.Allowed("no resource found")
    } else if len(config.SchedulerName) > 0 {
       pod.Spec.SchedulerName = config.SchedulerName
    }
    marshaledPod, err := json.Marshal(pod)
    if err != nil {
       klog.Errorf(template+" - Failed to marshal pod, error: %v", req.Namespace, req.Name, req.UID, err)
       return admission.Errored(http.StatusInternalServerError, err)
    }
    return admission.PatchResponseFromRaw(req.Object.Raw, marshaledPod)
}

逻辑比较简单：

• 1）判断 Pod 是否需要使用 HAMi-Scheduler 进行调度

• 2）需要的话就修改 Pod 的 SchedulerName 字段为 hami-scheduler(名字可配置)

至此，核心部分就是如何判断该 Pod 是否需要使用 hami-scheduler 进行调度呢？

如何判断是否使用 hami-scheduler

Webhook 中主要根据 Pod 是否申请 vGPU 资源来确定，不过也有一些特殊逻辑。

特权模式 Pod

首先对于特权模式的 Pod，HAMi 是直接忽略的

if ctr.SecurityContext != nil {
  if ctr.SecurityContext.Privileged != nil && *ctr.SecurityContext.Privileged {
     klog.Warningf(template+" - Denying admission as container %s is privileged", req.Namespace, req.Name, req.UID, c.Name)
     continue
  }
}

因为开启特权模式之后，Pod 可以访问宿主机上的所有设备，再做限制也没意义了，因此这里直接忽略。

具体判断逻辑

然后根据 Pod 中的 Resource 来判断是否需要使用 hami-scheduler 进行调度：

for _, val := range device.GetDevices() {
    found, err := val.MutateAdmission(c)
    if err != nil {
       klog.Errorf("validating pod failed:%s", err.Error())
       return admission.Errored(http.StatusInternalServerError, err)
    }
    hasResource = hasResource || found
}

如果 Pod Resource 中有申请 HAMi 这边支持的 vGPU 资源则，那么就需要使用 HAMi-Scheduler 进行调度。

而那些 Device 是 HAMi 支持的呢，就是之前 start 中初始化的：

var devices map[string]Devices

func GetDevices() map[string]Devices {
    return devices
}

func InitDevices() {
    devices = make(map[string]Devices)
    DevicesToHandle = []string{}
    devices[cambricon.CambriconMLUDevice] = cambricon.InitMLUDevice()
    devices[nvidia.NvidiaGPUDevice] = nvidia.InitNvidiaDevice()
    devices[hygon.HygonDCUDevice] = hygon.InitDCUDevice()
    devices[iluvatar.IluvatarGPUDevice] = iluvatar.InitIluvatarDevice()
    //devices[d.AscendDevice] = d.InitDevice()
    //devices[ascend.Ascend310PName] = ascend.InitAscend310P()
    DevicesToHandle = append(DevicesToHandle, nvidia.NvidiaGPUCommonWord)
    DevicesToHandle = append(DevicesToHandle, cambricon.CambriconMLUCommonWord)
    DevicesToHandle = append(DevicesToHandle, hygon.HygonDCUCommonWord)
    DevicesToHandle = append(DevicesToHandle, iluvatar.IluvatarGPUCommonWord)
    //DevicesToHandle = append(DevicesToHandle, d.AscendDevice)
    //DevicesToHandle = append(DevicesToHandle, ascend.Ascend310PName)
    for _, dev := range ascend.InitDevices() {
       devices[dev.CommonWord()] = dev
       DevicesToHandle = append(DevicesToHandle, dev.CommonWord())
    }
}

devices 是一个全局变量， InitDevices 则是在初始化该变量，供 Webhook 中使用，包括 NVIDIA、海光、天数、昇腾等等。

这里以 NVIDIA 为例说明 HAMi 是如何判断一个 Pod 是否需要自己来调度的，MutateAdmission 具体实现如下：

func (dev *NvidiaGPUDevices) MutateAdmission(ctr *corev1.Container) (bool, error) {
    /*gpu related */
    priority, ok := ctr.Resources.Limits[corev1.ResourceName(ResourcePriority)]
    if ok {
       ctr.Env = append(ctr.Env, corev1.EnvVar{
          Name:  api.TaskPriority,
          Value: fmt.Sprint(priority.Value()),
       })
    }

    _, resourceNameOK := ctr.Resources.Limits[corev1.ResourceName(ResourceName)]
    if resourceNameOK {
       return resourceNameOK, nil
    }

    _, resourceCoresOK := ctr.Resources.Limits[corev1.ResourceName(ResourceCores)]
    _, resourceMemOK := ctr.Resources.Limits[corev1.ResourceName(ResourceMem)]
    _, resourceMemPercentageOK := ctr.Resources.Limits[corev1.ResourceName(ResourceMemPercentage)]

    if resourceCoresOK || resourceMemOK || resourceMemPercentageOK {
       if config.DefaultResourceNum > 0 {
          ctr.Resources.Limits[corev1.ResourceName(ResourceName)] = *resource.NewQuantity(int64(config.DefaultResourceNum), resource.BinarySI)
          resourceNameOK = true
       }
    }

    if !resourceNameOK && OverwriteEnv {
       ctr.Env = append(ctr.Env, corev1.EnvVar{
          Name:  "NVIDIA_VISIBLE_DEVICES",
          Value: "none",
       })
    }
    return resourceNameOK, nil
}

首先判断如果 Pod 申请的 Resource 中有对应的 ResourceName 就直接返回 true

_, resourceNameOK := ctr.Resources.Limits[corev1.ResourceName(ResourceName)]
if resourceNameOK {
   return resourceNameOK, nil
}

NVIDIA GPU 对应的 ResourceName 为：

fs.StringVar(&ResourceName, "resource-name", "nvidia.com/gpu", "resource name")

如果 Pod Resource 中申请了这个资源，就需要由 HAMi 进行调度，其他几个 Resource 也是一样的就不细看了。

HAMi 会支持 NVIDIA、天数、华为、寒武纪、海光等厂家的 GPU，默认 ResourceName 为：nvidia.com/gpu、iluvatar.ai/vgpu、hygon.com/dcunum、cambricon.com/mlu、huawei.com/Ascend310 等等

使用这些 ResourceName 时都会有 HAMi-Scheduler 进行调度。

ps：这些 ResourceName 都是可以在对应 device plugin 中进行配置的。

如果没有直接申请nvidia.com/gpu ，但是申请了 gpucore、gpumem 等资源，同时 Webhook 配置的 DefaultResourceNum 大于 0 也会返回 true，并自动添加上 nvidia.com/gpu 资源的申请。

_, resourceCoresOK := ctr.Resources.Limits[corev1.ResourceName(ResourceCores)]
_, resourceMemOK := ctr.Resources.Limits[corev1.ResourceName(ResourceMem)]
_, resourceMemPercentageOK := ctr.Resources.Limits[corev1.ResourceName(ResourceMemPercentage)]

if resourceCoresOK || resourceMemOK || resourceMemPercentageOK {
    if config.DefaultResourceNum > 0 {
       ctr.Resources.Limits[corev1.ResourceName(ResourceName)] = *resource.NewQuantity(int64(config.DefaultResourceNum), resource.BinarySI)
       resourceNameOK = true
    }
}

修改 SchedulerName

对于上述满足条件的 Pod，需要由 HAMi-Scheduler 进行调度，Webhook 中会将 Pod 的 spec.schedulerName 改成 hami-scheduler。

具体如下：

if !hasResource {
    klog.Infof(template+" - Allowing admission for pod: no resource found", req.Namespace, req.Name, req.UID)
    //return admission.Allowed("no resource found")
} else if len(config.SchedulerName) > 0 {
    pod.Spec.SchedulerName = config.SchedulerName
}

这样该 Pod 就会由 HAMi-Scheduler 进行调度了，接下来就是 HAMi-Scheduler 开始工作了。

这里也有一个特殊逻辑：如果创建时直接指定了 nodeName，那 Webhook 就会直接拒绝，因为指定 nodeName 说明 Pod 都不需要调度了，会直接到指定节点启动，但是没经过调度，可能该节点并没有足够的资源。

if pod.Spec.NodeName != "" {
        klog.Infof(template+" - Pod already has node assigned", req.Namespace, req.Name, req.UID)
        return admission.Denied("pod has node assigned")
}

---

【Kubernetes 系列】持续更新中，搜索公众号【探索云原生】订阅，阅读更多文章。

---

3. 小结

该 Webhook 的作用为：将申请了 vGPU 资源的 Pod 的调度器修改为 hami-scheduler，后续使用 hami-scheduler 进行调度。

也存在一些特殊情况：

• 对于开启特权模式的 Pod Webhook 会忽略，不会将其切换到 hami-scheduler 进行调度，而是依旧使用 default-scheduler。

• 对于直接指定了 nodeName 的 Pod, Webhook 会直接拒绝，拦截掉 Pod 的创建。

基于以上特殊情况，可能会出现以下问题，也是社区中多次有同学反馈的：

特权模式 Pod 申请了 gpucore、gpumem 等资源，创建后一直处于 Pending 状态， 无法调度，提示节点上没有 gpucore、gpumem 等资源。

因为 Webhook 直接跳过了特权模式的 Pod，所以该 Pod 会使用 default-scheduler 进行调度，然后 default-scheduler 根据 Pod 中的 ResourceName 查看时发现没有任何 Node 有 gpucore、gpumem 等资源，因此无法调度，Pod 处理 Pending 状态。

ps：gpucore、gpumem 都是虚拟资源，并不会展示在 Node 上，只有 hami-scheduler 能够处理。

HAMi Webhook 工作流程如下：

• 1）用户创建 Pod 并在 Pod 中申请了 vGPU 资源

• 2）kube-apiserver 根据 MutatingWebhookConfiguration 配置请求 HAMi-Webhook

• 3）HAMi-Webhook 检测 Pod 中的 Resource，发现是申请的由 HAMi 管理的 vGPU 资源，因此把 Pod 中的 SchedulerName 改成了 hami-scheduler，这样这个 Pod 就会由 hami-scheduler 进行调度了。

  • 对于特权模式的 Pod，Webhook 会直接跳过不处理

  • 对于使用 vGPU 资源但指定了 nodeName 的 Pod，Webhook 会直接拒绝

• 4）接下来则进入 hami-scheduler 调度逻辑，下篇分析~

至此，我们就搞清楚了，为什么 Pod 会使用上 hami-scheduler 以及哪些 Pod 会使用 hami-scheduler 进行调度。 同时也说明了为什么特权模式 Pod 会无法调度的问题。

接下来就开始分析 hami-scheduler 实现了。