Kubernetes 学习与面试

Informer 和 WorkQueue 解决哪两个工程问题

Controller 每次 Reconcile 都要读取当前的期望状态和实际状态，但不能因此为每个对象高频轮询 API Server；对象变化也不能直接在 Watch 回调中执行耗时业务，否则一个慢操作会阻塞后续事件分发。

Informer 负责通过 List/Watch 维护本地对象视图并发出轻量通知；WorkQueue 负责保存待处理对象的 key，由 worker 控制并发、失败重试和退避。Reconcile 再根据 key 读取当前状态并执行真正的业务逻辑。

官方资料：Kubernetes Controllers · client-go cache / SharedInformer · client-go workqueue

Reflector 职责

Reflector 是 Informer 和 API Server 之间的数据同步器，核心逻辑是 List + Watch 循环：

1. 首次 List（全量同步）：启动时先调用 List API 获取该资源类型的一致对象快照（支持分页），记录返回的 resourceVersion，再通过 Replace 把列表交给 DeltaFIFO；当前 client-go 通常使用 Replaced delta 表达这次全量替换。
2. 持续 Watch（增量监听）：从 List 返回的 resourceVersion 开始调用 Watch API，接收 ADD/UPDATE/DELETE 事件，每个事件作为一个 Delta 推入 DeltaFIFO。
3. 断线重连：Watch 连接断开（网络错误、服务端超时）后，用最后一次收到的 resourceVersion 重新 Watch。如果 resourceVersion 太旧已被 etcd compact（"too old resource version"），则重新执行 List 全量同步。
4. 定期 Resync：按 resyncPeriod 周期将 Indexer 中的所有对象重新放入 DeltaFIFO（Sync delta），触发 ResourceEventHandler 的 OnUpdate 回调，让 Controller 有机会重新 reconcile 即使没有发生实际变化。

// Reflector 主循环（简化）
func (r *Reflector) ListAndWatch(stopCh <-chan struct{}) error {
    // 1. List：全量同步
    list, err := r.listerWatcher.List(options)
    if err != nil { return err }
    listMeta, _ := meta.ListAccessor(list)
    resourceVersion = listMeta.GetResourceVersion()
    r.replace(takeItems(list), resourceVersion) // 全量 Replace，通常产生 Replaced delta

    // 2. Watch：持续增量
    for {
        w, err := r.listerWatcher.Watch(options)
        if err != nil { return err }
        r.watchHandler(w, &resourceVersion, resyncerrc, stopCh)
        // 3. 重连逻辑：如果是 "too old resource version" 错误，重新 List
    }
}

DeltaFIFO 结构

DeltaFIFO 是一个生产-消费队列，存储的不是对象本身，而是 Delta（对象 + 变更类型）：

type Delta struct {
    Type   DeltaType  // Added / Updated / Deleted / Sync
    Object interface{}
}

// DeltaFIFO 的 key 是对象的 namespace/name
// 每个 key 对应一个 []Delta（按时间有序）
type DeltaFIFO struct {
    items map[string][]Deltas  // key → delta 列表
    queue []string             // FIFO 队列的 key 顺序
    // ... lock, cond, knownObjects (Indexer)
}

Indexer 设计

Indexer 是 Informer 的线程安全本地缓存，避免 Controller 每次查询都访问 API Server（会打爆 API Server 和 etcd）：

• Thread-safe：使用读写锁保护，支持多 goroutine 并发 Get/List，写操作（来自 DeltaFIFO 消费者）单线程更新。
• 索引（Index）：支持多种索引函数加速查询，默认有 namespace 索引，用户可注册自定义索引（如按 label selector、nodeName 等）。
• API 风格：Get(key)、List()、ListByIndex(indexName, indexValue)、GetByKey(key)。
• 和 API Server 的一致性：本地缓存最终一致（eventual consistency），Watch 事件有极短延迟。需要强一致读时仍需 GET API Server（但大多数 Controller 场景不需要）。

// 典型的 Indexer 用法（在 Reconcile 中）
func (c *Controller) syncHandler(key string) error {
    // 从本地缓存获取，不访问 API Server
    obj, exists, err := c.indexer.GetByKey(key)
    if err != nil { return err }
    if !exists {
        // 对象已删除：清理外部资源
        return c.cleanupExternalResources(key)
    }
    pod := obj.(*corev1.Pod)
    // ... reconcile 逻辑
}

RateLimitingQueue 核心接口

WorkQueue 是 Controller 并发控制和重试的核心组件：

type RateLimitingInterface interface {
    DelayingInterface
    AddRateLimited(item interface{})  // 按速率限制添加（退避重试）
    Forget(item interface{})          // 清除该 item 的重试计数（处理成功后调用）
    NumRequeues(item interface{}) int // 查询该 item 重试了多少次
}

type DelayingInterface interface {
    Interface
    AddAfter(item interface{}, duration time.Duration) // 延迟添加
}

type Interface interface {
    Add(item interface{})
    Get() (item interface{}, shutdown bool)
    Done(item interface{})   // 处理完成后必须调用！
    Len() int
    ShutDown()
    ShuttingDown() bool
}

标准 Controller 工作循环

func (c *Controller) Run(workers int, stopCh <-chan struct{}) {
    // 1. 等待本地缓存同步完成（Informer HasSynced）
    if !cache.WaitForCacheSync(stopCh, c.podSynced) {
        return
    }
    // 2. 启动 N 个 worker goroutine
    for i := 0; i < workers; i++ {
        go wait.Until(c.runWorker, time.Second, stopCh)
    }
    <-stopCh
}

