Kubernetes

Requests 参与放置和资源共享，limits 约束运行时消耗。它们是有关联的输入，不是对应用性能的一套通用下限与上限保证。应结合负载行为、争用风险和恢复要求选择，并查看准入后的 Pod，因为默认值与策略可能改变清单里提交的资源值。先区分记账、实际使用和执行约束，才能解释配置为什么影响行为。 解释放置前先读准入后的请求。CPU 节流和内存压力具有不同机制，需要关联证据；资源字段都不保证应用性能。 默认值也是契约的一部分 某资源只有 limit、没有 request 时，如果准入没有提供另一请求，Kubernetes 会把限制复制为请求。因此，只配 limit 通常不是零调度成本。LimitRange 默认值与 ResourceQuota 检查也会影响准入。解释 Pod 为什么 Pending 之前，应读取实际保存的两张资源映射，不能仅凭源文件中某一字段缺失进行判断。 Request 不会预先分配应用的物理内存，也不必然独占 CPU 核心。CPU 请求参与调度及争用时的相对份额。没有 CPU limit 的容器可以利用超过请求的空闲 CPU，但节点容量、祖先约束和竞争负载仍然构成边界。省略限制可能是有意选择，应配套明确容量和争用策略，而不是简单认定只配一边必然错误。 Linux 上 CPU limit 通常通过带宽节流执行，耗尽配额本身不会直接杀死进程。但等待可能增加延迟、触发应用超时或影响探针。整机 CPU 平均值低，也不能排除某个上限很紧的容器正在频繁节流。要比较对应时间窗口的需求、配额和等待，而不是拿整机平均值替代容器约束。 ...

NodePort 类型的 Service 分配一个集群范围的端口，并通过符合配置的节点地址转发流量。它适用于外部负载均衡、开发环境及有明确用途的服务暴露，但不保证每台机器的每个地址都能访问，也不保证每台节点都有一个普通应用监听套接字。路由、防火墙、代理实现与流量策略仍然决定真实访问路径，不能从 Service 类型推断全部网络条件。 NodePort 通过符合配置的节点地址转发到后端端口。Cluster 与 Local 改变端点候选范围；端口分配不能证明应用可达。本次未重跑诊断。 一次分配，多种转发路径 默认分配范围为 30000–32767，管理员可以配置其他范围。请求指定 nodePort 时，只有分配与校验允许才会成功；端口冲突会拒绝 API 事务，通常不是先创建一个对象，再悄悄留下不可用端口。应分别核对命令退出状态与实际保存的对象，不能把创建失败解释成运行期网络故障。 Service port、targetPort 与 nodePort 各有职责：前者是虚拟服务入口，中间值指定后端端口，最后一个是节点侧入口。多端口 Service 可以占用多个号码。LoadBalancer 类型也可能分配 NodePort，除非配置与实现允许省略。因此，仅统计类型为 NodePort 的对象，会漏掉地址池的部分实际使用者，第一端口也不代表整份清单。 ...

PodDisruptionBudget 限制一组选中 Pod 通过驱逐产生的中断。它可以协助维护期间保留服务容量或法定多数，但不能保证两者必然存在。保护取决于调用者使用 Eviction API、选择器选中正确成员，以及 Ready 条件真正反映应用所需能力。只建立一份对象而不核对这些前提，并不能让维护自动安全。 允许中断多少，应来自应用的失败模型。三成员多数派系统通常需要两个正常成员，但 Pod 就绪本身不证明成员身份、数据同步或成员之间的连通性。PDB 是应用健康检查与维护流程的补充，不会理解数据库协议，也不会自动纠正已经失去同步却仍报告 Ready 的副本。 PDB 约束的是特定驱逐路径。把额度视为安全维护余量前，先核对成员选择、就绪状态、策略与应用健康。 保护边界在驱逐接口 节点崩溃、网络分区和节点压力驱逐，都不会被 PDB 阻止。但已经不可用的成员仍可能减少后续维护可使用的额度。直接删除 Pod 或整个工作负载会绕过预算，工作负载控制器正常滚动更新时的删除也不受它限制。因此“主动中断”不自动等于“必然经过预算保护”，必须看实际调用路径。 ...

