Kubernetes

Requests 参与放置和资源共享，limits 约束运行时消耗。它们是有关联的输入，不是对应用性能的一套通用下限与上限保证。应结合负载行为、争用风险和恢复要求选择，并查看准入后的 Pod，因为默认值与策略可能改变清单里提交的资源值。先区分记账、实际使用和执行约束，才能解释配置为什么影响行为。 默认值也是契约的一部分 某资源只有 limit、没有 request 时，如果准入没有提供另一请求，Kubernetes 会把限制复制为请求。因此，只配 limit 通常不是零调度成本。LimitRange 默认值与 ResourceQuota 检查也会影响准入。解释 Pod 为什么 Pending 之前，应读取实际保存的两张资源映射，不能仅凭源文件中某一字段缺失进行判断。 Request 不会预先分配应用的物理内存，也不必然独占 CPU 核心。CPU 请求参与调度及争用时的相对份额。没有 CPU limit 的容器可以利用超过请求的空闲 CPU，但节点容量、祖先约束和竞争负载仍然构成边界。省略限制可能是有意选择，应配套明确容量和争用策略，而不是简单认定只配一边必然错误。 Linux 上 CPU limit 通常通过带宽节流执行，耗尽配额本身不会直接杀死进程。但等待可能增加延迟、触发应用超时或影响探针。整机 CPU 平均值低，也不能排除某个上限很紧的容器正在频繁节流。要比较对应时间窗口的需求、配额和等待，而不是拿整机平均值替代容器约束。 内存具有不同失败行为 内存限制不是 CPU 那种周期额度。内核可以回收记账内存，并在无法满足约束时触发控制组 OOM；它是响应实际压力的机制，不是看板曲线越线就立刻杀死进程。节点压力与应用自身失败又是另外的机制。应区分容器 OOM、节点驱逐和普通进程终止，避免给所有重启使用同一种解释。 容器记账内存不只包含托管堆。原生分配、线程栈、文件相关内存以及内存型卷都可能参与。进程 RSS 和应用堆指标很有用，却都不等于控制组全部计费字节。应依据运行时与内核检查合适的记账视图，并考虑采样间隔可能漏掉的短峰值，不能只把堆参数与 limit 作一次简单大小比较。 ...

NodePort 类型的 Service 分配一个集群范围的端口，并通过符合配置的节点地址转发流量。它适用于外部负载均衡、开发环境及有明确用途的服务暴露，但不保证每台机器的每个地址都能访问，也不保证每台节点都有一个普通应用监听套接字。路由、防火墙、代理实现与流量策略仍然决定真实访问路径，不能从 Service 类型推断全部网络条件。 一次分配，多种转发路径 默认分配范围为 30000–32767，管理员可以配置其他范围。请求指定 nodePort 时，只有分配与校验允许才会成功；端口冲突会拒绝 API 事务，通常不是先创建一个对象，再悄悄留下不可用端口。应分别核对命令退出状态与实际保存的对象，不能把创建失败解释成运行期网络故障。 Service port、targetPort 与 nodePort 各有职责：前者是虚拟服务入口，中间值指定后端端口，最后一个是节点侧入口。多端口 Service 可以占用多个号码。LoadBalancer 类型也可能分配 NodePort，除非配置与实现允许省略。因此，仅统计类型为 NodePort 的对象，会漏掉地址池的部分实际使用者，第一端口也不代表整份清单。 转发可能由 iptables、IPVS、nftables 或其他实现完成。规则可以引导数据包，而不需要普通用户态程序在该端口接收连接。所以，套接字列表不能证明 NodePort 数据路径健康，也不能凭列表为空宣布服务失效。节点地址筛选同样重要：主地址可达，不代表次要地址或回环地址具有相同行为，具体范围要看代理配置。 流量策略改变候选端点 externalTrafficPolicy 为 Cluster 时，可以选择其他节点上的合适端点。常见 kube-proxy 路径可能执行源地址转换，因此不能假定后端一定看到最初客户端地址。Local 则为外部流量选择本地合适端点，并在这段路径保留源地址。但上游代理或负载均衡可能已经改写过来源，Local 不会自动恢复之前丢失的信息。 没有合适本地端点的节点，无法处理普通 Local 策略流量。外部均衡必须考虑副本分布，不能长期平均发送到全部节点，再期待平台补回缺失的本地副本。终止中端点的处理和代理版本还有额外细节。单副本、三节点只能说明一种放置场景，不能替完整可用性模型，更不能省略真实数据路径测试。 暴露范围取决于实际后端 NodePort 本身提供传输层转发，不提供 HTTP 授权或 TLS 终止。如果它直接选择应用 Pod，确实可能绕过 Ingress 的认证、路由和 WAF；如果选择的就是 Ingress 控制器，那么经过该端口的流量并没有天然绕开控制器。必须先画清真实链路，再判断每项安全控制是否仍处于请求路径中。 ...