func (c *Controller) runWorker() {
    for c.processNextWorkItem() {}
}

func (c *Controller) processNextWorkItem() bool {
    // Get 阻塞取一个 key
    key, quit := c.workqueue.Get()
    if quit { return false }

    // Done 必须在 Get 之后调用（defer 最安全）
    defer c.workqueue.Done(key)

    // 执行 reconcile
    err := c.syncHandler(key.(string))
    c.handleErr(err, key)
    return true
}

func (c *Controller) handleErr(err error, key interface{}) {
    if err == nil {
        // 处理成功：清除重试计数
        c.workqueue.Forget(key)
        return
    }
    // 处理失败：退避重试（不 Forget，计数累积）
    // 超过最大重试次数后 Forget，避免无限重试
    if c.workqueue.NumRequeues(key) < c.maxRetries {
        c.workqueue.AddRateLimited(key)
        return
    }
    c.workqueue.Forget(key)
    utilruntime.HandleError(err)
}

请求处理五阶段

所有发往 API Server 的 REST 请求（kubectl、client-go、controller、kubelet）都经过同一条处理链：

HTTP Request
  │
  ├─ 1. Authentication（认证）
  │     → 你是谁？从请求中提取身份信息（user/group）
  │     → 失败返回 401 Unauthorized
  │
  ├─ 2. Authorization（鉴权）
  │     → 你有权限做这个操作吗？RBAC/ABAC/Node/Webhook
  │     → 失败返回 403 Forbidden
  │
  ├─ 3. Admission Control（准入控制）
  │     → 修改/校验对象，执行语义策略
  │     a. Mutating Webhooks（可修改对象）
  │     b. Object Schema Validation（内置校验）
  │     c. Validating Webhooks（只能批准/拒绝）
  │     → 失败返回 403/422
  │
  ├─ 4. Validation（验证）
  │     → 内置字段校验（格式、必填字段、immutable 字段）
  │     → CRD 有 OpenAPI schema 校验
  │     → 失败返回 422 Unprocessable Entity
  │
  └─ 5. Storage（持久化）
        → 写入 etcd（RESTStorage → etcd3 storage backend）
        → 触发 watch 事件通知所有 watcher
        → 返回结果给客户端

注意：读请求（GET/LIST/WATCH）经过认证和鉴权，但跳过 Admission 和 Validation（Webhook 可以配置对读请求生效，但通常不这么做）。

鉴权模式

API Server 支持多种鉴权模式并行启用（--authorization-mode=...,..），任一通过则放行：

生产环境推荐：--authorization-mode=Node,RBAC

Admission Control 架构

Admission 是可扩展的策略执行点，在对象持久化到 etcd 之前运行。分为两类：

1. Mutating Admission（变更准入）：可以修改请求中的对象（添加默认值、注入 sidecar、设置 label 等）。
2. Validating Admission（验证准入）：只能批准或拒绝请求，不能修改对象。

请求对象 → [Mutating Webhooks（顺序调用，顺序不应作为契约依赖）] → 对象可能已被修改
         → [内置 Validating Admission]
         → [Validating Webhooks（并行调用）] → 汇总为通过/拒绝

重要：Mutating Webhook 在 Validating Webhook 之前执行。Mutating 修改过的最终对象会再进入验证阶段。Mutating Webhook 顺序调用，但官方明确建议不要依赖固定调用顺序；启用 reinvocationPolicy: IfNeeded 后，已经执行过的 Mutating Webhook 还可能被重新调用。Validating Webhook 不修改对象，因此可以并行调用，只要任意一个拒绝，请求就不能持久化。

Watch 实现细节

Watch 是 K8s Controller 模式的基础，API Server 对 Watch 请求的处理：

• HTTP chunked transfer：Watch 响应是一个长连接 HTTP/1.1 chunked 响应（或 HTTP/2 stream），每个事件作为一个 JSON chunk 发送。
• Cacher（API Server 内的 watch cache）：API Server 为每个资源类型维护一个基于 etcd watch 的环形缓存（watch cache），List 请求默认从缓存读（resourceVersion=0），Watch 请求从缓存中推送事件，减轻 etcd 直接压力。
• Bookmark events：API Server 周期性发送 bookmark 事件（仅包含 resourceVersion），客户端可以用它更新 lastSeenResourceVersion 而无需处理完整对象，加速重连。
• resourceVersion 语义：list 返回 resourceVersion，watch 从该版本开始，支持从历史版本重放（在 watch cache 窗口内）。

GET /api/v1/namespaces/default/pods?watch=1&resourceVersion=12345
→ HTTP 200 OK, Content-Type: application/json, Transfer-Encoding: chunked

{"type":"ADDED","object":{...,"metadata":{"resourceVersion":"12350"}}}
{"type":"MODIFIED","object":{...,"metadata":{"resourceVersion":"12351"}}}
{"type":"DELETED","object":{...,"metadata":{"resourceVersion":"12355"}}}
{"type":"BOOKMARK","object":{"metadata":{"resourceVersion":"12399"}}}
...

resourceVersion 与 CAS

K8s 使用乐观并发控制（Optimistic Concurrency Control）处理并发更新，避免显式锁：