Deployment 主要表达副本总数，DaemonSet 主要表达合格节点的覆盖范围，适合节点日志采集、网络代理和设备插件。新节点符合条件后会触发协调工作，不代表服务立刻运行或就绪。节点选择、调度容量、镜像拉取、初始化和节点故障，都可能延迟真正有用的覆盖；这些环节需要分别观察。 控制器根据共享模板创建并协调 Pod，通常以每个合格节点一个受管理 Pod 为期望，而不是依赖手工维护副本总数。期望覆盖与实际就绪是两种指标。还应独立定义运维希望覆盖的节点集合，避免选择器写错后，被排除的机器同时从期望数和审计视野中消失。 每节点一个、天生如此 控制器评估节点选择器与必要亲和条件，为每个合格节点创建定向 Pod，通常再由调度器绑定。节点加入和离开会改变期望集合。DaemonSet Pod 自动容忍 unschedulable 污点，因此只执行 cordon 不会排除它们。节点注册并不保证调度、镜像获取和初始化在同一时刻完成，也不保证每台机器已经具备可用日志采集能力。 优先级可以帮助重要守护进程抢占低优先级工作负载，却不会创造容量或消除冲突的放置条件。应按真实重要性和业务影响选择 PriorityClass 与资源请求。Pod 可能一直 Pending，也可能调度后启动失败；高优先级和容忍都不能证明已经就绪，更不意味着免受节点压力驱逐。 覆盖优先于数量 RollingUpdate 会按策略替换 Pod；OnDelete 则等待旧 Pod 被删除后，才使用更新模板创建替代者。maxSurge 为零时，maxUnavailable 为一允许某个节点在更新期间暂时不可用，并不保证每节点不断档。非零 maxSurge 可以让同一节点暂时同时运行新旧 Pod，需要额外资源。更新期间存在版本差异是正常现象，阻塞会使差异持续。kubectl rollout status ds/agent 报告控制器进度，不能证明日志交付连续。 选择器与亲和可以把异构节点分成有意定义的子集，GPU 设备插件与边缘日志转发器不一定使用同一个 DaemonSet。检查各子集真正应该包含哪些节点，区分有意排除与预期代理缺席。跨池比较前还要确认标签来源可靠，不能把一个看起来合理的标签直接当成硬件或运行能力证明。 跟着节点生命周期走 控制器会自动添加文档规定的容忍，包括 not-ready、unreachable、若干压力污点及 unschedulable。控制平面或硬件自定义污点仍可能需要显式容忍。容忍只是允许跨过匹配污点，不会主动选择节点，也不保证满足其他约束。标签变化可能改变成员集合；应观察实际协调结果，不能假定不同守护集合之间是原子交接。 ...

Pod 反亲和表达一个 Pod 应该避开哪些选中的同伴。主机拓扑可以减少共用节点的风险，可用区拓扑可以覆盖更大的故障域。规则不会创造额外容量，也不能证明应用已经具备高可用性；它负责影响落点，复制机制、就绪、存储与故障恢复仍然有各自职责。三个副本分开只是减少共同故障的一步，并非完整恢复方案。 强制规则过滤候选节点，偏好规则贡献评分。如果硬条件没有留下可行节点，新 Pod 会持续 Pending，直到相关条件改变。对严格隔离要求而言，这可能是正确结果，但必须提前计入容量规划，而不是在故障时才发现“不允许同处”的代价。偏好则允许权衡，不应被描述成几乎等同于硬性分离。 强制反亲和让选中的同伴避开已经占用的拓扑域；拓扑分布则限制候选放置的数量差。两者都依赖选择器、命名空间范围、合格域和其他约束。 选中同伴，再定义拓扑域 labelSelector 识别同伴 Pod，topologyKey 指定用哪个节点标签划分它们所在的位置。kubernetes.io/hostname 通常区分节点，topology.kubernetes.io/zone 按可用区分组。应查看真实标签值，不要假定不同基础设施提供者都自动具备同一套标签；键存在但值错误，同样可能让故障域定义失真。 ...

