kubernetes（K8s）学习笔记：第八期与第九期核心知识点自测与详解

本自测解析针对 Kubernetes 系列第八期（集群治理与控制（上篇）：网络策略------NetworkPolicy）和第九期（集群治理与控制（下篇）：调度与节点管理------Scheduler + 污点容忍 + 节点维护）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固 Kubernetes 网络策略与调度管理的核心技能。
文章索引：

kubernetes（K8s）学习笔记（第八期）：集群治理与控制（上篇）：网络策略------NetworkPolicy

kubernetes（K8s）学习笔记（第九期）：集群治理与控制（下篇）：调度与节点管理------Scheduler + 污点容忍 + 节点维护

更多自我检测系列欢迎浏览：每日知识点小问答

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

第八期：网络策略（NetworkPolicy）（第 1-5 题）

题目一：NetworkPolicy 的四个核心字段及其作用

题目：Kubernetes NetworkPolicy 的 spec 中包含哪四个核心字段？分别起什么作用？如果 podSelector 设置为 {}，表示什么含义？policyTypes 字段如果不指定，默认行为是什么？

考查知识点

网络策略规约详解 ------ 第八期 §3
核心字段与选择器

详细解答

NetworkPolicy 的四个核心字段：

字段	作用	示例
`podSelector`	策略适用的 Pod 范围	`matchLabels: {role: db}`
`policyTypes`	策略类型（Ingress / Egress）	`[Ingress, Egress]`
`ingress`	入站规则白名单，匹配 `from` 和 `ports`	允许特定来源访问
`egress`	出站规则白名单，匹配 `to` 和 `ports`	允许访问特定目标

podSelector: {} 的含义：

选择当前 Namespace 中的所有 Pod
常用于设置默认策略（允许所有或拒绝所有）

policyTypes 默认行为：

如果 NetworkPolicy 未指定 policyTypes：
- 默认始终设置 Ingress（如果有 ingress 规则）
- 如果 NetworkPolicy 有任何 egress 规则，则默认设置 Egress
建议显式指定 policyTypes，避免歧义

完整 YAML 示例：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-policy
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379

题目二：四种选择器（selector）的对比与组合使用

题目：NetworkPolicy 中的 from 和 to 字段支持哪四种选择器？请分别说明其作用，并举例说明如何匹配"特定命名空间中的特定 Pod"。如果 from 数组中包含多个选择器条目，它们之间是"与"还是"或"的关系？

考查知识点

四种选择器 ------ 第八期 §3.3
组合使用与逻辑关系

详细解答

四种选择器：

选择器	作用	示例
podSelector	选择同一 Namespace 中的特定 Pod	`role: frontend`
namespaceSelector	选择特定 Namespace 中的所有 Pod	`project: myproject`
namespaceSelector + podSelector	选择特定 Namespace 中的特定 Pod	组合使用
ipBlock	选择特定 IP CIDR 范围（含 except）	`172.17.0.0/16`

匹配"特定命名空间中的特定 Pod"：

yaml 复制代码

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        project: myproject
    podSelector:
      matchLabels:
        role: frontend

含义：只允许来自 project=myproject 命名空间中带有 role=frontend 标签的 Pod 的流量。

关键逻辑：

namespaceSelector 和 podSelector 在同一层级时是 "且" 的关系（必须同时满足）
在 from 数组中，不同条目之间是"或" 的关系（满足任意一个即可）

示例：多个来源（或关系）：

yaml 复制代码

ingress:
- from:
  - namespaceSelector:
      matchLabels:
        project: myproject
  - podSelector:
      matchLabels:
        role: frontend

含义：允许来自 project=myproject 命名空间的任何 Pod 的流量，或来自本地命名空间中带有 role=frontend 标签的 Pod 的流量。

题目三：NetworkPolicy 的"相加性"原则

题目：Kubernetes 网络策略是"相加的"（additive），这是什么意思？如果两个 NetworkPolicy 同时作用于同一个 Pod，最终生效的规则是什么？请说明为什么 NetworkPolicy 不能显式"拒绝"某个来源。

考查知识点

网络策略概述 ------ 第八期 §2.4
策略相加性原则

详细解答

"相加性"的含义：

