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

kubernetesK8s学习笔记第八期与第九期核心知识点自测与详解本自测解析针对 Kubernetes 系列第八期集群治理与控制上篇网络策略——NetworkPolicy和第九期集群治理与控制下篇调度与节点管理——Scheduler 污点容忍 节点维护的核心内容。共 10 题每题包含题目回顾、考查知识点、详细解答与分析帮助读者巩固 Kubernetes 网络策略与调度管理的核心技能。文章索引kubernetesK8s学习笔记第八期集群治理与控制上篇网络策略——NetworkPolicykubernetesK8s学习笔记第九期集群治理与控制下篇调度与节点管理——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 示例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组合使用与逻辑关系详细解答四种选择器选择器作用示例podSelector选择同一 Namespace 中的特定 Podrole: frontendnamespaceSelector选择特定 Namespace 中的所有 Podproject: myprojectnamespaceSelector podSelector选择特定 Namespace 中的特定 Pod组合使用ipBlock选择特定 IP CIDR 范围含 except172.17.0.0/16匹配“特定命名空间中的特定 Pod”ingress:-from:-namespaceSelector:matchLabels:project:myprojectpodSelector:matchLabels:role:frontend含义只允许来自projectmyproject命名空间中带有rolefrontend标签的 Pod 的流量。关键逻辑namespaceSelector和podSelector在同一层级时是“且”的关系必须同时满足在from数组中不同条目之间是“或”的关系满足任意一个即可示例多个来源或关系ingress:-from:-namespaceSelector:matchLabels:project:myproject-podSelector:matchLabels:role:frontend含义允许来自projectmyproject命名空间的任何 Pod的流量或来自本地命名空间中带有rolefrontend标签的 Pod 的流量。题目三NetworkPolicy 的“相加性”原则题目Kubernetes 网络策略是“相加的”additive这是什么意思如果两个 NetworkPolicy 同时作用于同一个 Pod最终生效的规则是什么请说明为什么 NetworkPolicy 不能显式“拒绝”某个来源。考查知识点网络策略概述 —— 第八期 §2.4策略相加性原则详细解答“相加性”的含义多个 NetworkPolicy 作用于同一个 Pod 时所有策略允许的连接的并集就是最终生效的规则策略之间不会冲突或覆盖只会叠加这与“白名单”模式一致——只能添加允许规则不能显式拒绝示例策略规则策略 A允许 Pod X 访问来源rolefrontend策略 B允许 Pod Y 访问来源roleapi最终结果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规则时✅ 出口被隔离只允许策略中指定的出站连接❌ 入口不受影响仍然允许所有入站连接完全隔离禁止所有入站和出站流量apiVersion:networking.k8s.io/v1kind:NetworkPolicymetadata:name:default-deny-allspec:podSelector:{}policyTypes:-Ingress-Egress# 不指定 ingress 和 egress 规则 → 拒绝所有入站和出站题目五四种默认策略模板题目请写出以下四种默认 NetworkPolicy 的 YAML 模板默认允许所有入站流量默认拒绝所有入站流量默认允许所有出站流量默认拒绝所有出站流量考查知识点默认策略 —— 第八期 §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:-Ingress3. 默认允许所有出站流量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过滤与打分详细解答两个阶段阶段名称作用第一阶段过滤Filtering找出所有满足 Pod 需求的节点第二阶段打分Scoring对每个可调度节点打分选择最高分过滤阶段常见断言Predicates断言作用PodFitsResources检查节点是否有足够的 CPU/内存PodFitsHostPorts检查节点端口是否被占用MatchNodeSelector检查是否匹配 nodeSelectorPodToleratesNodeTaints检查 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对比项nodeSelectornodeAffinity灵活性简单匹配等于支持 In/NotIn/Exists 等操作符软性约束❌ 不支持✅ 支持preferredDuringScheduling硬性约束✅ 支持✅ 支持requiredDuringScheduling调度到有 SSD 磁盘的节点方法一nodeSelector推荐# 给节点打标签kubectl labelnodeworker31.whisky.clouddisktypessd# Pod 中指定 nodeSelectorspec:nodeSelector:disktype:ssd方法二nodeAffinity更灵活affinity:nodeAffinity:requiredDuringSchedulingIgnoredDuringExecution:nodeSelectorTerms:-matchExpressions:-key:disktypeoperator:Invalues:-ssd题目八污点与容忍度的匹配规则题目节点上有三个污点CPUL1:NoSchedule、CPUL1:NoExecute、MEML2:NoSchedule。Pod 有以下容忍度tolerations:-key:CPUoperator:Equalvalue:L1effect:NoSchedule-key:CPUoperator:Equalvalue:L1effect:NoExecute请问该 Pod 能否调度到该节点上为什么如果 Pod 已经在该节点上运行会发生什么考查知识点污点与容忍度 —— 第九期 §3.4多个污点的匹配规则详细解答答案不能调度。原因分析节点的三个污点污点 1CPUL1:NoSchedule污点 2CPUL1:NoExecute污点 3MEML2:NoSchedulePod 的容忍度容忍度 1匹配污点 1CPUL1:NoSchedule✅容忍度 2匹配污点 2CPUL1:NoExecute✅容忍度 3缺少对污点 3MEML2:NoSchedule的容忍度❌过滤逻辑遍历节点所有污点过滤掉 Pod 有匹配容忍度的污点剩余污点MEML2:NoSchedule未被容忍剩余污点中存在 effect 为NoSchedule的污点 →Pod 不能调度如果 Pod 已经在节点上运行由于缺少对MEML2: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 卡住可能的原因有哪些考查知识点节点管理 —— 第九期 §4cordon / drain / uncordon详细解答三个命令的区别命令作用对已有 Pod 的影响kubectl cordon标记节点不可调度❌ 不影响已有 Podkubectl drain驱逐节点上所有 Pod 标记不可调度✅ 驱逐所有 PodDaemonSet 除外kubectl uncordon恢复节点调度❌ 不影响已有 Pod为什么需要--ignore-daemonsetsDaemonSet 的设计初衷是每个节点运行一个 Pod如日志采集、网络插件驱逐 DaemonSet Pod 后kubelet 会立即重新创建它如果不忽略 DaemonSetdrain会陷入无限循环因此生产环境中drain命令通常必须加--ignore-daemonsetsdrain 卡住的可能原因原因说明PodDisruptionBudgetPDB限制Pod 设置了 PDB阻止驱逐以保证最低可用副本数裸 Pod非控制器管理的 Pod 无法被重新调度需加--forceDaemonSet Pod 未忽略未加--ignore-daemonsets参数Pod 无法正常终止容器进程卡死超过terminationGracePeriodSeconds完整 drain 命令示例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 状态为 Falsenode.kubernetes.io/unreachable节点不可达Ready 状态为 Unknownnode.kubernetes.io/memory-pressure内存压力node.kubernetes.io/disk-pressure磁盘压力node.kubernetes.io/pid-pressurePID 压力node.kubernetes.io/network-unavailable网络不可用Pod 默认的容忍度tolerations:-key:node.kubernetes.io/not-readyoperator:Existseffect:NoExecutetolerationSeconds:300-key:node.kubernetes.io/unreachableoperator:Existseffect:NoExecutetolerationSeconds: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/uncordon10第九期 §3.6 内置污点与驱逐机制学习建议对于答错的题目请回看第八期或第九期对应章节并动手在集群环境中执行相关命令。网络策略和调度管理是 Kubernetes 集群治理的核心能力建议通过实际操作加深理解。— Compiled and Authored by Whisky — July 4 th, 2026