1. 客户端 GET 对象，获取当前的 metadata.resourceVersion。
2. 客户端修改对象，UPDATE/PATCH 请求携带该 resourceVersion。
3. API Server 解析对象，检查 storage（etcd）中当前对象的 mod_revision 是否匹配客户端的 resourceVersion。
4. 匹配则写入成功，resourceVersion 更新为新的更高值。
5. 不匹配则返回 409 Conflict，客户端必须重新 GET、应用变更、重试。

// 使用 client-go 的 retry.RetryOnConflict 处理乐观冲突
retryErr := retry.RetryOnConflict(retry.DefaultRetry, func() error {
    // 每次重试前重新 GET 最新版本
    deployment, err := clientset.AppsV1().Deployments("default").Get(ctx, "nginx", metav1.GetOptions{})
    if err != nil { return err }

    // 应用变更
    deployment.Spec.Replicas = int32Ptr(5)

    // 尝试 UPDATE
    _, err = clientset.AppsV1().Deployments("default").Update(ctx, deployment, metav1.UpdateOptions{})
    return err
})

注意：PATCH（尤其是 strategic merge patch 和 JSON patch）和 UPDATE 的冲突处理不同——PATCH 可以在不指定 resourceVersion 的情况下执行，但有自己的 merge 语义；Server-Side Apply（SSA）通过 managedFields 做字段级别的冲突检测。

etcd 在 K8s 中的位置

API Server 是唯一直接读写 etcd 的组件。所有 K8s 资源对象（Pod、Deployment、Node、ConfigMap 等）都以 /registry/<resource>/<namespace>/<name> 的 key 格式存储在 etcd 中。etcd 负责一致性、持久化和通知分发，API Server 负责认证鉴权、版本转换和语义校验。

Raft 核心：Leader 选举

Raft 将一致性问题拆分为三个子问题：Leader 选举、日志复制、安全性。选举机制基于 term（任期） 和 心跳：

1. 初始状态：所有节点为 Follower，等待 Leader 心跳（默认 100ms）。
2. 选举触发：Follower 在随机 election timeout（150-300ms）内没收到心跳，转为 Candidate，term+1，给自己投票，向其他节点发 RequestVote RPC。
3. 投票规则：每个 term 每个节点只能投一票，先到先得；Candidate 必须包含自己的最后一条日志的 term 和 index，接收者只会投票给日志至少和自己一样新的 Candidate。
4. 当选 Leader：获得多数派（quorum = (n/2)+1）投票后成为 Leader，立即发心跳抑制其他选举。
5. Leader 故障：心跳中断，Follower 发起新选举，term 增加。

MVCC 原理

etcd 使用 MVCC 实现非阻塞读和乐观并发控制。每次写操作（PUT/DELETE）都会创建一个新的 key-value 版本，而不是原地覆盖：

初始: revision=1
PUT /registry/pods/default/pod-a → revision=2, mod_revision=2, version=1
PUT /registry/pods/default/pod-a → revision=3, mod_revision=3, version=2
DELETE /registry/pods/default/pod-a → revision=4 (tombstone)
PUT /registry/pods/default/pod-a → revision=5, create_revision=5, mod_revision=5, version=1

Watch 工作原理

Watch 是 etcd 支撑 K8s 声明式控制循环的核心能力。客户端通过 Watch(key, opts...) 建立长连接（gRPC stream），接收后续发生的变更事件。

Watch 事件历史保存在 etcd 的 watch cache（环形缓冲区）中。如果客户端请求的 revision 已被 compact，etcd 会返回 compaction revision error，客户端必须重新 List 获取全量数据，再从新的 resourceVersion 开始 watch。这就是 K8s 中 "too old resource version" 错误的来源。

etcd 与 K8s 对象的映射

K8s 资源对象的 etcd key 格式：
/registry/<resource-plural>/<namespace>/<name>

示例：
/registry/pods/default/nginx-6799fc88d8-2xk4z
/registry/deployments/kube-system/coredns
/registry/nodes/node-1
/registry/configmaps/kube-system/kube-proxy

集群范围资源没有 namespace 段：
/registry/clusterroles/cluster-admin
/registry/namespaces/default

调度问题定位：区分 Pod 属性、调度阶段和调度机制

在分析 Kubernetes Scheduler 时，需要区分三类概念，这三类概念不能混在一起：

1. Pod 属性：Pod 自身携带的信息，例如优先级、资源请求、节点选择约束等。
2. 调度阶段 / 扩展点：Scheduler Framework 中处理 Pod 的流程位置，例如 QueueSort、Filter、Score、Reserve、Permit。
3. 调度机制 / 策略：由多个阶段共同完成的行为，例如抢占、退避重试、Gang 调度、回填调度等。

例如，priority 是 Pod 的属性，它会影响队列排序和抢占，但它本身不是调度阶段。Preemption 是调度失败后的抢占机制，通常发生在没有可行节点之后，和 PostFilter 等流程有关，但它也不是普通的节点打分阶段。QueueSort、Filter、Score、Reserve、Permit 才是 Scheduler Framework 中更明确的扩展点。

Cache 与 API Server 暂时不一致时如何收敛

Scheduler Cache 是基于 Informer 事件维护的低延迟视图，不是跨 API Server、节点和外部 scheduler 的强一致事务。默认 scheduler 依靠单 Leader、Cache 顺序更新、Assume 提前记账和绑定结果回流，把常见竞态限制在可恢复范围内。

这种设计保证的是在标准单活 scheduler 模型下最终收敛，不是任意并发写入下的全局串行化。如果多个独立 scheduler 或外部组件同时分配同一批 Node 资源，它们必须共享 Reservation/Claim 协议或划分互斥资源池，不能只依赖各自 Cache。

