Kubernetes 网络编程延迟Network Programming LatencySLI/SLO 解析度量 Service 后端变更在集群内负载均衡中的生效时延【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇文章基于 Kubernetes Community 仓库 SIG Scalability 的 SLO 定义文档sig-scalability/slos/network_programming_latency.md展开系统解读网络编程延迟这一 Service Level Indicator / Service Level ObjectiveSLI/SLO的设计动机、精确度量方法及其工程权衡。读完本文你将理解 Kubernetes 如何回答Service 的后端Backend就绪或下线后集群内的负载均衡规则如 iptables究竟需要多久才会生效这一关键性能问题并掌握基于 Endpoints 注解时间戳的官方测量方案。一、背景Kubernetes 如何定义可扩展性承诺Kubernetes 的规模化与性能保证并非一句空话而是被组织为可量化、可测试的 SLI 与 SLO。在 sig-scalability/slos/slos.md 中SIG Scalability 用 you promise, we promise 框架来界定承诺的边界用户承诺正确配置集群、合理使用扩展性特性、将集群负载控制在推荐阈值内Kubernetes 承诺在上述前提下集群的所有 SLO 均得到满足。其中网络编程延迟 SLI/SLO 正是这一框架下、目前仍处于WIPWork In Progress状态的一项指标用于覆盖用户对服务变更生效速度的预期。它与其他指标API 调用延迟、Pod 启动延迟、DNS 编程延迟等一同构成 Kubernetes 稳态steady state下的性能保证体系其总体清单可见 slos.md 的稳态 SLI/SLO 汇总表。二、SLI/SLO 定义网络编程延迟原文档给出的定义如下完整继承StatusSLISLOWIPLatency of programming in-cluster load balancing mechanism (e.g. iptables), measured from when service spec or list of itsReadypods change to when it is reflected in load balancing mechanism, measured as 99th percentile over last 5 minutes aggregated across all programmersIn default Kubernetes installation, 99th percentile per cluster-day X脚注原文档原文Aggregation across all programmers means that all samples from all programmers go into one large pool, and SLI is percentile from all of them. 对所有 programmer 的聚合意味着来自所有 programmer 的全部样本汇入一个大的样本池SLI 是该池的分位数。拆解定义中的关键术语in-cluster load balancing mechanism集群内负载均衡机制默认指 kube-proxy 基于 iptables或 IPVS、nftables 等后端为 Service 维护的转发规则。所谓 programmer即负责把 Service 的期望状态写入该机制的控制组件——默认安装下即 kube-proxy测量起点Service spec 发生变化或 Service 的ReadyPod 列表发生变化即 Pod 在Ready/NotReady之间转换测量终点上述变化被反映reflected到负载均衡机制中统计口径以最近 5 分钟为窗口的 99 百分位且对所有 programmer 聚合SLO 目标默认 Kubernetes 安装下每个集群日per cluster-day的 99 百分位 X——注意阈值 X 目前尚未确定这正是该指标处于 WIP 状态的标志之一。结合 slos.md 的脚注per cluster-day 的含义可以理解为对一天内的分钟进行统计即每天中好分钟满足阈值所占比例的滑动窗口表述。三、用户故事该 SLO 试图解决的三个问题原文档以用户故事User stories形式明确了这一指标要服务的真实诉求作为 vanilla Kubernetes 用户我希望得到某种保证我的 Service 的新后端能以多快的速度成为集群内负载均衡的目标作为 vanilla Kubernetes 用户我希望得到某种保证我的 Service 被删除或不健康的后端能以多快的速度从集群内负载均衡中被移除作为 vanilla Kubernetes 用户我希望得到某种保证对 Service spec 的变更包括新建 Service能多快反映到集群内负载均衡中。三条用户故事覆盖了负载均衡编程的三种典型变更新增后端、移除后端、修改 Service 定义。它们共同指向一个事实——Kubernetes 的数据面转发规则并非即时更新的kube-proxy 需要监听 Service/Endpoints 的变化、重新计算并写回规则这一过程存在可感知的延迟而用户对此有明确的体验预期。四、设计取舍为什么只承诺集群内负载均衡原文档的 Other notes 部分记录了设计时的两个关键决策聚焦 in-cluster 负载均衡外部负载均衡External load-balancing明显与云厂商/环境强相关很难为它设定统一合理的 SLO因此被排除在本次指标之外未来可扩展文档明确指出未来完全可能以几乎相同的方式为外部负载均衡制定 SLI以保证口径的一致性被否决的备选方案曾经考虑过从 Pod 创建开始测量端到端时间的 SLI但因其与应用强相关不同应用的启动特性差异巨大引入 SLO 将不可能实现故被否决。这一取舍与仓库中其他性能资料相互印证。在 sig-scalability/blogs/k8s-services-scalability-issues.md 中SIG Scalability 详细记录了 iptables 数据面的真实瓶颈当集群中 Service 端口数量很大时KUBE-SERVICES链会变长且被高频评估拖累报文处理性能当后端数量超过 10 万时kube-proxy 的iptables-restore还可能因拿不到 xtables 锁而超时。这些现象恰恰说明规则编程速度是真实存在、且随规模恶化的关键性能维度——这正是网络编程延迟 SLI 存在的工程依据。五、聚合方式的选择为什么聚合发生在 SLO 层而非 SLI 层原文档的 Caveats 部分解释了一个非常精巧的设计决策该 SLI 聚合的是所有 programmer 的样本池而不是要求从 99% 的 programmer 视角可见。原因在于计算可行性feasibility从最终用户视角看聚合所有 programmer 才是真正关心的——少量 programmer 完全无响应只要其他 programmer 足够快是可以接受的因为在足够大的规模下必然存在一些慢速或无响应的节点SLO 必须允许这种情况发生如果在 SLI 层做聚合即把指标表述为...反映到集群内负载均衡机制中并从 99% 的 programmer 可见那么要判断某个 Pod 转换到 Ready 是否已被反映就必须知道它在 99% 的 programmer如 iptables中具体生效的时刻——这要求对每一次变更单独跟踪指标无法高效实现。因此度量层面采用单一时间戳 单个 programmer 的完成时间的简单方案统计层面再做池化聚合兼顾了用户语义与工程可行性。六、测量方法基于 Endpoints 注解的时间戳方案网络编程延迟的测量方法并不直观原文档专门用一节描述了计划的实现方式含全部注意事项。核心思路是在 Endpoints 对象上记录触发变更的时间戳再由 programmer 在完成编程时记录完成时间两者之差即延迟。具体步骤假设集群内负载均衡编程以 KubernetesEndpoints对象为输入即默认的 kube-proxy 数据来源新增注解为Endpoints对象引入一个专用注解名称 TBD待定Endpoints controller 写入时间戳controller 在更新某个Endpoints对象时将该注解的值设置为触发本次更新的变更时间戳对于 Pod 在Ready与NotReady之间的状态转换其时间戳直接取自 Pod conditionPod 状态本身已携带该信息对于 Service 更新时间戳来源为 TBD——理想方案是在对象 metadata 中新增LastUpdateTimestamp字段置于已有的CreationTimestamp旁边。文档特别指出这些数据在存储层etcd已经存在传播出来并不困难programmer 导出指标集群内负载均衡 programmer默认即 kube-proxy在完成一次编程后导出一个 Prometheus 指标该次操作的延迟定义为编程完成的时间戳与新注解中记录的时间戳之差。从 Kubernetes 的控制流看这条测量链路正好横跨两个关键组件Endpoints controller写入注解→ kube-proxy消费 Endpoints、编程 iptables、导出指标。由于 Endpoints controller 与 kube-proxy 都基于 informer/watch 机制工作这一方案天然与 slos.md 中列出的其他指标 共享同一套事件观察基础设施无需额外埋点即可获得触发端时间。七、测量方法的局限与工程妥协原文档为上述测量方案列出了三条 caveats揭示了在真实集群中实现精确测量必须做的妥协单个 Endpoints 对象可能批量合并多次 Pod 状态转换此时只选择最旧的一个时间戳不暴露全部时间戳以避免对象理论上无界增长。这会使指标不够精确但由于批处理周期相对于整个端到端流程而言很小误差可接受单个 Pod 可能在批处理周期内多次转换状态为此Endpoints controller 需要增加一个额外缓存记录每个 Pod 首次被观察到的转换时间戳该缓存条目在 controller 把 Pod 纳入 Endpoints 对象更新时清除。这与上一点选择最旧更新的策略保持一致。文档也提到最初实现时可以考虑暂时忽略这一事实组件可能滑出 watch 窗口历史而丢失部分 watch 事件这在 Endpoints controller 或 kube-proxy以及其他网络 programmer上都可能发生。只有当同一对象在此期间发生多次变更时才成为问题否则 informer 在重新 list 时会补发 handler。并且这只可能发生在组件处理事件过慢这本身已会反映在指标中或 kube-apiserver 重启之后。基于收益甚微、徒增复杂度的考虑文档明确决定忽略这一问题。这三条妥协体现了一个共同原则用工程上可控的近似换取可落地的精确语义——避免对象元数据无界膨胀、避免缓存复杂化、避免为罕见场景引入过度设计。八、与仓库内其他 SLI/SLO 及限制条件的关联网络编程延迟并非孤立指标它与仓库中的其他文档存在紧密关联SLO 汇总登记该指标已在 slos.md 的稳态 SLI/SLO 表 中登记状态为 WIPSLO 阈值为 X同构的 DNS 编程延迟sig-scalability/slos/dns_programming_latency.md 中明确指出DNS 编程延迟以几乎完全相同的方式表述其测量方法完全一致并直接引用本文档的 How to measure the SLI 一节。区别仅在于programmer换成了 DNS 实例且 DNS SLI 额外要求发布延迟不随记录数增长而变化例如 headless Service 上千 Pod 场景下第一个与最后一个 Pod 的 A/AAAA 记录发布延迟应统计一致端到端视角的补充sig-scalability/slos/network_latency.md 从单个 prober Pod 的视角测量集群内网络往返延迟其文档明确指出该端到端流程其中就包括 in-cluster 网络编程机制如 iptables的延迟——即网络编程延迟是端到端网络延迟的组成部分二者视角互补负载前提SLO 的满足依赖集群负载处于 sig-scalability/configs-and-limits/thresholds.md 定义的阈值内例如每个 Service 的 Endpoints 数上限 250、集群 Services 总数上限 10,000、节点数上限 5,000 等。这些阈值划定了默认安装下该 SLO 的适用边界背景佐证sig-scalability/blogs/k8s-services-scalability-issues.md 记录的 iptables 链过长、iptables-restore锁竞争、apiserver 重复序列化 Endpoints 消耗 CPU 等问题正是推动该 SLI 立项的现实背景。九、现状与展望截至本仓库当前版本网络编程延迟 SLI/SLO 仍处于WIP状态关键参数尚未定稿SLO 阈值X未确定Endpoints专用注解的名称 TBDService 更新时间戳来源的LastUpdateTimestamp字段方案待定原文档的 Test scenario 一节 标注为__TODO: Describe test scenario.__即正式测试场景尚未成文。从文档脉络可以推断后续工作将围绕敲定注解/字段方案 → 实现 Endpoints controller 时间戳写入 → 在 kube-proxy 导出 Prometheus 指标 → 设计并固化测试场景 → 确定 X 的具体数值展开。对于希望跟踪或贡献该指标的开发者可以持续关注 sig-scalability/slos 目录下的文档演进以及 SIG Scalability 的总体 SLI/SLO 定义 中该条目状态的更新。对于集群运维与平台开发者而言即使该 SLO 尚未正式生效其测量思路Endpoints 注解时间戳 programmer 完成时间与设计取舍SLO 层聚合、最旧时间戳近似本身就提供了有价值的参考它示范了如何在分布式控制面中用最小的埋点成本获得变更生效延迟这一关键可观测性指标。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Kubernetes 网络编程延迟（Network Programming Latency）SLI/SLO 解析：度量 Service 后端变更在集群内负载均衡中的生效时延
Kubernetes 网络编程延迟Network Programming LatencySLI/SLO 解析度量 Service 后端变更在集群内负载均衡中的生效时延【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community本篇文章基于 Kubernetes Community 仓库 SIG Scalability 的 SLO 定义文档sig-scalability/slos/network_programming_latency.md展开系统解读网络编程延迟这一 Service Level Indicator / Service Level ObjectiveSLI/SLO的设计动机、精确度量方法及其工程权衡。读完本文你将理解 Kubernetes 如何回答Service 的后端Backend就绪或下线后集群内的负载均衡规则如 iptables究竟需要多久才会生效这一关键性能问题并掌握基于 Endpoints 注解时间戳的官方测量方案。一、背景Kubernetes 如何定义可扩展性承诺Kubernetes 的规模化与性能保证并非一句空话而是被组织为可量化、可测试的 SLI 与 SLO。在 sig-scalability/slos/slos.md 中SIG Scalability 用 you promise, we promise 框架来界定承诺的边界用户承诺正确配置集群、合理使用扩展性特性、将集群负载控制在推荐阈值内Kubernetes 承诺在上述前提下集群的所有 SLO 均得到满足。其中网络编程延迟 SLI/SLO 正是这一框架下、目前仍处于WIPWork In Progress状态的一项指标用于覆盖用户对服务变更生效速度的预期。它与其他指标API 调用延迟、Pod 启动延迟、DNS 编程延迟等一同构成 Kubernetes 稳态steady state下的性能保证体系其总体清单可见 slos.md 的稳态 SLI/SLO 汇总表。二、SLI/SLO 定义网络编程延迟原文档给出的定义如下完整继承StatusSLISLOWIPLatency of programming in-cluster load balancing mechanism (e.g. iptables), measured from when service spec or list of itsReadypods change to when it is reflected in load balancing mechanism, measured as 99th percentile over last 5 minutes aggregated across all programmersIn default Kubernetes installation, 99th percentile per cluster-day X脚注原文档原文Aggregation across all programmers means that all samples from all programmers go into one large pool, and SLI is percentile from all of them. 对所有 programmer 的聚合意味着来自所有 programmer 的全部样本汇入一个大的样本池SLI 是该池的分位数。拆解定义中的关键术语in-cluster load balancing mechanism集群内负载均衡机制默认指 kube-proxy 基于 iptables或 IPVS、nftables 等后端为 Service 维护的转发规则。所谓 programmer即负责把 Service 的期望状态写入该机制的控制组件——默认安装下即 kube-proxy测量起点Service spec 发生变化或 Service 的ReadyPod 列表发生变化即 Pod 在Ready/NotReady之间转换测量终点上述变化被反映reflected到负载均衡机制中统计口径以最近 5 分钟为窗口的 99 百分位且对所有 programmer 聚合SLO 目标默认 Kubernetes 安装下每个集群日per cluster-day的 99 百分位 X——注意阈值 X 目前尚未确定这正是该指标处于 WIP 状态的标志之一。结合 slos.md 的脚注per cluster-day 的含义可以理解为对一天内的分钟进行统计即每天中好分钟满足阈值所占比例的滑动窗口表述。三、用户故事该 SLO 试图解决的三个问题原文档以用户故事User stories形式明确了这一指标要服务的真实诉求作为 vanilla Kubernetes 用户我希望得到某种保证我的 Service 的新后端能以多快的速度成为集群内负载均衡的目标作为 vanilla Kubernetes 用户我希望得到某种保证我的 Service 被删除或不健康的后端能以多快的速度从集群内负载均衡中被移除作为 vanilla Kubernetes 用户我希望得到某种保证对 Service spec 的变更包括新建 Service能多快反映到集群内负载均衡中。三条用户故事覆盖了负载均衡编程的三种典型变更新增后端、移除后端、修改 Service 定义。它们共同指向一个事实——Kubernetes 的数据面转发规则并非即时更新的kube-proxy 需要监听 Service/Endpoints 的变化、重新计算并写回规则这一过程存在可感知的延迟而用户对此有明确的体验预期。四、设计取舍为什么只承诺集群内负载均衡原文档的 Other notes 部分记录了设计时的两个关键决策聚焦 in-cluster 负载均衡外部负载均衡External load-balancing明显与云厂商/环境强相关很难为它设定统一合理的 SLO因此被排除在本次指标之外未来可扩展文档明确指出未来完全可能以几乎相同的方式为外部负载均衡制定 SLI以保证口径的一致性被否决的备选方案曾经考虑过从 Pod 创建开始测量端到端时间的 SLI但因其与应用强相关不同应用的启动特性差异巨大引入 SLO 将不可能实现故被否决。这一取舍与仓库中其他性能资料相互印证。在 sig-scalability/blogs/k8s-services-scalability-issues.md 中SIG Scalability 详细记录了 iptables 数据面的真实瓶颈当集群中 Service 端口数量很大时KUBE-SERVICES链会变长且被高频评估拖累报文处理性能当后端数量超过 10 万时kube-proxy 的iptables-restore还可能因拿不到 xtables 锁而超时。这些现象恰恰说明规则编程速度是真实存在、且随规模恶化的关键性能维度——这正是网络编程延迟 SLI 存在的工程依据。五、聚合方式的选择为什么聚合发生在 SLO 层而非 SLI 层原文档的 Caveats 部分解释了一个非常精巧的设计决策该 SLI 聚合的是所有 programmer 的样本池而不是要求从 99% 的 programmer 视角可见。原因在于计算可行性feasibility从最终用户视角看聚合所有 programmer 才是真正关心的——少量 programmer 完全无响应只要其他 programmer 足够快是可以接受的因为在足够大的规模下必然存在一些慢速或无响应的节点SLO 必须允许这种情况发生如果在 SLI 层做聚合即把指标表述为...反映到集群内负载均衡机制中并从 99% 的 programmer 可见那么要判断某个 Pod 转换到 Ready 是否已被反映就必须知道它在 99% 的 programmer如 iptables中具体生效的时刻——这要求对每一次变更单独跟踪指标无法高效实现。因此度量层面采用单一时间戳 单个 programmer 的完成时间的简单方案统计层面再做池化聚合兼顾了用户语义与工程可行性。六、测量方法基于 Endpoints 注解的时间戳方案网络编程延迟的测量方法并不直观原文档专门用一节描述了计划的实现方式含全部注意事项。核心思路是在 Endpoints 对象上记录触发变更的时间戳再由 programmer 在完成编程时记录完成时间两者之差即延迟。具体步骤假设集群内负载均衡编程以 KubernetesEndpoints对象为输入即默认的 kube-proxy 数据来源新增注解为Endpoints对象引入一个专用注解名称 TBD待定Endpoints controller 写入时间戳controller 在更新某个Endpoints对象时将该注解的值设置为触发本次更新的变更时间戳对于 Pod 在Ready与NotReady之间的状态转换其时间戳直接取自 Pod conditionPod 状态本身已携带该信息对于 Service 更新时间戳来源为 TBD——理想方案是在对象 metadata 中新增LastUpdateTimestamp字段置于已有的CreationTimestamp旁边。文档特别指出这些数据在存储层etcd已经存在传播出来并不困难programmer 导出指标集群内负载均衡 programmer默认即 kube-proxy在完成一次编程后导出一个 Prometheus 指标该次操作的延迟定义为编程完成的时间戳与新注解中记录的时间戳之差。从 Kubernetes 的控制流看这条测量链路正好横跨两个关键组件Endpoints controller写入注解→ kube-proxy消费 Endpoints、编程 iptables、导出指标。由于 Endpoints controller 与 kube-proxy 都基于 informer/watch 机制工作这一方案天然与 slos.md 中列出的其他指标 共享同一套事件观察基础设施无需额外埋点即可获得触发端时间。七、测量方法的局限与工程妥协原文档为上述测量方案列出了三条 caveats揭示了在真实集群中实现精确测量必须做的妥协单个 Endpoints 对象可能批量合并多次 Pod 状态转换此时只选择最旧的一个时间戳不暴露全部时间戳以避免对象理论上无界增长。这会使指标不够精确但由于批处理周期相对于整个端到端流程而言很小误差可接受单个 Pod 可能在批处理周期内多次转换状态为此Endpoints controller 需要增加一个额外缓存记录每个 Pod 首次被观察到的转换时间戳该缓存条目在 controller 把 Pod 纳入 Endpoints 对象更新时清除。这与上一点选择最旧更新的策略保持一致。文档也提到最初实现时可以考虑暂时忽略这一事实组件可能滑出 watch 窗口历史而丢失部分 watch 事件这在 Endpoints controller 或 kube-proxy以及其他网络 programmer上都可能发生。只有当同一对象在此期间发生多次变更时才成为问题否则 informer 在重新 list 时会补发 handler。并且这只可能发生在组件处理事件过慢这本身已会反映在指标中或 kube-apiserver 重启之后。基于收益甚微、徒增复杂度的考虑文档明确决定忽略这一问题。这三条妥协体现了一个共同原则用工程上可控的近似换取可落地的精确语义——避免对象元数据无界膨胀、避免缓存复杂化、避免为罕见场景引入过度设计。八、与仓库内其他 SLI/SLO 及限制条件的关联网络编程延迟并非孤立指标它与仓库中的其他文档存在紧密关联SLO 汇总登记该指标已在 slos.md 的稳态 SLI/SLO 表 中登记状态为 WIPSLO 阈值为 X同构的 DNS 编程延迟sig-scalability/slos/dns_programming_latency.md 中明确指出DNS 编程延迟以几乎完全相同的方式表述其测量方法完全一致并直接引用本文档的 How to measure the SLI 一节。区别仅在于programmer换成了 DNS 实例且 DNS SLI 额外要求发布延迟不随记录数增长而变化例如 headless Service 上千 Pod 场景下第一个与最后一个 Pod 的 A/AAAA 记录发布延迟应统计一致端到端视角的补充sig-scalability/slos/network_latency.md 从单个 prober Pod 的视角测量集群内网络往返延迟其文档明确指出该端到端流程其中就包括 in-cluster 网络编程机制如 iptables的延迟——即网络编程延迟是端到端网络延迟的组成部分二者视角互补负载前提SLO 的满足依赖集群负载处于 sig-scalability/configs-and-limits/thresholds.md 定义的阈值内例如每个 Service 的 Endpoints 数上限 250、集群 Services 总数上限 10,000、节点数上限 5,000 等。这些阈值划定了默认安装下该 SLO 的适用边界背景佐证sig-scalability/blogs/k8s-services-scalability-issues.md 记录的 iptables 链过长、iptables-restore锁竞争、apiserver 重复序列化 Endpoints 消耗 CPU 等问题正是推动该 SLI 立项的现实背景。九、现状与展望截至本仓库当前版本网络编程延迟 SLI/SLO 仍处于WIP状态关键参数尚未定稿SLO 阈值X未确定Endpoints专用注解的名称 TBDService 更新时间戳来源的LastUpdateTimestamp字段方案待定原文档的 Test scenario 一节 标注为__TODO: Describe test scenario.__即正式测试场景尚未成文。从文档脉络可以推断后续工作将围绕敲定注解/字段方案 → 实现 Endpoints controller 时间戳写入 → 在 kube-proxy 导出 Prometheus 指标 → 设计并固化测试场景 → 确定 X 的具体数值展开。对于希望跟踪或贡献该指标的开发者可以持续关注 sig-scalability/slos 目录下的文档演进以及 SIG Scalability 的总体 SLI/SLO 定义 中该条目状态的更新。对于集群运维与平台开发者而言即使该 SLO 尚未正式生效其测量思路Endpoints 注解时间戳 programmer 完成时间与设计取舍SLO 层聚合、最旧时间戳近似本身就提供了有价值的参考它示范了如何在分布式控制面中用最小的埋点成本获得变更生效延迟这一关键可观测性指标。【免费下载链接】communityKubernetes Community Documentation项目地址: https://gitcode.com/GitHub_Trending/com/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