PodDisruptionBudget 限制一组选中 Pod 通过驱逐产生的中断。它可以协助维护期间保留服务容量或法定多数，但不能保证两者必然存在。保护取决于调用者使用 Eviction API、选择器选中正确成员，以及 Ready 条件真正反映应用所需能力。只建立一份对象而不核对这些前提，并不能让维护自动安全。 允许中断多少，应来自应用的失败模型。三成员多数派系统通常需要两个正常成员，但 Pod 就绪本身不证明成员身份、数据同步或成员之间的连通性。PDB 是应用健康检查与维护流程的补充，不会理解数据库协议，也不会自动纠正已经失去同步却仍报告 Ready 的副本。 保护边界在驱逐接口 节点崩溃、网络分区和节点压力驱逐，都不会被 PDB 阻止。但已经不可用的成员仍可能减少后续维护可使用的额度。直接删除 Pod 或整个工作负载会绕过预算，工作负载控制器正常滚动更新时的删除也不受它限制。因此“主动中断”不自动等于“必然经过预算保护”，必须看实际调用路径。 正常 drain 通过驱逐请求工作，在预算阻挡时重试；选择直接删除的调用方则绕过这层保护。依赖预算之前，应确认维护工具真实行为。Deployment 与 StatefulSet 的滚动可用性由各自更新策略控制，所以要协调发布和节点维护，不能假定一份 PDB 就会把所有会影响副本的操作自动串行化。 计算之前先弄清分母 minAvailable 与 maxUnavailable 只能选择其一。三个健康副本配整数 minAvailable 二，在普通稳定状态下允许驱逐一个健康成员。maxUnavailable 一则相对于预期规模表达允许量。currentHealthy 计算符合条件的 Ready Pod，并排除正在删除或已经记录待中断的成员；只处于 Running 阶段并不够，进程在跑也可能完全没有服务能力。 expectedPods 并不总等于控制器的期望 replicas。此次核对的 Kubernetes 1.34.0 实现中，整数 minAvailable 使用选中 Pod 对象的数量；百分比 minAvailable 与 maxUnavailable 则从所属控制器取得预期规模。因此它与 StatefulSet replicas 不一致，可能来自策略类型或协调时刻，不能直接断定选择器拼错。不同字段的分母需要按实际计算路径理解。 ...

Deployment 在意总数，DaemonSet 在意覆盖面：新节点一进池子，同一个服务立刻就在那里。节点级关切——发日志、暴露硬件指标、跑网络 fabric、执行策略——必须处处有，不然等于处处没有。用逐节点脚本或每个 Pod 塞 sidecar 去凑合，立刻就烂：新节点漏掉、版本漂移，没人答得出"哪些节点跑着 agent"而不审计。 DaemonSet 控制器用声明式覆盖弥合这个缝。你把守护进程描述一次，控制器永远把现实收敛到每合格节点一个 Pod，扩集群自动扩守护舰队。覆盖从 runbook 条目变成系统维护的不变量。 每节点一个、天生如此 你把守护进程描述一次，控制器就给每个节点都挂一份副本，这正是节点级日志、指标 agent 与 kube-proxy 这类流量的天然归属。没有需要手工调大小的伸缩旋钮。没有旋钮是特性：副本数一经手压就会从意图漂走，而"每合格节点一个"不会漂——它按节点列表持续重算。新节点注册时 gain Pod，离场释放，被 cordon 的除非 drain 都留着。 因为放置按节点不按容量，DaemonSet Pod 一般要优先级和抢占 headroom，才能在满节点上活下来。给高 PriorityClass、诚实而克制的资源 requests：节点再满它们也必须调度上去，因为过载节点上缺席的监控 agent，恰在最需要 visibility 时致盲。没有需要手工调大小的伸缩旋钮，但调度要做对。 覆盖优先于数量 因为期望副本数本就隐含，一次滚动更新会触及每个成员：往池子里加一个节点，守护进程不用额外动作就自动出现。这是任何逐节点脚本都拼不过的保证。更新用 maxUnavailable 限 disruption 在舰队铺开——设 1 就逐节点刷新，舰队永不断覆盖。节点脚本的慢性病版本漂移，在结构上不可能：控制器把每节点收敛到同一模板，kubectl rollout status ds/agent 告诉你收敛何时完成。 ...