Plugin 扩展点与调度研究问题的映射

Scheduler 性能与扩展性

大规模集群（数千节点、数万 Pod）中，scheduler 的性能直接决定 Pod 启动延迟。面试中要能说清楚关键性能参数和优化手段。

六维设计目标

Node Affinity / Anti-Affinity 与 Pod Affinity / Anti-Affinity

这里有三组概念容易混：Node Affinity、Node Anti-Affinity、Pod Affinity / Pod Anti-Affinity。核心区别：

Node Affinity / Anti-Affinity：Pod 和节点之间的关系。Pod Affinity / Anti-Affinity：Pod 和 Pod 之间的关系。

NodeAffinity 在两个扩展点上的不同行为

NodeAffinity 同时挂在 Filter（处理 Required）和 Score（处理 Preferred）两个扩展点上。这是"硬约束 vs 软偏好"在调度框架里的标准落地方式。

三种 Effect 的语义、扩展点和触发对象

Filter 阶段：装得下吗

NodeResourcesFit 在 Filter 阶段判断节点可用资源是否能装下 Pod 的 requests。逻辑很直接：对每个资源类型（CPU、Memory、扩展资源），检查 node.Allocatable - sum(running pods.requests) ≥ pod.requests。

Extender 是什么、和 Plugin 的关系

Extender 是 K8s 早期的扩展机制，核心是一个独立 HTTP 服务，scheduler 在 Filter / Prioritize / Bind 等阶段通过 HTTP 调用它。

抢占体现的设计哲学

• 声明式：用户通过 PriorityClass 表达"重要程度"，不需要写抢占代码。
• 公平性：抢占只能"高优抢低优"，避免同优先级互抢；PDB 限制驱逐范围。
• 异步退出：设置 nominatedNodeName 后等待 victim graceful shutdown，而不是立刻杀掉，保证服务连续性。
• 可扩展性：抢占决策在 PostFilter 扩展点，自定义 Plugin 可以替换默认抢占逻辑（例如考虑 GPU checkpoint 新鲜度）。

核心差异表

自定义 Scheduler Plugin 实战

自定义调度逻辑可以运行在 kube-scheduler 进程内、进程外 Extender，或独立 scheduler 中。三种方式能接入的生命周期、状态视图和故障边界不同。

Scheduling Framework Plugin 开发详解

Scheduler Framework 定义了从 Pod 入队到绑定的完整生命周期，每个阶段都是一个扩展点（Extension Point）。开发自定义插件就是实现一个或多个扩展点接口。

package main

import (
    "os"

    "k8s.io/component-base/cli"
    "k8s.io/kubernetes/cmd/kube-scheduler/app"
    "example.com/scheduler/pkg/myplugin"
)

func main() {
    cmd := app.NewSchedulerCommand(
        app.WithPlugin(myplugin.Name, myplugin.New),
    )
    os.Exit(cli.Run(cmd))
}

apiVersion: kubescheduler.config.k8s.io/v1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: gpu-scheduler
  plugins:
    filter:
      enabled:
      - name: MyGPUPlugin
    score:
      enabled:
      - name: MyGPUPlugin
        weight: 5
  pluginConfig:
  - name: MyGPUPlugin
    args:
      maxMetricAgeSeconds: 15

案例：AIJob 驱动的预测调度插件

面试官常追问："如果让你做一个预测调度器，既预测任务运行时间，又预测多个任务共置时的干扰程度，你怎么落到 Kubernetes Scheduler Framework 里？" 推荐统一回答成 AIJob CRD + AIJob Operator + Scheduler Plugin 三层架构：AIJob 表达深度学习任务，AIJob Operator 管生命周期和预测子控制器，scheduler plugin 只读辅助 CRD。

③ PredictionResult 的生命周期与消费路径

PredictionResult 不是用户手写的主资源，而是 AIJob Operator 为调度器准备的辅助状态。它的核心作用是把“深度学习任务画像”转换成 scheduler plugin 能低延迟读取的结构化字段。

func (r *AIJobReconciler) reconcilePrediction(ctx context.Context, job *aiv1.AIJob) error {
    // 1. 从 AIJob spec 提取任务画像：模型、batch size、GPU、replica、checkpoint。
    features := buildFeatures(job.Spec)

    // 2. 调用预测模块；这是控制面异步逻辑，不在 scheduler 热路径。
    pred := r.predictor.Predict(ctx, features)

    // 3. Upsert PredictionResult，并通过 ownerReference 绑定 AIJob 生命周期。
    result := buildPredictionResult(job, pred)
    if err := controllerutil.SetControllerReference(job, result, r.Scheme); err != nil {
        return err
    }
    return r.Client.Status().Update(ctx, result)
}

④ 各扩展点职责与 Go 骨架

下面代码只展示关键路径。真实实现中还需要错误处理、metrics、并发保护、feature gate 和配置化权重。

QueueSort：预测运行时间只做第三排序键

