路由优化 - 可扩展性和性能优化 | 可扩展性和性能 | OpenShift 容器平台 4.17

基线 Ingress 控制器（路由器）性能
配置 Ingress 控制器存活性、就绪性和启动探针
配置 HAProxy 重新加载间隔

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

基线 Ingress 控制器（路由器）性能

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

在评估单个 HAProxy 路由器的每秒处理的 HTTP 请求数的性能方面，性能会因许多因素而异。特别是

HTTP keep-alive/close 模式
路由类型
TLS 会话恢复客户端支持
每个目标路由的并发连接数
目标路由数
后端服务器页面大小
底层基础架构（网络、CPU 等）

虽然您特定环境中的性能会有所不同，但 Red Hat 实验室在大小为 4 vCPU/16GB RAM 的公共云实例上进行了测试。单个 HAProxy 路由器处理 100 个由后端终止的路由（提供 1kB 静态页面），能够处理每秒以下数量的事务。

在 HTTP keep-alive 模式场景中

加密	LoadBalancerService	HostNetwork
无	21515	29622
边缘	16743	22913
直通	36786	53295
重新加密	21583	25198

在 HTTP close（无 keep-alive）场景中

加密	LoadBalancerService	HostNetwork
无	5719	8273
边缘	2729	4069
直通	4121	5344
重新加密	2320	2941

使用默认的 Ingress 控制器配置，spec.tuningOptions.threadCount 字段设置为 4。测试了两种不同的端点发布策略：负载均衡器服务和主机网络。加密路由使用了 TLS 会话恢复。使用 HTTP keep-alive，单个 HAProxy 路由器能够在页面大小小至 8 kB 时使 1 Gbit NIC 饱和。

在使用现代处理器的裸机上运行时，您可以预期性能大约是上述公共云实例的两倍。此开销是由公共云上的虚拟化层引入的，并且大部分也适用于基于私有云的虚拟化。下表是关于路由器后面应使用多少应用程序的指南

应用程序数量	应用程序类型
5-10	静态文件/Web 服务器或缓存代理
100-1000	生成动态内容的应用程序

应用程序数量

应用程序类型

5-10

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

100-1000

生成动态内容的应用程序

一般来说，HAProxy 可以支持多达 1000 个应用程序的路由，具体取决于所使用的技术。Ingress 控制器的性能可能受到其后端应用程序的功能和性能的限制，例如语言或静态与动态内容。

应使用 Ingress 或路由器分片来为应用程序提供更多路由，并帮助水平扩展路由层。

有关 Ingress 分片的更多信息，请参阅使用路由标签配置 Ingress 控制器分片和使用命名空间标签配置 Ingress 控制器分片。

您可以使用设置 Ingress 控制器线程数（用于线程）和Ingress 控制器配置参数（用于超时和其他 Ingress 控制器规范中的调整配置）中提供的信息修改 Ingress 控制器部署。

配置 Ingress 控制器存活性、就绪性和启动探针

集群管理员可以为由 OpenShift Container Platform Ingress 控制器（路由器）管理的路由器部署配置 kubelet 的存活性、就绪性和启动探针的超时值。路由器的存活性探针和就绪性探针使用默认超时值为 1 秒，当网络或运行时性能严重下降时，这太短了。探针超时可能会导致不需要的路由器重新启动，从而中断应用程序连接。设置更大的超时值可以降低不必要和意外重新启动的风险。

您可以更新路由器容器的livenessProbe、readinessProbe和startupProbe参数中的timeoutSeconds值。

参数描述

参数	描述
`livenessProbe`	`livenessProbe`向kubelet报告Pod是否已失效并需要重启。
`readinessProbe`	`readinessProbe`报告Pod是健康还是不健康。当就绪探针报告Pod不健康时，kubelet会将该Pod标记为不可接受流量。随后，该Pod的端点将被标记为未就绪，此状态将传播到kube-proxy。在配置了负载均衡器的云平台上，kube-proxy会与云负载均衡器通信，指示其不要将流量发送到具有该Pod的节点。
`startupProbe`	`startupProbe`允许路由器Pod最多初始化2分钟，然后kubelet才开始发送路由器的存活性和就绪性探针。此初始化时间可以防止具有许多路由或端点的路由器过早重启。

livenessProbe

livenessProbe向kubelet报告Pod是否已失效并需要重启。

readinessProbe

readinessProbe报告Pod是健康还是不健康。当就绪探针报告Pod不健康时，kubelet会将该Pod标记为不可接受流量。随后，该Pod的端点将被标记为未就绪，此状态将传播到kube-proxy。在配置了负载均衡器的云平台上，kube-proxy会与云负载均衡器通信，指示其不要将流量发送到具有该Pod的节点。

startupProbe

startupProbe允许路由器Pod最多初始化2分钟，然后kubelet才开始发送路由器的存活性和就绪性探针。此初始化时间可以防止具有许多路由或端点的路由器过早重启。

超时配置选项是一种高级调整技术，可用于解决问题。但是，最终应诊断这些问题，并可能针对任何导致探针超时的相关问题提交支持案例或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

配置HAProxy重载间隔

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

HAProxy使旧进程继续运行以处理现有连接，直到所有这些连接都关闭。当旧进程具有长期存在的连接时，这些进程可能会累积并消耗资源。

默认最小HAProxy重载间隔为五秒。您可以使用其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"}}}'