多个 NetworkPolicy 作用于同一个 Pod 时，所有策略允许的连接的并集就是最终生效的规则
策略之间不会冲突或覆盖，只会叠加
这与"白名单"模式一致------只能添加允许规则，不能显式拒绝

示例：

策略	规则
策略 A	允许 Pod X 访问（来源：`role=frontend`）
策略 B	允许 Pod Y 访问（来源：`role=api`）
最终结果	Pod X 和 Pod Y 都可以访问

为什么不能显式拒绝：

NetworkPolicy 的设计哲学是白名单模式
默认情况下所有流量都被拒绝（Deny by default），只有显式允许的流量才能通过
因此不需要"拒绝"规则------只要不列入白名单，流量自然被拒绝
多个策略的相加性也简化了规则管理，避免了复杂的优先级判断

重要提示 ：要允许从源 Pod 到目的 Pod 的连接，源 Pod 的出口策略 和目的 Pod 的入口策略都需要允许连接。任何一方不允许，连接都会失败。

题目四：入口隔离（Ingress）与出口隔离（Egress）

题目：Kubernetes 中 Pod 的入口隔离和出口隔离默认行为分别是什么？当 NetworkPolicy 只指定了 Ingress 而没有指定 Egress 时，Pod 的出站流量会受到限制吗？如果希望完全隔离 Pod（禁止所有入站和出站流量），应该如何配置？

考查知识点

网络策略概述 ------ 第八期 §2.3
入口/出口隔离

详细解答

默认行为：

隔离类型	方向	默认行为
入口（Ingress）	流入 Pod	✅ 允许所有入站连接
出口（Egress）	流出 Pod	✅ 允许所有出站连接

只指定 Ingress 时的行为：

当 NetworkPolicy 只包含 Ingress 规则时：
- ✅ 入口被隔离：只允许策略中指定的入站连接
- ❌ 出口不受影响：仍然允许所有出站连接

只指定 Egress 时的行为：

当 NetworkPolicy 只包含 Egress 规则时：
- ✅ 出口被隔离：只允许策略中指定的出站连接
- ❌ 入口不受影响：仍然允许所有入站连接

完全隔离（禁止所有入站和出站流量）：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress
  # 不指定 ingress 和 egress 规则 → 拒绝所有入站和出站

题目五：四种默认策略模板

题目：请写出以下四种默认 NetworkPolicy 的 YAML 模板：

默认允许所有入站流量
默认拒绝所有入站流量
默认允许所有出站流量
默认拒绝所有出站流量

考查知识点

默认策略 ------ 第八期 §5

详细解答

1. 默认允许所有入站流量：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - {}

2. 默认拒绝所有入站流量：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
spec:
  podSelector: {}
  policyTypes:
  - Ingress

3. 默认允许所有出站流量：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - {}

4. 默认拒绝所有出站流量：

yaml 复制代码

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-egress
spec:
  podSelector: {}
  policyTypes:
  - Egress

生产环境最佳实践 ：在关键 Namespace 中部署 default-deny-all 策略（同时拒绝 Ingress 和 Egress），然后按需添加允许规则，实现零信任网络隔离。

第九期：调度与节点管理（第 6-10 题）

题目六：kube-scheduler 的调度过程

题目：kube-scheduler 的调度过程分为哪两个阶段？过滤阶段有哪些常见的断言（Predicates）？打分阶段有哪些常见的优先级（Priorities）？如果过滤后没有可调度节点，Pod 会处于什么状态？

考查知识点

调度概述 ------ 第九期 §1
过滤与打分

详细解答

两个阶段：

阶段	名称	作用
第一阶段	过滤（Filtering）	找出所有满足 Pod 需求的节点
第二阶段	打分（Scoring）	对每个可调度节点打分，选择最高分

过滤阶段常见断言（Predicates）：

断言	作用
`PodFitsResources`	检查节点是否有足够的 CPU/内存
`PodFitsHostPorts`	检查节点端口是否被占用
`MatchNodeSelector`	检查是否匹配 nodeSelector
`PodToleratesNodeTaints`	检查 Pod 能否容忍节点污点
`CheckVolumeBinding`	检查 PVC 是否可绑定
`NoVolumeZoneConflict`	检查存储卷的可用区限制