Pod 反亲和表达一个 Pod 应该避开哪些选中的同伴。主机拓扑可以减少共用节点的风险，可用区拓扑可以覆盖更大的故障域。规则不会创造额外容量，也不能证明应用已经具备高可用性；它负责影响落点，复制机制、就绪、存储与故障恢复仍然有各自职责。三个副本分开只是减少共同故障的一步，并非完整恢复方案。 强制规则过滤候选节点，偏好规则贡献评分。如果硬条件没有留下可行节点，新 Pod 会持续 Pending，直到相关条件改变。对严格隔离要求而言，这可能是正确结果，但必须提前计入容量规划，而不是在故障时才发现“不允许同处”的代价。偏好则允许权衡，不应被描述成几乎等同于硬性分离。 选中同伴，再定义拓扑域 labelSelector 识别同伴 Pod，topologyKey 指定用哪个节点标签划分它们所在的位置。kubernetes.io/hostname 通常区分节点，topology.kubernetes.io/zone 按可用区分组。应查看真实标签值，不要假定不同基础设施提供者都自动具备同一套标签；键存在但值错误，同样可能让故障域定义失真。 命名空间范围也是规则的一部分。既没有显式命名空间列表、也没有 namespaceSelector 时，默认匹配待调度 Pod 自己所在的命名空间。空的 namespaceSelector 对象则匹配所有命名空间。因此经过配置后，规则可以跨命名空间影响调度，并不是天然的租户隔离边界。审阅时必须把同伴标签与命名空间选择一起看，不能只看 app 名称。 相关节点需要一致的拓扑标签。Kubernetes 文档明确警告，缺少标签会导致意外的反亲和行为，但不能把这个警告简化成“所有未标记节点必定被接纳”或“必定被排除”。Pod 间规则、既有落点和 topology spread 是不同机制，需要查看真实规则与候选集合。直接把两种机制的缺失标签表现混在一起，会导向相反而同样错误的诊断。 硬规则可能形成放置上限 对于互相被选择器选中的副本，强制 hostname 反亲和通常让每个合格主机域最多容纳一个匹配副本。九个这样的副本放到六个合格节点，仍会有三个等待，哪怕节点还有很多 CPU。滚动更新的额外副本也可能先撞到同一道上限，所以容量规划不能只计算稳定状态的 replicas。 强制可用区反亲和同样会限制每区匹配同伴数量，但还需要检查准入配置。启用 LimitPodHardAntiAffinityTopology 时，强制反亲和的 topologyKey 被限制为 hostname。不能假定任何集群都会接受区域级硬规则，更不应在未核对允许拓扑之前就把它写进可用性设计。命令行没有执行到调度阶段，可能是准入先拒绝了清单。 ...

Annotation 为 Kubernetes 对象附加非识别性元数据，可以记录来源、负责人说明，或供工具消费的配置。标准标签选择器不会按 annotation 值筛选对象，但这并不意味着 annotation 没有作用。控制器、准入组件或发布工具都可能解释约定的键并改变行为。判断元数据修改的影响之前，应先确认具体消费者，不能仅凭字段名称认定它只是无害备注。 不参与选择，不等于没有校验 Annotation 的键和值都必须是字符串。键遵循限定名称格式，可以包含可选的 DNS 风格前缀和名称部分；一个对象的 annotation 键和值合计大小不能超过 256 KiB。因此，它不是不受限制的任意类型 JSON 存储。如果某个工具把 JSON 序列化后放进字符串，额外的格式与解释规则仍然由这个工具负责，而不是自动成为 Kubernetes 的通用语义。 自动化写入的键应使用负责组织控制的前缀。普通负责人说明与某个控制器专用参数，即使都位于同一张映射中，也具有不同含义。应记录哪个组件负责写入、哪个组件负责读取每个操作性键。来自另一种控制器、看起来很熟悉的 annotation，不能在没有核对契约时就当作可移植配置使用。 标签与 annotation 的选择角色也不同。标准选择器可以匹配标签表达式，而描述性的 annotation 通常需要另外读取和解释。这不意味着每一个任意标签都拥有专门存储索引，更不意味着 annotation 无法影响协调过程。字段选择应依据消费者的 API，而不是机械遵循“机器只读标签、人只读备注”的错误分工。 坏掉的样子 字段所在的位置会改变效果。修改 Deployment 顶层 metadata，与修改 spec.template 里面的 metadata，是不同操作。即使容器镜像和选择器标签没有改变，Pod 模板变化仍可能触发滚动更新。反过来，只写在 Deployment 对象上的 annotation，也不会自动变成 Pod 模板里的变化。审阅补丁时应明确完整字段路径，不能只比较键名。 ...