Annotation 为 Kubernetes 对象附加非识别性元数据，可以记录来源、负责人说明，或供工具消费的配置。标准标签选择器不会按 annotation 值筛选对象，但这并不意味着 annotation 没有作用。控制器、准入组件或发布工具都可能解释约定的键并改变行为。判断元数据修改的影响之前，应先确认具体消费者，不能仅凭字段名称认定它只是无害备注。 历史 Deployment 样例对比顶层与 Pod 模板 annotation。generation 本身不是滚动更新证据。本次绘图未重跑集群样例。 不参与选择，不等于没有校验 Annotation 的键和值都必须是字符串。键遵循限定名称格式，可以包含可选的 DNS 风格前缀和名称部分；一个对象的 annotation 键和值合计大小不能超过 256 KiB。因此，它不是不受限制的任意类型 JSON 存储。如果某个工具把 JSON 序列化后放进字符串，额外的格式与解释规则仍然由这个工具负责，而不是自动成为 Kubernetes 的通用语义。 ...

污点排斥没有容忍对应效果的 Pod，容忍度只移除这项障碍，不会强制把负载送到专用硬件。专用节点设计通常还需要标签与必要的节点亲和，再分别检查容量和准入策略。不能把通行资格理解成目的地保证，也不能把容忍度当成工作负载的完整权限边界。 容忍度移除匹配污点这一项障碍。效果决定后果，放置与权限仍是其他机制。 给专用者的标记 NoSchedule 污点在未被容忍时，阻止普通的新调度，但不移动已有 Pod。这可以把 GPU 等专用节点留给特定负载。不能进一步概括为所有污点都不影响运行中程序：NoExecute 具有驱逐行为，PreferNoSchedule 则只是调度偏好。首先看清 effect，才能判断这次变更会影响新放置还是已有实例。 污点不是安全隔离。有权提交合适容忍度的主体可能获得池子资格，直接指定 nodeName 还会绕过普通调度检查。准入限制、授权和设备资源请求是另外的控制；一个 GPU 容忍度既没有请求 GPU，也不保证有空闲 GPU。审阅专用池时，需要同时核对谁能修改模板、谁能添加容忍度以及真正需要哪些硬件资源。 效果决定行为 NoSchedule 对未容忍的 Pod 构成硬性调度排除；PreferNoSchedule 提供软性避让偏好，单靠它不会让节点完全失去资格。NoExecute 还可能移除已经绑定、却没有匹配容忍度的 Pod。匹配 NoExecute 的容忍度可以带 tolerationSeconds，限定污点出现之后还能停留多久；不写时长与设置短时长具有不同后果。 ...

选择器让 Service 从一段固定列表变成动态视图：新增移除都在后台完成，Pod 重启时客户端无需改任何配置。 地址稳定受 Service 对象存续期限定。成员关系、路由收敛与请求成功仍需分别看待。精确分配模型本轮再次通过，仅验证台账；未执行 Kubernetes。 先声明，再分配地址 普通 ClusterIP Service 在对象存续期间提供虚拟地址，并在集群 DNS 支持下提供稳定发现名称。带选择器的 Service 还声明本命名空间中哪些 Pod 是预期后端。其他形态不同：无头服务不分配虚拟 IP，ExternalName 使用 DNS 间接引用，无选择器服务可以配合单独管理的 EndpointSlice。不能把每种 Service 都套进同一种分配流程。 地址稳定仅限 Service 对象存续期间，不是某个名称出现之后永远占用同一个地址。删除重建可能得到新地址。客户端应遵守约定的发现方式，并适当重新解析，而不是把抄下来的 ClusterIP 当成永久基础设施身份。这层稳定性主要隔离后端更替，不能消除对象本身重建和发现系统变化带来的影响。 ...