K8s 调度、资源管理与存储

一、调度器（kube-scheduler）工作原理

两阶段：

1. 过滤（Filter / Predicates）：筛掉不满足硬性条件的节点——资源是否够、nodeSelector、节点亲和性、taint/toleration、端口冲突、卷可用性等。可能剩余 0 个节点 → Pod Pending。
2. 打分（Score / Priorities）：给通过过滤的节点打分排序（如资源最空闲、拓扑分散、镜像已存在、亲和优先），选最高分绑定。

绑定：调度器把结果写回 Pod 的 nodeName（该节点的 kubelet watch 到后开始创建容器）。

二、影响调度的机制

机制	作用
nodeSelector	最简单的节点标签选择（硬条件）
nodeAffinity	节点亲和性，支持硬性(required)/软性(preferred)
podAffinity / podAntiAffinity	与某些 Pod 靠近/远离（如副本分散到不同节点）
Taint / Toleration	节点打"污点"，只有"容忍"该污点的 Pod 才能调度上去（用于独占、隔离）
拓扑分布约束 topologySpreadConstraints	让副本在 zone/节点间均衡分布
PriorityClass / Preemption	高优先级 Pod 可抢占低优先级 Pod 的节点

Taint 与 Affinity 的区别（高频）：Affinity 是 Pod "想去哪"（从 Pod 视角），Taint 是节点"拒绝谁"（从节点视角）；二者配合使用。

三、资源管理：requests / limits / QoS

• requests：Pod 需要保证的资源量，调度依据（调度器按 requests 找放得下的节点）。
• limits：容器能用的上限。超过 CPU limit 被限流（throttle），超过内存 limit 被 OOMKill。
• QoS 等级（由 requests/limits 决定，影响驱逐优先级）：
  1. Guaranteed：每个容器 CPU/内存的 requests == limits（最高保障，最后被驱逐）。
  2. Burstable：设置了 requests 但不等 limits（中间档）。
  3. BestEffort：什么都没设（最先被驱逐）。

驱逐（Eviction）：节点资源紧张时，kubelet 按 QoS 从低到高驱逐 Pod，保命节点。

LimitRange / ResourceQuota：前者设命名空间内对象默认/上下限；后者限制命名空间总量。

四、存储：Volume / PV / PVC / StorageClass

• Volume：Pod 级存储抽象，生命周期可长于容器（容器重启卷还在）。
• PV（PersistentVolume）：集群级存储资源（真实盘/NFS/云盘），由管理员或动态供给创建。
• PVC（PersistentVolumeClaim）：用户对存储的"申请"（大小、访问模式），K8s 把它绑到一个 PV。
• StorageClass：定义"动态供给"的模板（用哪个 provisioner、参数），PVC 指定 SC 后自动创建 PV。

访问模式：RWO（单节点读写）、ROX（单节点只读）、RWX（多节点读写，需共享存储支持）、RWOP。

绑定关系：PVC ← 绑定 → PV；Pod 通过 volumes 引用 PVC。StatefulSet 用 volumeClaimTemplates 给每个 Pod 生成独立 PVC。

五、ConfigMap 与 Secret

• ConfigMap：存非敏感配置（环境变量、配置文件、命令行参数）。
• Secret：存敏感信息（密码、token、证书），默认 base64（不是加密！要真加密需开 etcd 加密或外部 KMS）。
• 注入方式：环境变量、挂载为文件（卷）、命令行参数。
• 热更新：以卷挂载方式注入的 ConfigMap/Secret 会自动更新到文件（有延迟）；环境变量方式不会更新（需重建 Pod）。

六、高频速答

Q：Pod 一直 Pending 可能原因？ A：资源不足（requests 太大）、亲和性/污点不匹配、PVC 未绑定、节点被 cordon、镜像拉取前的调度失败等。看 kubectl describe pod 的 Events。

Q：requests 和 limits 设置的最佳实践？ A：requests 按稳定需求设（保证调度与 QoS），limits 按峰值设；内存 limit 尤其要小心（超了直接 OOMKill）。

Q：为什么内存超 limit 是 Kill，CPU 超只是限流？ A：内存不可压缩（不可回收），只能杀；CPU 可压缩，超了靠 CFS 限流节流。

Q：PVC 一直是 Pending？ A：没有匹配的 PV/StorageClass、容量不足、访问模式不匹配，或 provisioner 异常。

Q：StatefulSet 的存储怎么保证重建后数据还在？ A：用 volumeClaimTemplates，每个序号 Pod 绑定固定 PVC，重建时挂回同一块卷。

Q：ConfigMap 改了 Pod 里为什么不生效？ A：环境变量方式不热更；卷挂载方式才会自动更新（有延迟）。需要重启/滚动更新 Pod。