污点排斥没有容忍对应效果的 Pod，容忍度只移除这项障碍，不会强制把负载送到专用硬件。专用节点设计通常还需要标签与必要的节点亲和，再分别检查容量和准入策略。不能把通行资格理解成目的地保证，也不能把容忍度当成工作负载的完整权限边界。 给专用者的标记 NoSchedule 污点在未被容忍时，阻止普通的新调度，但不移动已有 Pod。这可以把 GPU 等专用节点留给特定负载。不能进一步概括为所有污点都不影响运行中程序：NoExecute 具有驱逐行为，PreferNoSchedule 则只是调度偏好。首先看清 effect，才能判断这次变更会影响新放置还是已有实例。 污点不是安全隔离。有权提交合适容忍度的主体可能获得池子资格，直接指定 nodeName 还会绕过普通调度检查。准入限制、授权和设备资源请求是另外的控制；一个 GPU 容忍度既没有请求 GPU，也不保证有空闲 GPU。审阅专用池时，需要同时核对谁能修改模板、谁能添加容忍度以及真正需要哪些硬件资源。 效果决定行为 NoSchedule 对未容忍的 Pod 构成硬性调度排除；PreferNoSchedule 提供软性避让偏好，单靠它不会让节点完全失去资格。NoExecute 还可能移除已经绑定、却没有匹配容忍度的 Pod。匹配 NoExecute 的容忍度可以带 tolerationSeconds，限定污点出现之后还能停留多久；不写时长与设置短时长具有不同后果。 执行基于污点驱逐的是相应驱逐控制器，不是调度器把正在运行的进程搬走。这不等同于 kubectl drain，中断预算处理与操作顺序并不相同。维护应选择适合的流程，先评估受影响负载，不要把 NoExecute 当成有同样保护栏的快速排空按钮。容忍过期引发的延迟动作同样需要纳入维护时间线。 配对即约定 本例演示 Equal 和 Exists 两种运算符，匹配由键、运算符、值及效果共同决定。Equal 比较值，Exists 忽略指定键的值；空 effect 覆盖所有效果。合法的空 key 需要 Exists，并把匹配扩展到所有键。应校验 API 格式，不能让不合法输入在本地模型里悄悄变成通配符；未来或其他版本的运算符也不在本例范围内。 ...

选择器让 Service 从一段固定列表变成动态视图：新增移除都在后台完成，Pod 重启时客户端无需改任何配置。 先声明，再分配地址 普通 ClusterIP Service 在对象存续期间提供虚拟地址，并在集群 DNS 支持下提供稳定发现名称。带选择器的 Service 还声明本命名空间中哪些 Pod 是预期后端。其他形态不同：无头服务不分配虚拟 IP，ExternalName 使用 DNS 间接引用，无选择器服务可以配合单独管理的 EndpointSlice。不能把每种 Service 都套进同一种分配流程。 地址稳定仅限 Service 对象存续期间，不是某个名称出现之后永远占用同一个地址。删除重建可能得到新地址。客户端应遵守约定的发现方式，并适当重新解析，而不是把抄下来的 ClusterIP 当成永久基础设施身份。这层稳定性主要隔离后端更替，不能消除对象本身重建和发现系统变化带来的影响。 选择器就是实时成员 EndpointSlice 控制器异步协调匹配 Pod 与端点条件。未就绪 Pod 可以继续出现在对象中，只是 ready 为 false，并非一定从所有端点对象里消失。消费者根据这些条件选择路由目标。publishNotReadyAddresses 会改变普通就绪解释，终止中端点又有额外处理细节，不能仅凭列表存在地址就断言后端应接收普通流量。 标签一致也不能证明请求健康。端口错误、不适当探针或过期数据路径仍然可能导致失败。应同时检查预期选择器与实际 EndpointSlice，再验证应用行为。自动协调减少手工维护后端名单，但不承诺瞬间更新，也不会消除所有漂移。控制面对象、节点转发和客户端连接各有自己的状态及更新时序。 Pod 变了地址依旧稳定 稳定目的地允许替换后端，而不必向调用方逐个公布 Pod IP，但不保证每次请求都不中断。已有连接可能仍关联旧后端，新连接依赖已经收敛的路由状态；没有可用端点的 Service 也不能制造缺失容量。不能因为名称没有改变，就认为所有连接已经自动迁移到新进程。 ...