func (pl *PredictivePlugin) Less(p1, p2 *framework.QueuedPodInfo) bool {
    // 1. PriorityClass 仍然是第一优先级，避免预测策略破坏 K8s 语义。
    if *p1.Pod.Spec.Priority != *p2.Pod.Spec.Priority {
        return *p1.Pod.Spec.Priority > *p2.Pod.Spec.Priority
    }

    // 2. 租户公平性第二优先级，QAD 越低表示越需要补偿资源。
    qad1 := pl.fairness.QAD(p1.Pod.Namespace)
    qad2 := pl.fairness.QAD(p2.Pod.Namespace)
    if qad1 != qad2 {
        return qad1 < qad2
    }

    // 3. 运行时间预测来自 AIJob 对应的 PredictionResult，本地 cache 读取。
    rt1 := pl.predStore.RuntimeSeconds(jobUID(p1.Pod))
    rt2 := pl.predStore.RuntimeSeconds(jobUID(p2.Pod))
    if rt1 != rt2 {
        return rt1 < rt2
    }

    // 4. 最后用入队时间打破平局，避免不稳定排序。
    return p1.Timestamp.Before(p2.Timestamp)
}

PreFilter：把 CRD 预测值写入 CycleState

func (pl *PredictivePlugin) PreFilter(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
) (*framework.PreFilterResult, *framework.Status) {
    pred := pl.predStore.GetByJobUID(jobUID(pod))
    if pred == nil {
        // 冷启动兜底：AIJob 还没有 PredictionResult 时走保守策略。
        pred = conservativePrediction(pod)
    }

    // CycleState 只在本次 scheduling cycle 内有效，避免后续阶段重复查 CRD cache。
    state.Write(stateKeyPrediction, &PodPredictionState{
        RuntimeSeconds:      pred.RuntimeSeconds,
        JobSignature:        pred.JobSignature,
        MinRetention:        pred.MinRetention,
        InterferenceProfile: pred.InterferenceProfile,
    })
    return nil, framework.NewStatus(framework.Success)
}

Filter：共置干扰超过阈值就拒绝节点

func (pl *PredictivePlugin) Filter(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeInfo *framework.NodeInfo,
) *framework.Status {
    pred := readPredictionState(state)
    nodeName := nodeInfo.Node().Name
    nodeProfile := pl.nodeProfileStore.Get(nodeName)

    // 节点画像缺失时走保守策略：Guaranteed 任务拒绝共置，BestEffort 可降级打分。
    if nodeProfile == nil && isGuaranteed(pod) {
        return framework.NewStatus(framework.Unschedulable, "missing NodeGpuProfile")
    }

    retention := minPredictedRetention(pred, nodeProfile.ColocatedJobSignatures)
    if retention < pred.MinRetention {
        return framework.NewStatus(
            framework.Unschedulable,
            fmt.Sprintf("predicted retention %.2f below threshold %.2f", retention, pred.MinRetention),
        )
    }
    return framework.NewStatus(framework.Success)
}

Score：在可行节点里选择更低干扰、更好装箱的节点

func (pl *PredictivePlugin) Score(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) (int64, *framework.Status) {
    pred := readPredictionState(state)
    nodeProfile := pl.nodeProfileStore.Get(nodeName)

    // interferenceScore 越高表示共置越安全。
    retention := minPredictedRetention(pred, nodeProfile.ColocatedJobSignatures)
    interferenceScore := int64(retention * 100)

    // MostAllocated 风格：优先填补已有 GPU 利用率较高但仍安全的节点。
    binPackScore := int64(nodeProfile.GPUUtilization * 100)
    topologyScore := pl.topology.Score(pod, nodeName)

    score := interferenceScore*5 + binPackScore*2 + topologyScore*3
    return normalize(score), framework.NewStatus(framework.Success)
}

Reserve / Unreserve：维护插件自己的共置账本

func (pl *PredictivePlugin) Reserve(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) *framework.Status {
    pred := readPredictionState(state)
    // scheduler cache 只知道整数资源；共置 signature 账本由插件自己维护。
    pl.ledger.Add(nodeName, pod.UID, pred.JobSignature)
    return framework.NewStatus(framework.Success)
}

func (pl *PredictivePlugin) Unreserve(
    ctx context.Context,
    state *framework.CycleState,
    pod *v1.Pod,
    nodeName string,
) {
    // Bind / Permit / PreBind 失败时必须回滚，避免后续 Pod 看到假的共置状态。
    pl.ledger.Remove(nodeName, pod.UID)
}

QueueingHint 的设计

QueueingHint 让每个 Plugin 通过实现 EnqueueExtensions 接口告诉 scheduler：

1. 我关心哪些事件类型：例如 NodeAffinity 关心 Node 增删和 Node Label 更新；NodeResourcesFit 关心 Node 增删和 Node 资源量更新；TaintToleration 关心 Node Taint 变化。
2. 事件发生时，能不能让这个 Pod 重新有机会：返回 QueueingHint 的三种值：

Move Request 来源

Move Request（也叫 cluster event）是 scheduler 内部抽象，统一表达"集群中发生了某种可能影响 Pending Pod 的变化"。下面是触发 Move Request 的全部来源：

是什么、为什么需要

kube-scheduler-simulator（sig-scheduling 官方维护，github.com/kubernetes-sigs/kube-scheduler-simulator）是一个本地 scheduler + Web UI，能在不动生产集群的前提下：

1. 导入快照：把生产集群的 Node / Pod / PVC / PriorityClass 等对象一键导入。
2. 重放调度：用同一份 KubeSchedulerConfiguration 跑一遍调度，看每个 Pod 在哪些 Plugin 失败、得分如何。
3. Mock Plugin：支持注入 mock 插件，可以预设某个 Plugin 在某个节点上的返回值，用来构造极端场景。
4. 新插件验证：开发自定义 Plugin 时，先在 simulator 上跑通，再部署到 staging。

findNodesThatFitPod 返回的诊断数据

