9.2. 优化路由


OpenShift Container Platform HAProxy 路由器可以扩展或配置以优化性能。

9.2.1. Ingress Controller(router)性能的基线

OpenShift Container Platform Ingress Controller 或路由器是使用路由和入口配置的应用程序和服务的入口流量的入站点。

当根据每秒处理的 HTTP 请求来评估单个 HAProxy 路由器性能时,其性能取决于多个因素。特别是:

  • HTTP keep-alive/close 模式
  • 路由类型
  • 对 TLS 会话恢复客户端的支持
  • 每个目标路由的并行连接数
  • 目标路由数
  • 后端服务器页面大小
  • 底层基础结构(网络/SDN 解决方案、CPU 等)

具体环境中的性能会有所不同,红帽实验室在一个有 4 个 vCPU/16GB RAM 的公有云实例中进行测试。一个 HAProxy 路由器处理由后端终止的 100 个路由服务提供 1kB 静态页面,每秒处理以下传输数。

在 HTTP 的 keep-alive 模式下:

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

在 HTTP 关闭(无 keep-alive)情境中:

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

默认 Ingress Controller 配置用于将 spec.tuningOptions.threadCount 字段设置为 4。测试了两个不同的端点发布策略: Load Balancer Service 和 Host Network。TLS 会话恢复用于加密路由。使用 HTTP keep-alive 设置,单个 HAProxy 路由器可在页面大小小到 8 kB 时充满 1 Gbit NIC。

当在使用现代处理器的裸机中运行时,性能可以期望达到以上公有云实例测试性能的大约两倍。这个开销是由公有云的虚拟化层造成的,基于私有云虚拟化的环境也会有类似的开销。下表是有关在路由器后面的应用程序数量的指导信息:

应用程序数量应用程序类型

5-10

静态文件/web 服务器或者缓存代理

100-1000

生成动态内容的应用程序

取决于所使用的技术,HAProxy 通常可支持最多 1000 个程序的路由。Ingress Controller 性能可能会受其后面的应用程序的能力和性能的限制,如使用的语言,静态内容或动态内容。

如果有多个服务于应用程序的 Ingress 或路由器,则应该使用路由器分片(router sharding)以帮助横向扩展路由层。

如需有关 Ingress 分片的更多信息,请参阅 使用路由标签和使用命名空间标签 配置 Ingress Controller 分片

您可以使用为线程 设置 Ingress Controller 线程计数和 Ingress Controller 配置参数(用于超时)以及 Ingress Controller 规格中的其他调优配置来修改 Ingress Controller 部署。

9.2.2. 配置 Ingress Controller 存活度、就绪度和启动探测

集群管理员可为由 OpenShift Container Platform Ingress Controller(路由器)管理的路由器部署配置 kubelet 存活度、就绪度和启动探测的超时值。路由器的存活度和就绪度探测使用默认值 1 秒,这在网络或运行时性能严重降级时太短。探测超时可能会导致中断应用程序连接的路由器重启。设置较大的超时值可以降低不必要的和不需要的重启的风险。

您可以更新路由器容器的 livenessProbereadinessProbestartProbe 参数上的 timeoutSeconds 值。

参数描述

livenessProbe

livenessProbe 会向 kubelet 报告 Pod 是否已死并需要重启。

readinessProbe

readinessProbe 报告容器集是健康还是不健康。当就绪度探测报告不健康的 pod 时,kubelet 会将 pod 标记为不接受流量。然后,该 pod 的端点标记为未就绪,这个状态会应用到 kube-proxy。在配置了负载均衡器的云平台中,kube-proxy 与云负载均衡器通信,不会将流量发送到该 pod 的节点。

startupProbe

startupProbe 为路由器 pod 提供最多 2 分钟的时间,以便 kubelet 开始发送路由器存活度和就绪度探测。这种初始化时间可以防止带有多个路由或端点的路由器会预先重启。

重要

timeout 配置选项是一个高级调优技术,可用于解决问题。但是,最终应该诊断这些问题,并可能为导致探测超时的所有问题打开支持问题单或 JIRA 问题

以下示例演示了如何直接修补默认路由器部署来为存活度和就绪度探测设置 5 秒超时:

$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'

验证

$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
    Liveness:   http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
    Readiness:  http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3

9.2.3. 配置 HAProxy 重新加载间隔

当您更新路由或与路由关联的端点时,OpenShift Container Platform 路由器会更新 HAProxy 的配置。然后,HAProxy 重新加载更新后的配置以使这些更改生效。当 HAProxy 重新加载时,它会生成一个使用更新的配置来处理新连接的新进程。

HAProxy 保持旧进程正在运行,以处理现有连接,直到这些连接都关闭。当旧进程有长期连接时,这些进程可能会累积并消耗资源。

默认最小 HAProxy 重新加载间隔为 5 秒。您可以使用 spec.tuningOptions.reloadInterval 字段配置 Ingress Controller,以设置较长的重新载入间隔。

警告

为最低 HAProxy 重新加载间隔设置较大的值可能会导致观察路由及其端点更新产生延迟。要降低风险,请避免设置值超过更新可容忍的延迟。

流程

  • 运行以下命令,将默认 Ingress Controller 的最小 HAProxy 重新加载间隔改为 15 秒:

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.