Red Hat Summit 红帽全球峰会支持控制台（Console）开发人员开始试用联系人

3.11. 在 control plane 节点间测量网络 jitter

heartbeat 间隔的值应当大约在成员之间平均往返用时(RTT)的最大值，通常往返时间大约为 1.5 倍。OpenShift Container Platform 默认心跳间隔为 100 ms，在 control plane 节点间推荐的 RTT 小于大约 33 毫秒，且最大小于 66 ms (66 ms 乘以 1.5 等于 99 ms)。如需更多信息，请参阅"为 etcd 设置调优参数"。任何较高网络延迟都可能会导致服务影响事件和集群不稳定。

网络延迟会受到很多因素的影响，包括但不限于以下因素：

  • 传输网络的技术，如 copper、fiber、wireless 或 satellite
  • 传输网络中网络设备的数量和质量

好的评估参考是将机构中的网络延迟与电信供应商发布的商业延迟进行比较，如每月 IP 延迟统计。

对于更准确的计算，请考虑网络延迟网络延迟。网络 jitter 是网络延迟的差异，或者更具体地说，接收的数据包的延迟变化。在理想的网络条件上，jitter 尽可能接近零。网络 jitter 影响 etcd 的网络延迟计算，因为一段时间内的实际网络延迟将是 RTT 加减的 jitter。例如，一个最大延迟为 80 ms 和 jitter 为 30 ms 的网络会出现 110 ms 的延迟，这意味着 etcd 缺少心跳，从而导致请求超时和临时领导丢失。在领导丢失和重新选举的过程中，Kubernetes API 无法处理任何请求，并可能出现对集群服务有影响的事件，并造成集群不稳定。

务必要测量所有 control plane 节点之间的网络 jitter。为此，您可以在 UDP 模式下使用 iPerf3 工具。

前提条件

流程

  1. 连接到其中一个 control plane 节点，并在主机网络模式下运行 iPerf 容器作为 iPerf 服务器。当您以服务器模式运行时，工具接受 TCP 和 UDP 测试。输入以下命令，请小心将 < iperf_image> 替换为您的 iPerf 镜像： 

    # podman run -ti --rm --net host <iperf_image> iperf3 -s
    Copy to Clipboard Toggle word wrap

  2. 输入以下命令连接到另一个 control plane 节点，并在 UDP 客户端模式下运行 iPerf ： 

    # podman run -ti --rm --net host <iperf_image> iperf3 -u -c <node_iperf_server> -t 300
    Copy to Clipboard Toggle word wrap

    默认测试运行了 10 秒，最后，客户端输出显示客户端的角度来看的平均 jitter。

  3. 输入以下命令运行 debug 节点模式： 

    # oc debug node/m1
    Copy to Clipboard Toggle word wrap

    输出示例

    Starting pod/m1-debug ...
To use host binaries, run `chroot /host`
Pod IP: 198.18.111.13
If you don't see a command prompt, try pressing enter.
    Copy to Clipboard Toggle word wrap

  4. 输入以下命令： 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap 
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -u -c m0
    Copy to Clipboard Toggle word wrap

    输出示例

    Connecting to host m0, port 5201
[  5] local 198.18.111.13 port 60878 connected to 198.18.111.12 port 5201
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   1.00-2.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   2.00-3.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   3.00-4.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   4.00-5.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   5.00-6.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   6.00-7.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   7.00-8.00   sec   129 KBytes  1.05 Mbits/sec  91
[  5]   8.00-9.00   sec   127 KBytes  1.04 Mbits/sec  90
[  5]   9.00-10.00  sec   129 KBytes  1.05 Mbits/sec  91
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec  1.25 MBytes  1.05 Mbits/sec  0.000 ms  0/906 (0%)  sender
[  5]   0.00-10.04  sec  1.25 MBytes  1.05 Mbits/sec  1.074 ms  0/906 (0%)  receiver

iperf Done.
    Copy to Clipboard Toggle word wrap

  5. 在 iPerf 服务器上，输出显示每秒间隔的 jitter。平均在末尾显示。对于此测试，您要识别测试过程中遇到的最大 jitter，忽略第一秒的输出，因为它可能包含无效的测量。输入以下命令： 

    # oc debug node/m0
    Copy to Clipboard Toggle word wrap

    输出示例

    Starting pod/m0-debug ...
To use host binaries, run `chroot /host`
Pod IP: 198.18.111.12
If you don't see a command prompt, try pressing enter.
    Copy to Clipboard Toggle word wrap

  6. 输入以下命令： 

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap 
    sh-4.4# podman run -ti --rm --net host <iperf_image> iperf3 -s
    Copy to Clipboard Toggle word wrap

    输出示例

    -----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
Accepted connection from 198.18.111.13, port 44136
[  5] local 198.18.111.12 port 5201 connected to 198.18.111.13 port 60878
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec   124 KBytes  1.02 Mbits/sec  4.763 ms  0/88 (0%)
[  5]   1.00-2.00   sec   127 KBytes  1.04 Mbits/sec  4.735 ms  0/90 (0%)
[  5]   2.00-3.00   sec   129 KBytes  1.05 Mbits/sec  0.568 ms  0/91 (0%)
[  5]   3.00-4.00   sec   127 KBytes  1.04 Mbits/sec  2.443 ms  0/90 (0%)
[  5]   4.00-5.00   sec   129 KBytes  1.05 Mbits/sec  1.372 ms  0/91 (0%)
[  5]   5.00-6.00   sec   127 KBytes  1.04 Mbits/sec  2.769 ms  0/90 (0%)
[  5]   6.00-7.00   sec   129 KBytes  1.05 Mbits/sec  2.393 ms  0/91 (0%)
[  5]   7.00-8.00   sec   127 KBytes  1.04 Mbits/sec  0.883 ms  0/90 (0%)
[  5]   8.00-9.00   sec   129 KBytes  1.05 Mbits/sec  0.594 ms  0/91 (0%)
[  5]   9.00-10.00  sec   127 KBytes  1.04 Mbits/sec  0.953 ms  0/90 (0%)
[  5]  10.00-10.04  sec  5.66 KBytes  1.30 Mbits/sec  1.074 ms  0/4 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.04  sec  1.25 MBytes  1.05 Mbits/sec  1.074 ms  0/906 (0%)  receiver
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
    Copy to Clipboard Toggle word wrap

  7. 将计算的 jitter 添加为网络延迟的损失。例如，如果网络延迟为 80 ms，并且 jitter 为 30 ms，则考虑 control plane 的目的为 110 ms 的有效网络延迟。在本例中，该值超过 100 ms 阈值，系统将丢失 heartbeat。

  8. 当您计算 etcd 的网络延迟时，请使用有效的网络延迟，即以下等于的总和：

    RTT + jitter

    您可以使用平均 jitter 值来计算 penalty，但如果 etcd heartbeat 计时器低于以下原因的总和，集群可能会正常丢失心跳：

    RTT + max(jitter)

    相反，请考虑将 99th percentile 或 max jitter 值用于更具弹性的部署：

    有效的网络延迟 = RTT + max (jitter)

返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

Theme

© 2025 Red Hat