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

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: {}的含义：

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

policyTypes默认行为：

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

完整 YAML 示例：

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:test-policyspec:podSelector:matchLabels:role:dbpolicyTypes:-Ingress-Egressingress:-from:-podSelector:matchLabels:role:frontendports:-protocol:TCPport:6379

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

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

考查知识点

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

详细解答

四种选择器：

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

ingress:-from:-namespaceSelector:matchLabels:project:myprojectpodSelector:matchLabels:role:frontend

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

关键逻辑：

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

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

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 时，所有策略允许的连接的并集就是最终生效的规则
• 策略之间不会冲突或覆盖，只会叠加
• 这与“白名单”模式一致——只能添加允许规则，不能显式拒绝

示例：

为什么不能显式拒绝：

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

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

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

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

考查知识点

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

详细解答

默认行为：

只指定 Ingress 时的行为：

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

只指定 Egress 时的行为：

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

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

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-allspec:podSelector:{}policyTypes:-Ingress-Egress# 不指定 ingress 和 egress 规则 → 拒绝所有入站和出站

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

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

1. 默认允许所有入站流量
2. 默认拒绝所有入站流量
3. 默认允许所有出站流量
4. 默认拒绝所有出站流量

考查知识点

• 默认策略 —— 第八期 §5

详细解答

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

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-all-ingressspec:podSelector:{}policyTypes:-Ingressingress:-{}

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

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-ingressspec:podSelector:{}policyTypes:-Ingress

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

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:allow-all-egressspec:podSelector:{}policyTypes:-Egressegress:-{}

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

apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-egressspec:podSelector:{}policyTypes:-Egress

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

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

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

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

考查知识点

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

详细解答

两个阶段：

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

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

过滤后无可用节点：

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

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

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

考查知识点

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

详细解答

四种方式：

nodeSelector vs nodeAffinity：

调度到有 SSD 磁盘的节点：

方法一：nodeSelector（推荐）

# 给节点打标签kubectl labelnodeworker31.whisky.clouddisktype=ssd

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

方法二：nodeAffinity（更灵活）

affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:disktypeoperator:Invalues:-ssd

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

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

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

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

考查知识点

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

详细解答

答案：不能调度。

原因分析：

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

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

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

匹配规则速查：

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

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

考查知识点

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

详细解答

三个命令的区别：

为什么需要--ignore-daemonsets：

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

drain 卡住的可能原因：

完整 drain 命令示例：

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

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

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

考查知识点

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

详细解答

内置污点列表：

Pod 默认的容忍度：

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 服务（如日志采集、网络插件）需要在每个节点上持续运行

附：知识点对应总表

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