打分阶段常见优先级（Priorities）：

优先级	作用
`LeastRequestedPriority`	优先选择资源使用率较低的节点（负载均衡）
`NodeAffinityPriority`	优先选择匹配节点亲和性的节点
`InterPodAffinityPriority`	优先选择满足 Pod 间亲和性的节点
`ImageLocalityPriority`	优先选择已有容器镜像缓存的节点

过滤后无可用节点：

Pod 保持 Pending 状态
可通过 kubectl describe pod <pod-name> 查看 FailedScheduling 事件，了解具体原因

题目七：四种控制 Pod 运行位置的方式

题目：Kubernetes 有哪四种方式控制 Pod 调度到特定节点？请说明它们的优先级和推荐度。nodeSelector 和 nodeAffinity 的主要区别是什么？如何让 Pod 调度到"有 SSD 磁盘"的节点？

考查知识点

控制 Pod 运行位置 ------ 第九期 §2
调度方式对比

详细解答

四种方式：

方式	优先级	推荐度
nodeName	最高	❌ 不推荐（仅测试）
nodeSelector	高	✅ 推荐
nodeAffinity	高	✅ 推荐
podAffinity / antiAffinity	中	按需使用

nodeSelector vs nodeAffinity：

对比项	nodeSelector	nodeAffinity
灵活性	简单匹配（等于）	支持 In/NotIn/Exists 等操作符
软性约束	❌ 不支持	✅ 支持 `preferredDuringScheduling`
硬性约束	✅ 支持	✅ 支持 `requiredDuringScheduling`

调度到有 SSD 磁盘的节点：

方法一：nodeSelector（推荐）

bash 复制代码

# 给节点打标签
kubectl label node worker31.whisky.cloud disktype=ssd

yaml 复制代码

# Pod 中指定 nodeSelector
spec:
  nodeSelector:
    disktype: ssd

方法二：nodeAffinity（更灵活）

yaml 复制代码

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd

题目八：污点与容忍度的匹配规则

题目：节点上有三个污点：CPU=L1:NoSchedule、CPU=L1:NoExecute、MEM=L2:NoSchedule。Pod 有以下容忍度：

yaml 复制代码

tolerations:
- key: "CPU"
  operator: "Equal"
  value: "L1"
  effect: "NoSchedule"
- key: "CPU"
  operator: "Equal"
  value: "L1"
  effect: "NoExecute"

请问：该 Pod 能否调度到该节点上？为什么？如果 Pod 已经在该节点上运行，会发生什么？

考查知识点

污点与容忍度 ------ 第九期 §3.4
多个污点的匹配规则

详细解答

答案：不能调度。

原因分析：

节点的三个污点：
- 污点 1：CPU=L1:NoSchedule
- 污点 2：CPU=L1:NoExecute
- 污点 3：MEM=L2:NoSchedule
Pod 的容忍度：
- 容忍度 1：匹配污点 1（CPU=L1:NoSchedule）✅
- 容忍度 2：匹配污点 2（CPU=L1:NoExecute）✅
- 容忍度 3：缺少对污点 3（MEM=L2:NoSchedule）的容忍度 ❌
过滤逻辑：
- 遍历节点所有污点，过滤掉 Pod 有匹配容忍度的污点
- 剩余污点：MEM=L2:NoSchedule（未被容忍）
- 剩余污点中存在 effect 为 NoSchedule 的污点 → Pod 不能调度

如果 Pod 已经在节点上运行：

由于缺少对 MEM=L2:NoSchedule 的容忍度，Pod 不会被驱逐
NoSchedule 只影响新 Pod 的调度，不影响已有 Pod
但如果污点的 effect 是 NoExecute，则会立即驱逐不匹配的 Pod

匹配规则速查：

条件	结果
无未容忍的 NoSchedule 污点	Pod 可以调度
存在未容忍的 NoSchedule 污点	Pod 不能调度
存在未容忍的 NoExecute 污点	Pod 被驱逐

题目九：cordon / drain / uncordon 的区别