当一个 Pod 调度失败，findNodesThatFitPod() 会返回 framework.Diagnosis，描述"为什么没找到合适节点"。这是 kubectl describe pod 里 FailedScheduling 事件背后的数据源。

scheduler 核心 metrics 全景

固定阈值不能跨集群照搬。在线服务、批任务和稀缺 GPU 队列的正常等待时间差异很大，应以目标集群基线、业务启动 SLO、profile 和 PriorityClass 分层告警。

CNI（Container Network Interface）是什么

CNI 是 CNCF 维护的容器网络标准化接口，定义了容器运行时如何调用网络插件为容器配置网络。核心设计极简：插件是可执行文件，通过 stdin/stdout 传递 JSON 配置和结果，不引入守护进程依赖（数据面可以有 daemon，接口本身只需要二进制）。

# CNI 插件调用示例（ADD 操作）
# 容器运行时通过环境变量和 stdin 传参：
CNI_COMMAND=ADD
CNI_CONTAINERID=<container-id>
CNI_NETNS=/var/run/netns/<netns-path>
CNI_IFNAME=eth0
CNI_PATH=/opt/cni/bin

# stdin 传入网络配置 JSON
cat <<'EOF' | CNI_COMMAND=ADD CNI_CONTAINERID=abc123 \
  CNI_NETNS=/var/run/netns/cni-abc123 CNI_IFNAME=eth0 \
  CNI_PATH=/opt/cni/bin /opt/cni/bin/bridge
{
  "cniVersion": "0.4.0",
  "name": "mynet",
  "type": "bridge",
  "bridge": "cni0",
  "ipam": {
    "type": "host-local",
    "subnet": "10.244.0.0/16"
  }
}
EOF

Pod IP 从哪来：IPAM

IPAM（IP Address Management）是 CNI 的子插件，负责 IP 地址分配和释放：

• host-local：每个节点从配置的 subnet 中分配 IP，本地文件存储分配记录（/var/lib/cni/networks/），节点间 subnet 不重叠，不依赖中心化存储。
• dhcp：从外部 DHCP 服务器获取 IP（较少用）。
• Calico IPAM：使用 etcd 或 CRD 存储 IP 分配，支持更灵活的 IP pool、block 分配（按 block 聚合路由）。
• Cilium IPAM：支持多种模式（cluster-wide、hostscope、CRD-based），可对接云厂商 ENI 做 IP 直通。

# CNI 配置中指定 IPAM
{
  "name": "k8s-pod-network",
  "cniVersion": "0.4.0",
  "plugins": [
    {
      "type": "calico",  # 主 CNI
      "ipam": {"type": "calico-ipam"}
    },
    {"type": "portmap"},  # 附加插件：端口映射
    {"type": "bandwidth"} # 附加插件：带宽限制
  ]
}

kube-proxy 三种模式

kube-proxy 负责实现 Service 的虚拟 IP（ClusterIP）负载均衡。它监听 API Server 中 Service 和 Endpoint/EndpointSlice 的变化，编程节点的网络规则：

Service 类型

# Headless Service 示例（StatefulSet 常用）
apiVersion: v1
kind: Service
metadata:
  name: mysql
spec:
  clusterIP: None  # Headless
  selector:
    app: mysql
  ports:
  - port: 3306
# nslookup mysql → 返回所有 Pod IP 列表，客户端直连 Pod

# ExternalName Service
apiVersion: v1
kind: Service
metadata:
  name: ext-db
spec:
  type: ExternalName
  externalName: db.example.com
# nslookup ext-db → CNAME db.example.com，kube-proxy 不处理

kubelet 启动与节点注册

新节点加入集群的完整流程：

1. kubelet 启动：读取 kubeconfig（或 bootstrap kubeconfig），有有效证书则直接加入；没有则进入 TLS Bootstrap 流程。
2. TLS Bootstrap：kubelet 使用 bootstrap token（在 kube-system namespace 的 bootstrap token secret 中）创建 CertificateSigningRequest（CSR）。
3. CSR 审批：管理员手动审批（kubectl certificate approve）或配置 controller 自动审批（需要正确的 Group 权限）。
4. 证书签发：API Server 签发 kubelet client 证书，kubelet 将证书和 key 存储到 --cert-dir（默认 /var/lib/kubelet/pki/）。
5. 创建 Node 对象：kubelet 使用自己的证书向 API Server 创建 Node 对象（或更新已有），Node 对象的 metadata.name 默认是主机名（--hostname-override 可覆盖）。
6. Node Authorization：Node authorizer 限制每个 kubelet 只能修改自己的 Node 对象、只能读写自己节点上的 Pod/Service/Secret/PV 等资源，防止 kubelet 越权。

# Bootstrap kubeconfig 示例
apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://api-server:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: tls-bootstrap-token-user
  name: tls-bootstrap
current-context: tls-bootstrap
users:
- name: tls-bootstrap-token-user
  user:
    token: 07401b.f395accd246ae52d  # bootstrap token: .

Node Conditions

Node 对象的 status.conditions 描述节点健康状态：

# Node status 片段
status:
  conditions:
  - type: Ready
    status: "True"
    lastHeartbeatTime: "2024-01-15T10:30:00Z"
    lastTransitionTime: "2024-01-01T00:00:00Z"
    reason: "KubeletReady"
    message: "kubelet is posting ready status"
  - type: MemoryPressure
    status: "False"
  - type: DiskPressure
    status: "False"
  addresses:
  - type: InternalIP
    address: 10.0.1.5
  - type: Hostname
    address: node-1
  capacity:
    cpu: "16"
    memory: 64Gi
    pods: "110"
    nvidia.com/gpu: "4"

