4. Kubernetes 原生调度器扩展：调度框架与自定义调度器开发

Kubernetes 原生调度器（kube-scheduler）在 v1.19 之后引入了 调度框架（Scheduling Framework），将调度流程拆解为多个可插拔的扩展点。这一架构变革使得调度策略的定制不再需要 Fork 整个调度器代码，而是通过实现特定扩展点的插件来注入自定义逻辑。对于跨集群调度与 OPA 集成的安全审计场景，理解调度框架是构建变更门禁的基础。

4.1 调度框架（Scheduling Framework）概述

调度框架将一次 Pod 调度决策分解为两个阶段：Scheduling Cycle 和 Binding Cycle。Scheduling Cycle 为 Pod 选择一个合适的 Node，Binding Cycle 将决策结果持久化到 API Server。两个阶段之间通过内部队列和缓存解耦，框架提供了 11 个扩展点供插件注册。

4.2 核心扩展点详解

每个扩展点对应调度流程中的一个特定阶段，插件可以注册到多个扩展点。下表列出了与安全审计和跨集群调度最相关的扩展点及其典型用途：

4.3 自定义调度器开发基础

基于调度框架开发自定义调度器，本质上是编写一个或多个实现了特定扩展点接口的插件，并通过 scheduler-config 配置文件将其注册到调度器中。开发流程分为三步：

1. 实现插件接口：根据目标扩展点实现对应的 Go 接口（如 FilterPlugin、ScorePlugin）。
2. 注册插件：在调度器启动时通过 runtime.Registry 注册插件实例。
3. 配置调度器：通过 YAML 配置文件指定启用哪些插件及其顺序。

以下是一个最小化的 Filter 插件代码骨架，展示了如何集成外部策略引擎：

package securityaudit

import (
    "context"
    "fmt"
    v1 "k8s.io/api/core/v1"
    "k8s.io/kubernetes/pkg/scheduler/framework"
)

// AuditFilterPlugin 实现 FilterPlugin 接口
type AuditFilterPlugin struct {
    opaClient *OPAClient // 假设的 OPA 客户端
}

// Name 返回插件名称
func (pl *AuditFilterPlugin) Name() string {
    return "SecurityAuditFilter"
}

// Filter 在调度周期中过滤 Node
func (pl *AuditFilterPlugin) Filter(ctx context.Context, state *framework.CycleState, pod *v1.Pod, nodeInfo *framework.NodeInfo) *framework.Status {
    // 1. 提取 Pod 和 Node 的审计上下文
    podLabels := pod.GetLabels()
    nodeName := nodeInfo.Node().GetName()

    // 2. 调用 OPA 策略引擎评估
    allowed, reason, err := pl.opaClient.Evaluate(podLabels, nodeName)
    if err != nil {
        return framework.NewStatus(framework.Error, fmt.Sprintf("OPA evaluation failed: %v", err))
    }
    if !allowed {
        return framework.NewStatus(framework.Unschedulable, fmt.Sprintf("Denied by security policy: %s", reason))
    }

    // 3. 通过策略检查
    return framework.NewStatus(framework.Success, "")
}

// 注册插件到调度器框架
func NewAuditFilterPlugin(obj runtime.Object, handle framework.Handle) (framework.Plugin, error) {
    client := NewOPAClient("http://opa-service:8181/v1/data/kubernetes/authz")
    return &AuditFilterPlugin{opaClient: client}, nil
}

4.4 调度器配置与插件注册

自定义插件开发完成后，需要通过 KubeSchedulerConfiguration 配置文件启用。以下是一个启用安全审计 Filter 插件和自定义 Score 插件的配置示例：

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
  - schedulerName: security-aware-scheduler
    plugins:
      filter:
        enabled:
          - name: "SecurityAuditFilter"   # 安全审计 Filter 插件
          - name: "NodeResourcesFit"      # 保留内置插件
        disabled:
          - name: "NodeUnschedulable"     # 可选禁用某些内置插件
      score:
        enabled:
          - name: "ComplianceScore"       # 自定义合规评分插件
          - name: "NodeResourcesBalancedAllocation"
        disabled: []
    pluginConfig:
      - name: "SecurityAuditFilter"
        args:
          opaEndpoint: "http://opa-service:8181/v1/data/kubernetes/authz"
          timeoutSeconds: 5
      - name: "ComplianceScore"
        args:
          weight: 30
          complianceDataPath: "/etc/scheduler/compliance.json"

4.5 扩展点选择策略：同步 vs 异步

在安全审计场景中，选择哪个扩展点集成 OPA 策略评估，取决于对调度延迟和审计严格性的要求：

4.6 跨集群调度中的扩展点适配

在跨集群调度场景下，调度器需要感知多个集群的状态。自定义扩展点需要额外处理以下问题：

• 集群抽象：将每个集群视为一个“超级 Node”，Filter 插件检查集群级别的策略合规性，Score 插件基于集群整体负载和成本打分。
• 网络延迟：跨集群 API 调用延迟远高于单集群。建议在 PreFilter 中批量拉取集群状态缓存，避免在 Filter/Score 中频繁发起远程调用。
• 一致性保证：Permit 扩展点可用于实现两阶段提交：先预留目标集群的资源，待审批通过后再执行 Bind。这需要自定义 Bind 插件与集群代理交互。
• 审计日志聚合：在 PostBind 扩展点中，将调度决策（包括 OPA 评估结果、最终选择的集群、时间戳）写入统一的审计日志系统，便于事后追溯。