题目：kubectl cordon、kubectl drain 和 kubectl uncordon 三个命令分别有什么作用？执行 kubectl drain 时，为什么通常需要加上 --ignore-daemonsets 参数？如果 drain 卡住，可能的原因有哪些？

考查知识点

节点管理 ------ 第九期 §4
cordon / drain / uncordon

详细解答

三个命令的区别：

命令	作用	对已有 Pod 的影响
`kubectl cordon`	标记节点不可调度	❌ 不影响已有 Pod
`kubectl drain`	驱逐节点上所有 Pod + 标记不可调度	✅ 驱逐所有 Pod（DaemonSet 除外）
`kubectl uncordon`	恢复节点调度	❌ 不影响已有 Pod

为什么需要 --ignore-daemonsets：

DaemonSet 的设计初衷是每个节点运行一个 Pod（如日志采集、网络插件）
驱逐 DaemonSet Pod 后，kubelet 会立即重新创建它
如果不忽略 DaemonSet，drain 会陷入无限循环
因此生产环境中 drain 命令通常必须加 --ignore-daemonsets

drain 卡住的可能原因：

原因	说明
PodDisruptionBudget（PDB）限制	Pod 设置了 PDB，阻止驱逐以保证最低可用副本数
裸 Pod	非控制器管理的 Pod 无法被重新调度，需加 `--force`
DaemonSet Pod 未忽略	未加 `--ignore-daemonsets` 参数
Pod 无法正常终止	容器进程卡死，超过 `terminationGracePeriodSeconds`

完整 drain 命令示例：

bash 复制代码

kubectl drain worker31.whisky.cloud --ignore-daemonsets

题目十：内置污点与自动驱逐机制

题目：Kubernetes 有哪些内置污点？Pod 默认针对 node.kubernetes.io/not-ready 和 node.kubernetes.io/unreachable 的容忍度配置是什么？这有什么意义？DaemonSet 的 Pod 在这方面有何不同？

考查知识点

内置污点 ------ 第九期 §3.6
自动驱逐与 tolerationSeconds

详细解答

内置污点列表：

污点	触发条件
`node.kubernetes.io/not-ready`	节点未就绪（Ready 状态为 False）
`node.kubernetes.io/unreachable`	节点不可达（Ready 状态为 Unknown）
`node.kubernetes.io/memory-pressure`	内存压力
`node.kubernetes.io/disk-pressure`	磁盘压力
`node.kubernetes.io/pid-pressure`	PID 压力
`node.kubernetes.io/network-unavailable`	网络不可用

Pod 默认的容忍度：

yaml 复制代码

tolerations:
- key: "node.kubernetes.io/not-ready"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 300
- key: "node.kubernetes.io/unreachable"
  operator: "Exists"
  effect: "NoExecute"
  tolerationSeconds: 300

意义：

节点出现故障时，Pod 会在节点上停留 5 分钟（300 秒）
给集群管理员时间修复问题，避免因短暂网络抖动导致大量 Pod 被驱逐
这种机制有效防止了"惊群效应"------大规模 Pod 同时被驱逐和重建

DaemonSet 的特殊行为：

DaemonSet 的 Pod 针对 not-ready 和 unreachable 污点的容忍度没有 tolerationSeconds
这意味着 DaemonSet Pod 永不因节点故障被驱逐（永久容忍）
原因：DaemonSet 服务（如日志采集、网络插件）需要在每个节点上持续运行

附：知识点对应总表

题号	主要考查知识点（对应笔记章节）
1	第八期 §3 网络策略规约详解
2	第八期 §3.3 四种选择器
3	第八期 §2.4 策略相加性原则
4	第八期 §2.3 入口/出口隔离
5	第八期 §5 默认策略
6	第九期 §1 调度过程（过滤+打分）
7	第九期 §2 四种调度方式对比
8	第九期 §3.4 污点与容忍度匹配规则
9	第九期 §4 节点管理（cordon/drain/uncordon）
10	第九期 §3.6 内置污点与驱逐机制

学习建议：对于答错的题目，请回看第八期或第九期对应章节，并动手在集群环境中执行相关命令。网络策略和调度管理是 Kubernetes 集群治理的核心能力，建议通过实际操作加深理解。
--- Compiled and Authored by Whisky --- July 4 th, 2026