Cordon vs Drain

# 安全 drain 节点（生产常用参数）
kubectl drain node-1 \
  --ignore-daemonsets \           # 忽略 DaemonSet Pod（无法驱逐，它们随节点走）
  --delete-emptydir-data \        # 允许删除使用 emptyDir 的 Pod（否则 drain 失败）
  --timeout=300s \                # 驱逐超时
  --grace-period=60               # Pod 优雅终止宽限期

# drain 过程：
# 1. cordon 节点（打 SchedulingDisabled）
# 2. 逐个驱逐 Pod：
#    a. 发送 Eviction 请求到 API Server
#    b. API Server 检查 PDB 是否允许驱逐
#    c. 如果 PDB 阻止，等待并重试
#    d. Pod 收到 SIGTERM，执行 preStop hook
#    e. 等待 grace period
#    f. kubelet 强制 kill 容器
# 3. 等待所有 Pod 被驱逐（或超时）

Taint/Toleration 模型

Taint（污点）打在 Node 上，排斥不能容忍该 taint 的 Pod；Toleration（容忍）加在 Pod 上，允许 Pod 被调度到有对应 taint 的 Node。

# 给节点打 taint
kubectl taint nodes node-1 dedicated=gpu:NoSchedule

# Pod 加 toleration
tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "gpu"
  effect: "NoSchedule"
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 300   # NotReady 后容忍 300 秒，之后被驱逐

kubelet 驱逐策略

当节点资源紧张时，kubelet 会主动终止 Pod 以回收资源（节点级 OOM 保护）：

kubelet 不直接按 QoS 类别做固定排序，而是针对发生压力的资源依次比较：是否超过 request、Pod Priority、使用量相对 request 的程度。对 CPU/内存这类有 request 的资源，结果通常表现为：

1. 使用量超过 request 的 BestEffort 或 Burstable Pod 先进入候选，再按 Priority 和超过 request 的相对程度排序。
2. Guaranteed Pod，以及使用量低于 request 的 Burstable Pod 最后考虑，主要按 Priority 排序；系统进程挤占预留资源时它们仍可能被驱逐。
3. inode/PID 没有 request，DiskPressure 的统计口径也不同，因此不能把“BestEffort → Burstable → Guaranteed”套到所有节点压力场景。

节点压力驱逐与内核 OOM Killer 也不是同一条链路。发生节点 OOM 时，kubelet 设置的 oom_score_adj 会影响内核选择：BestEffort 通常为 1000，Guaranteed 通常为 -997，Burstable 根据 request 占节点内存比例计算。

Pod 内容器启动顺序

一个 Pod 中容器的启动有明确顺序：

1. Init Containers：按定义顺序串行执行，每个必须成功退出才执行下一个。任何 Init Container 失败，Pod 重启（restartPolicy 决定）。用于初始化配置、等待依赖服务、数据库迁移等。
2. postStart Hook：主容器启动后异步执行（容器 entrypoint 启动同时触发），执行失败会重启容器。不要用 postStart 做必须在容器接受流量前完成的初始化——它和 entrypoint 是并行的，没有顺序保证。
3. Main Containers：在所有 Init Container 成功后并行启动。

apiVersion: v1
kind: Pod
spec:
  initContainers:
  - name: init-config
    image: busybox:1.35
    command: ['sh', '-c', 'cp /config/* /etc/app/']
    volumeMounts:
    - name: config
      mountPath: /etc/app
  - name: wait-for-db
    image: busybox:1.35
    command: ['sh', '-c', 'until nc -z db 5432; do sleep 2; done;']
  containers:
  - name: app
    image: myapp:v1
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "sleep 3 && warmup-cache.sh"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 10 && kill -TERM 1"]  # 等待 envoy sidecar 处理完
    ports:
    - containerPort: 8080

Pod 优雅终止完整过程

当 Pod 被删除（kubectl delete、drain、滚动更新、驱逐）时，经历以下步骤：

T=0s: API Server 收到删除请求，设置 Pod metadata.deletionTimestamp
       → Pod 被标记为 Terminating
       → Endpoint Controller 开始从 Endpoints 中移除该 Pod（摘流）
       → kube-proxy 更新 iptables/IPVS 规则，停止转发新请求到该 Pod

T=0s+: kubelet 看到 Pod Terminating：
       1. 执行 preStop hook（如果定义）
          - preStop 是同步执行的，必须退出才进入下一步
          - 用于优雅摘流：sleep 几秒让旧请求处理完（等待 iptables 规则传播）、通知注册中心下线、保存 checkpoint
       2. preStop 完成后（或没有 preStop），向容器主进程（PID 1）发送 SIGTERM

T=0s → T=terminationGracePeriodSeconds（默认 30s）:
       - 容器进程收到 SIGTERM，应该开始优雅关闭
         （完成在途请求、关闭连接、flush 数据、释放锁）
       - 如果进程在 grace period 内退出，终止完成
       - Sidecar 容器问题：如果有 istio-proxy/envoy sidecar，
         它可能在主容器退出前先被 kill 导致主容器网络中断。
         解决方案：
         a. preStop 中 sleep 等待 sidecar 完成转发
         b. K8s 1.28+ Sidecar Containers（restartPolicy: Always + restartPolicy 标记为 sidecar）

T=grace period 到期:
       - kubelet 发送 SIGKILL 强制杀死仍在运行的容器
       - 容器被清理，Pod 从 API Server 中删除

注意：如果节点故障（NotReady 超时被驱逐），kubelet 无法执行上述流程，
Pod 会卡在 Terminating 状态，需要等节点恢复或强制删除（--force --grace-period=0）。

CA 工作原理

Cluster Autoscaler 是 K8s 社区标准节点自动扩缩容组件，工作在节点组（Node Group/ASG）级别：

1. Scale-up 触发：每 10 秒扫描一次，检查是否有 Pending Pod（因资源不足无法调度）。对每个 Pending Pod，CA 模拟调度：假设增加节点组中的一个节点，是否能放得下这个 Pod？如果能，且该节点组没有正在 scale-up，则将 ASG 扩容 +1 节点。
2. Scale-down 判断：每 10 秒扫描节点，判断节点是否"低利用率"（CPU/内存 request 利用率 < scale-down-utilization-threshold，默认 0.5）且其上 Pod 可以被调度到其他节点。节点满足条件后进入冷却期（默认 10 分钟不缩），冷却期后仍低利用率则驱逐 Pod 并删除节点。
3. 不可驱逐 Pod：Kube-system Pod（非 DaemonSet/PodPriority）、PDB 阻止的 Pod、有 local storage 的 Pod、没有 controller 的 Pod 默认阻止节点缩容。

CA Scale-up 决策路径：
Pending Pod 存在?
  → 模拟调度: 现有节点能放吗? → 能则不扩
  → 不能: 增加 ASG 的一个节点能放吗?
     → 有多个 ASG 可选: 选 expansion policy (least-waste/most-pods/price)
     → 触发 ASG scale-up (+1)
  → 等待新节点 join 集群，kubelet 注册，调度器调度 Pending Pod

Karpenter 设计理念

Karpenter 是 AWS 开源（现在 CNCF 沙箱）的节点自动伸缩组件，设计目标是直接按需供给最合适的计算资源，跳过 ASG 抽象，直接调用云厂商 API 创建 EC2 实例（或其他云资源）：

GPU 伸缩特殊考虑

GPU 节点弹性伸缩相比 CPU 场景有额外复杂性：

1. GPU 实例类型特殊：GPU 实例（AWS p5/p4d/g5/g6、GCP a3/a2、NC 系列）价格高、供给紧张，scale-up 失败率高（InsufficientInstanceCapacity 常见）。需要配置备选实例类型和多 AZ 分散。
2. 拓扑感知调度：多 GPU 训练（如 8x A100）要求同一实例内有 NVLink/NVSwitch 连接；多机分布式训练要求同一 placement group 内低延迟网络。Karpenter 通过 topology.kubernetes.io/zone、karpenter.sh/instance-size、weight 机制处理。
3. NVIDIA Device Pluginnvidia.com/gpu resource 必须在 Node Ready 后才能被调度，kubelet 启动后需要 device plugin 分配 GPU 资源并上报。这导致节点 Ready 到真正可调度有延迟。
4. GPU 节点 taints/tolerations：GPU 节点应该打 taint（如 nvidia.com/gpu:NoSchedule），需要 GPU 的 Pod 加对应的 toleration，避免 CPU Pod 占了昂贵的 GPU 节点。
5. 启动开销：GPU 节点需要预装 NVIDIA 驱动、CUDA、容器运行时（nvidia-container-runtime）、device plugin daemonset，启动后还需要拉取大型 AI 镜像（数 GB 到数十 GB），实际可用时间比 CPU 节点长。
6. Consolidation 风险：GPU 训练/推理任务对中断敏感，必须用 do-not-disrupt、PDB 阻止 consolidation 驱逐正在运行的 GPU Pod，避免训练中断。

# GPU Pod 示例（正确配置）
apiVersion: v1
kind: Pod
metadata:
  name: llm-inference
  annotations:
    karpenter.sh/do-not-disrupt: "true"  # 防止 consolidation 驱逐
spec:
  tolerations:
  - key: "nvidia.com/gpu"
    operator: "Exists"
    effect: "NoSchedule"
  nodeSelector:
    nvidia.com/gpu.product: "A10G"
  containers:
  - name: vllm
    image: vllm/vllm-openai:latest
    resources:
      limits:
        nvidia.com/gpu: 1
        cpu: "8"
        memory: "32Gi"

HPA（Horizontal Pod Autoscaler）

HPA 自动调整 Deployment/StatefulSet 的副本数，基于 metrics 驱动：

• CPU/Memory 利用率：通过 metrics-server 获取 Pod resource metrics，计算 targetAverageUtilization。
• 自定义指标：通过 Prometheus Adapter 暴露自定义指标（如 QPS、Kafka lag、GPU 利用率）。
• 外部指标：对接外部系统指标（如 SQS queue length、ALB request count）。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-inference
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-inference
  minReplicas: 2
  maxReplicas: 20
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0      # 扩容不等待
      policies:
      - type: Percent
        value: 100                       # 每次最多翻倍
        periodSeconds: 30
    scaleDown:
      stabilizationWindowSeconds: 300   # 缩容稳定窗口 5 分钟
      policies:
      - type: Pods
        value: 1                         # 每次最多缩 1 个
        periodSeconds: 60
  metrics:
  - type: Resource
    resource:
      name: nvidia.com/gpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric: {name: vllm_num_requests_waiting}
      target: {type: AverageValue, averageValue: "10"}

HPA 公式：desiredReplicas = ceil[currentReplicas * (currentMetric / targetMetric)]