×

Ingress Operator 实现 IngressController API,是启用对 OpenShift 专用集群服务的外部访问的组件。

OpenShift 专用 Ingress 操作符

创建 OpenShift 专用集群时,在集群上运行的 Pod 和服务都会分配自己的 IP 地址。这些 IP 地址可被附近运行的其他 Pod 和服务访问,但外部客户端无法访问。

Ingress Operator 通过部署和管理一个或多个基于 HAProxy 的 Ingress Controller 来处理路由,从而使外部客户端能够访问您的服务。Red Hat 站点可靠性工程师 (SRE) 管理 OpenShift 专用集群的 Ingress Operator。虽然您无法更改 Ingress Operator 的设置,但您可以查看默认 Ingress Controller 的配置、状态和日志,以及 Ingress Operator 的状态。

Ingress 配置资源

安装程序生成一个包含 config.openshift.io API 组中 Ingress 资源的资源文件 cluster-ingress-02-config.yml

Ingress 资源的 YAML 定义
apiVersion: config.openshift.io/v1
kind: Ingress
metadata:
  name: cluster
spec:
  domain: apps.openshiftdemos.com

安装程序将此资源文件存储在 manifests/ 目录中的 cluster-ingress-02-config.yml 文件中。此 Ingress 资源定义了集群范围的 Ingress 配置。此 Ingress 配置的使用方式如下:

  • Ingress Operator 使用集群 Ingress 配置中的域名作为默认 Ingress Controller 的域名。

  • OpenShift API Server 操作符使用集群 Ingress 配置中的域名。此域名也用于为未指定显式主机的 Route 资源生成默认主机。

Ingress Controller 配置参数

IngressController 自定义资源 (CR) 包含可选的配置参数,您可以配置这些参数以满足组织的特定需求。

参数 描述

domain

domain 是 Ingress Controller 提供服务的 DNS 名称,用于配置多个功能。

  • 对于 LoadBalancerService 端点发布策略,domain 用于配置 DNS 记录。请参阅 endpointPublishingStrategy

  • 使用生成的默认证书时,证书对domain及其subdomains有效。请参见defaultCertificate

  • 该值发布到各个路由状态,以便用户知道在哪里定位外部 DNS 记录。

domain值在所有 Ingress Controller 中必须唯一,并且无法更新。

如果为空,则默认值为ingress.config.openshift.io/cluster .spec.domain

副本数 (replicas)

replicas 是 Ingress Controller 副本的数量。如果未设置,则默认值为 2

端点发布策略 (endpointPublishingStrategy)

endpointPublishingStrategy 用于将 Ingress Controller 端点发布到其他网络,启用负载均衡器集成,并提供对其他系统的访问。

对于云环境,请使用loadBalancer字段配置 Ingress Controller 的端点发布策略。

您可以配置以下endpointPublishingStrategy字段

  • loadBalancer.scope

  • loadBalancer.allowedSourceRanges

如果未设置,则默认值基于infrastructure.config.openshift.io/cluster .status.platform

  • Amazon Web Services (AWS):LoadBalancerService(具有外部范围)

  • Google Cloud Platform (GCP):LoadBalancerService(具有外部范围)

对于大多数平台,可以更新endpointPublishingStrategy值。在 GCP 上,您可以配置以下endpointPublishingStrategy字段

  • loadBalancer.scope

  • loadbalancer.providerParameters.gcp.clientAccess

如果需要在集群部署后更新endpointPublishingStrategy值,您可以配置以下endpointPublishingStrategy字段

  • hostNetwork.protocol

  • nodePort.protocol

  • private.protocol

默认证书 (defaultCertificate)

defaultCertificate值是对包含 Ingress Controller 提供的默认证书的密钥的引用。当路由未指定自己的证书时,将使用defaultCertificate

密钥必须包含以下键和数据:* tls.crt:证书文件内容 * tls.key:密钥文件内容

如果未设置,则会自动生成并使用通配符证书。证书对 Ingress Controller 的domainsubdomains有效,并且生成的证书的 CA 会自动与集群的信任存储集成。

正在使用的证书(无论是生成的还是用户指定的)都会自动与 OpenShift Dedicated 内置 OAuth 服务器集成。

命名空间选择器 (namespaceSelector)

namespaceSelector用于过滤 Ingress Controller 服务的命名空间集。这对于实现分片很有用。

路由选择器 (routeSelector)

routeSelector用于过滤 Ingress Controller 服务的路由集。这对于实现分片很有用。

节点部署 (nodePlacement)

nodePlacement允许对 Ingress Controller 的调度进行显式控制。

如果未设置,则使用默认值。

nodePlacement参数包括两部分,nodeSelectortolerations。例如

nodePlacement:
 nodeSelector:
   matchLabels:
     kubernetes.io/os: linux
 tolerations:
 - effect: NoSchedule
   operator: Exists

TLS 安全配置文件 (tlsSecurityProfile)

tlsSecurityProfile指定 Ingress Controller 的 TLS 连接设置。

如果未设置,则默认值基于apiservers.config.openshift.io/cluster资源。

使用OldIntermediateModern配置文件类型时,有效的配置文件配置在发行版之间可能会发生变化。例如,给定一个在X.Y.Z版本上部署的Intermediate配置文件规范,升级到X.Y.Z+1版本可能会导致新的配置文件配置应用于 Ingress Controller,从而导致重新部署。

Ingress Controller 的最小 TLS 版本为1.1,最大 TLS 版本为1.3

配置的安全配置文件的密码和最小 TLS 版本反映在TLSProfile状态中。

Ingress Operator 将OldCustom配置文件的 TLS 1.0转换为1.1

客户端 TLS (clientTLS)

clientTLS验证客户端对集群和服务的访问;因此,启用了双向 TLS 身份验证。如果未设置,则不会启用客户端 TLS。

clientTLS具有必需的子字段spec.clientTLS.clientCertificatePolicyspec.clientTLS.ClientCA

ClientCertificatePolicy子字段接受两个值之一:RequiredOptionalClientCA子字段指定位于 openshift-config 命名空间中的配置映射。配置映射应包含 CA 证书包。

AllowedSubjectPatterns是一个可选值,它指定正则表达式的列表,这些正则表达式与有效客户端证书上的可分辨名称匹配以过滤请求。正则表达式必须使用 PCRE 语法。至少一个模式必须与客户端证书的可分辨名称匹配;否则,Ingress Controller 将拒绝证书并拒绝连接。如果未指定,Ingress Controller 不会根据可分辨名称拒绝证书。

路由准入 (routeAdmission)

routeAdmission定义了处理新路由声明的策略,例如允许或拒绝跨命名空间的声明。

namespaceOwnership描述了如何在命名空间之间处理主机名声明。默认为Strict

  • Strict:不允许路由跨命名空间声明相同的主机名。

  • InterNamespaceAllowed:允许路由跨命名空间声明相同主机名的不同路径。

wildcardPolicy描述了 Ingress Controller 如何处理具有通配符策略的路由。

  • WildcardsAllowed:表示 Ingress Controller 允许具有任何通配符策略的路由。

  • WildcardsDisallowed:表示 Ingress Controller 只允许具有None通配符策略的路由。将wildcardPolicyWildcardsAllowed更新为WildcardsDisallowed会导致具有Subdomain通配符策略的已允许路由停止工作。必须将这些路由重新创建为None通配符策略才能被 Ingress Controller 重新接纳。WildcardsDisallowed是默认设置。

IngressController 日志记录 (IngressControllerLogging)

logging定义了在哪里记录什么的参数。如果此字段为空,则启用操作日志但禁用访问日志。

  • access描述了如何记录客户端请求。如果此字段为空,则禁用访问日志记录。

    • destination描述日志消息的目标。

      • type是日志目标的类型

        • Container指定日志应写入 sidecar 容器。Ingress Operator 在 Ingress Controller pod 上配置名为**logs**的容器,并配置 Ingress Controller 将日志写入该容器。预期管理员配置一个自定义日志记录解决方案,该解决方案从该容器读取日志。使用容器日志意味着如果日志速率超过容器运行时容量或自定义日志记录解决方案容量,则日志可能会丢失。

        • Syslog指定将日志发送到 Syslog 端点。管理员必须指定可以接收 Syslog 消息的端点。预期管理员已配置自定义 Syslog 实例。

      • container 描述 Container 日志目标类型的参数。目前容器日志没有参数,因此此字段必须为空。

      • syslog 描述 Syslog 日志目标类型的参数。

        • address 是接收日志消息的 syslog 端点的 IP 地址。

        • port 是接收日志消息的 syslog 端点的 UDP 端口号。

        • maxLength 是 syslog 消息的最大长度。它必须在 4804096 字节之间。如果此字段为空,则最大长度设置为默认值 1024 字节。

        • facility 指定日志消息的 syslog 设备。如果此字段为空,则设备为 local1。否则,它必须指定一个有效的 syslog 设备:kernusermaildaemonauthsysloglprnewsuucpcronauth2ftpntpauditalertcron2local0local1local2local3local4local5local6local7

    • httpLogFormat 指定 HTTP 请求日志消息的格式。如果此字段为空,日志消息将使用实现的默认 HTTP 日志格式。有关 HAProxy 的默认 HTTP 日志格式,请参见 HAProxy 文档

httpHeaders

httpHeaders 定义 HTTP 头的策略。

通过设置 IngressControllerHTTPHeadersforwardedHeaderPolicy,您可以指定 Ingress Controller 何时以及如何设置 ForwardedX-Forwarded-ForX-Forwarded-HostX-Forwarded-PortX-Forwarded-ProtoX-Forwarded-Proto-Version HTTP 头。

默认情况下,策略设置为 Append

  • Append 指定 Ingress Controller 附加头,保留任何现有头。

  • Replace 指定 Ingress Controller 设置头,删除任何现有头。

  • IfNone 指定 Ingress Controller 如果头尚未设置则设置头。

  • Never 指定 Ingress Controller 从不设置头,保留任何现有头。

通过设置 headerNameCaseAdjustments,您可以指定可以应用于 HTTP 头名称的大小写调整。每个调整都指定为具有所需大小写的 HTTP 头名称。例如,指定 X-Forwarded-For 表示应调整 x-forwarded-for HTTP 头以具有指定的大小写。

这些调整仅应用于明文、边缘终止和重新加密路由,并且仅在使用 HTTP/1 时应用。

对于请求头,这些调整仅应用于具有 haproxy.router.openshift.io/h1-adjust-case=true 注解的路由。对于响应头,这些调整应用于所有 HTTP 响应。如果此字段为空,则不会调整任何请求头。

actions 指定对头执行某些操作的选项。不能为 TLS 直通连接设置或删除头。actions 字段具有附加子字段 spec.httpHeader.actions.responsespec.httpHeader.actions.request

  • response 子字段指定要设置或删除的 HTTP 响应头的列表。

  • request 子字段指定要设置或删除的 HTTP 请求头的列表。

httpCompression

httpCompression 定义 HTTP 流量压缩的策略。

  • mimeTypes 定义应应用压缩的 MIME 类型列表。例如,text/css; charset=utf-8text/htmltext/*image/svg+xmlapplication/octet-streamX-custom/customsub,使用格式模式 type/subtype; [;attribute=value]types 为:application、image、message、multipart、text、video 或以 X- 开头的自定义类型;例如,要查看 MIME 类型和子类型的完整表示法,请参见 RFC1341

httpErrorCodePages

httpErrorCodePages 指定自定义 HTTP 错误代码响应页面。默认情况下,IngressController 使用内置于 IngressController 镜像中的错误页面。

httpCaptureCookies

httpCaptureCookies 指定要在访问日志中捕获的 HTTP Cookie。如果 httpCaptureCookies 字段为空,则访问日志不会捕获 Cookie。

对于要捕获的任何 Cookie,以下参数必须位于您的 IngressController 配置中

  • name 指定 Cookie 的名称。

  • maxLength 指定 Cookie 的最大长度。

  • matchType 指定 Cookie 的 name 字段是否完全匹配捕获 Cookie 设置或是否是捕获 Cookie 设置的前缀。matchType 字段使用 ExactPrefix 参数。

例如

  httpCaptureCookies:
  - matchType: Exact
    maxLength: 128
    name: MYCOOKIE

httpCaptureHeaders

httpCaptureHeaders 指定要在访问日志中捕获的 HTTP 头。如果 httpCaptureHeaders 字段为空,则访问日志不会捕获头。

httpCaptureHeaders 包含要在访问日志中捕获的两个头列表。两个头字段列表为 requestresponse。在这两个列表中,name 字段必须指定头名称,maxlength 字段必须指定头的最大长度。例如

  httpCaptureHeaders:
    request:
    - maxLength: 256
      name: Connection
    - maxLength: 128
      name: User-Agent
    response:
    - maxLength: 256
      name: Content-Type
    - maxLength: 256
      name: Content-Length

tuningOptions

tuningOptions 指定用于调整 Ingress Controller Pod 性能的选项。

  • clientFinTimeout 指定在等待客户端响应服务器关闭连接时保持连接打开的时间长度。默认超时时间为 1s

  • clientTimeout 指定在等待客户端响应时保持连接打开的时间长度。默认超时时间为 30s

  • headerBufferBytes 指定为 Ingress Controller 连接会话保留的内存量(以字节为单位)。如果为 Ingress Controller 启用了 HTTP/2,则此值必须至少为 16384。如果未设置,则默认值为 32768 字节。不建议设置此字段,因为 headerBufferBytes 值太小可能会破坏 Ingress Controller,而 headerBufferBytes 值太大可能会导致 Ingress Controller 使用的内存比必要的内存多得多。

  • headerBufferMaxRewriteBytes 指定应从 headerBufferBytes 中为 Ingress Controller 连接会话的 HTTP 头重写和追加保留多少内存(以字节为单位)。headerBufferMaxRewriteBytes 的最小值为 4096。对于传入的 HTTP 请求,headerBufferBytes 必须大于 headerBufferMaxRewriteBytes。如果未设置,则默认值为 8192 字节。不建议设置此字段,因为 headerBufferMaxRewriteBytes 值太小可能会破坏 Ingress Controller,而 headerBufferMaxRewriteBytes 值太大可能会导致 Ingress Controller 使用的内存比必要的内存多得多。

  • healthCheckInterval 指定路由器在健康检查之间等待的时间长度。默认值为 5s

  • serverFinTimeout 指定在等待服务器响应正在关闭连接的客户端时保持连接打开的时间长度。默认超时时间为 1s

  • serverTimeout 指定在等待服务器响应时保持连接打开的时间长度。默认超时时间为 30s

  • threadCount 指定每个 HAProxy 进程创建的线程数。创建更多线程允许每个 Ingress Controller Pod 处理更多连接,但代价是会消耗更多系统资源。HAProxy 支持最多 64 个线程。如果此字段为空,则 Ingress Controller 使用默认值 4 个线程。默认值在将来的版本中可能会更改。不建议设置此字段,因为增加 HAProxy 线程数允许 Ingress Controller Pod 在负载下使用更多 CPU 时间,并阻止其他 Pod 获得执行所需 的 CPU 资源。减少线程数可能会导致 Ingress Controller 性能下降。

  • tlsInspectDelay 指定路由器为了找到匹配路由可以保持数据的时长。将此值设置得太短会导致路由器回退到边缘终止、重新加密或直通路由的默认证书,即使使用更匹配的证书也是如此。默认检查延迟为 5s

  • tunnelTimeout 指定隧道连接(包括 WebSockets)在空闲时保持打开的时间长度。默认超时时间为 1h

  • maxConnections 指定每个 HAProxy 进程可以建立的最大同时连接数。增加此值允许每个 Ingress Controller Pod 处理更多连接,但代价是会消耗更多系统资源。允许的值为 0-120002000000 之间的任何值,或者可以留空此字段。

    • 如果此字段为空或值为 0,则 Ingress Controller 将使用默认值 50000。此值在将来的版本中可能会更改。

    • 如果字段值为 -1,则 HAProxy 将根据运行容器中可用的 ulimits 动态计算最大值。此过程会计算出一个很大的值,与当前默认值 50000 相比,会占用大量的内存。

    • 如果字段值大于当前操作系统的限制,则 HAProxy 进程将无法启动。

    • 如果您选择一个离散值,并且路由器 Pod 迁移到新的节点,则新的节点可能没有配置相同的 ulimit。在这种情况下,Pod 将无法启动。

    • 如果您配置了不同 ulimits 的节点,并且选择了一个离散值,建议将此字段的值设置为 -1,以便在运行时计算最大连接数。

logEmptyRequests

logEmptyRequests 指定未收到请求且未记录的连接。这些空请求来自负载均衡器健康探测或 Web 浏览器推测性连接(预连接),记录这些请求可能是不希望的。但是,这些请求可能是由网络错误引起的,在这种情况下,记录空请求对于诊断错误可能很有用。这些请求可能是由端口扫描引起的,记录空请求可以帮助检测入侵尝试。此字段允许的值为 LogIgnore。默认值为 Log

LoggingPolicy 类型接受两个值中的一个

  • Log:将此值设置为 Log 表示应记录事件。

  • Ignore:将此值设置为 Ignore 会在 HAproxy 配置中设置 dontlognull 选项。

HTTPEmptyRequestsPolicy

HTTPEmptyRequestsPolicy 描述如果连接在收到请求之前超时,如何处理 HTTP 连接。此字段允许的值为 RespondIgnore。默认值为 Respond

HTTPEmptyRequestsPolicy 类型接受两个值中的一个

  • Respond:如果字段设置为 Respond,则 Ingress Controller 将发送 HTTP 400408 响应,如果启用了访问日志记录,则记录连接,并在相应的指标中计数连接。

  • Ignore:将此选项设置为 Ignore 会在 HAproxy 配置中添加 http-ignore-probes 参数。如果字段设置为 Ignore,则 Ingress Controller 将关闭连接而不发送响应,然后记录连接或增加指标。

这些连接来自负载均衡器健康探测或 Web 浏览器推测性连接(预连接),可以安全地忽略。但是,这些请求可能是由网络错误引起的,因此将此字段设置为 Ignore 可能会妨碍问题的检测和诊断。这些请求可能是由端口扫描引起的,在这种情况下,记录空请求可以帮助检测入侵尝试。

Ingress Controller TLS 安全配置文件

TLS 安全配置文件为服务器提供了一种方法,可以用来规范连接客户端在连接到服务器时可以使用哪些密码。

了解 TLS 安全配置文件

您可以使用 TLS(传输层安全)安全配置文件来定义各种 OpenShift Dedicated 组件所需的 TLS 密码。OpenShift Dedicated TLS 安全配置文件基于 Mozilla 推荐的配置

您可以为每个组件指定以下 TLS 安全配置文件之一

表 1. TLS 安全配置文件
配置文件 描述

旧版 (Old)

此配置文件适用于旧版客户端或库。该配置文件基于 旧版向后兼容性 推荐的配置。

Old 配置文件要求最低 TLS 版本为 1.0。

对于 Ingress Controller,最低 TLS 版本从 1.0 转换为 1.1。

中间版 (Intermediate)

此配置文件是大多数客户端的推荐配置。它是 Ingress Controller、kubelet 和控制平面的默认 TLS 安全配置文件。该配置文件基于 中间版兼容性 推荐的配置。

Intermediate 配置文件要求最低 TLS 版本为 1.2。

现代版 (Modern)

此配置文件适用于不需要向后兼容性的现代客户端。该配置文件基于 现代兼容性 推荐的配置。

Modern 配置文件要求最低 TLS 版本为 1.3。

自定义 (Custom)

此配置文件允许您定义要使用的 TLS 版本和密码。

使用 Custom 配置文件时请谨慎,因为无效的配置可能会导致问题。

使用预定义的配置文件类型时,有效的配置文件配置可能会在版本之间发生更改。例如,给定在 X.Y.Z 版本上部署的要使用中间版配置文件的规范,升级到 X.Y.Z+1 版本可能会导致应用新的配置文件配置,从而导致重新部署。

配置 Ingress Controller 的 TLS 安全配置文件

要为 Ingress 控制器配置 TLS 安全配置文件,请编辑IngressController自定义资源 (CR) 以指定预定义或自定义 TLS 安全配置文件。如果未配置 TLS 安全配置文件,则默认值基于为 API 服务器设置的 TLS 安全配置文件。

配置Old TLS 安全配置文件的IngressController CR 示例
apiVersion: operator.openshift.io/v1
kind: IngressController
 ...
spec:
  tlsSecurityProfile:
    old: {}
    type: Old
 ...

TLS 安全配置文件定义 Ingress 控制器的 TLS 连接的最低 TLS 版本和 TLS 密码。

您可以在IngressController自定义资源 (CR) 的Status.Tls Profile下查看已配置的 TLS 安全配置文件的密码和最低 TLS 版本,并在Spec.Tls Security Profile下查看已配置的 TLS 安全配置文件。对于Custom TLS 安全配置文件,特定密码和最低 TLS 版本都列在两个参数下。

HAProxy Ingress 控制器镜像支持 TLS 1.3Modern 配置文件。

Ingress 运算符还会将OldCustom配置文件的 TLS 1.0 转换为1.1

先决条件
  • 您具有作为具有cluster-admin角色的用户访问集群的权限。

步骤
  1. 编辑openshift-ingress-operator项目中的IngressController CR 以配置 TLS 安全配置文件

    $ oc edit IngressController default -n openshift-ingress-operator
  2. 添加spec.tlsSecurityProfile字段

    Custom配置文件的IngressController CR 示例
    apiVersion: operator.openshift.io/v1
    kind: IngressController
     ...
    spec:
      tlsSecurityProfile:
        type: Custom (1)
        custom: (2)
          ciphers: (3)
          - ECDHE-ECDSA-CHACHA20-POLY1305
          - ECDHE-RSA-CHACHA20-POLY1305
          - ECDHE-RSA-AES128-GCM-SHA256
          - ECDHE-ECDSA-AES128-GCM-SHA256
          minTLSVersion: VersionTLS11
     ...
    1 指定 TLS 安全配置文件类型 (OldIntermediateCustom)。默认为Intermediate
    2 为所选类型指定相应的字段
    • old: {}

    • intermediate: {}

    • custom

    3 对于custom类型,请指定 TLS 密码列表和最低可接受的 TLS 版本。
  3. 保存文件以应用更改。

验证
  • 验证配置文件是否已在IngressController CR 中设置

    $ oc describe IngressController default -n openshift-ingress-operator
    示例输出
    Name:         default
    Namespace:    openshift-ingress-operator
    Labels:       <none>
    Annotations:  <none>
    API Version:  operator.openshift.io/v1
    Kind:         IngressController
     ...
    Spec:
     ...
      Tls Security Profile:
        Custom:
          Ciphers:
            ECDHE-ECDSA-CHACHA20-POLY1305
            ECDHE-RSA-CHACHA20-POLY1305
            ECDHE-RSA-AES128-GCM-SHA256
            ECDHE-ECDSA-AES128-GCM-SHA256
          Min TLS Version:  VersionTLS11
        Type:               Custom
     ...

配置双向 TLS 身份验证

您可以通过设置spec.clientTLS值来配置 Ingress 控制器以启用双向 TLS (mTLS) 身份验证。clientTLS值将 Ingress 控制器配置为验证客户端证书。此配置包括设置clientCA值,这是一个对配置映射的引用。配置映射包含用于验证客户端证书的 PEM 编码的 CA 证书捆绑包。此外,您还可以选择配置证书主题筛选器列表。

如果clientCA值指定 X509v3 证书吊销列表 (CRL) 分发点,则 Ingress 运算符将根据每个提供的证书中指定的 HTTP URI X509v3 CRL Distribution Point下载并管理 CRL 配置映射。Ingress 控制器在 mTLS/TLS 协商期间使用此配置映射。不提供有效证书的请求将被拒绝。

先决条件
  • 您具有作为具有cluster-admin角色的用户访问集群的权限。

  • 您拥有 PEM 编码的 CA 证书捆绑包。

  • 如果您的 CA 捆绑包引用 CRL 分发点,则您还必须将最终实体或叶证书包含到客户端 CA 捆绑包中。此证书必须在CRL Distribution Points下包含 HTTP URI,如 RFC 5280 中所述。例如

     Issuer: C=US, O=Example Inc, CN=Example Global G2 TLS RSA SHA256 2020 CA1
             Subject: SOME SIGNED CERT            X509v3 CRL Distribution Points:
                    Full Name:
                      URI:http://crl.example.com/example.crl
步骤
  1. openshift-config命名空间中,从您的 CA 捆绑包创建配置映射

    $ oc create configmap \
       router-ca-certs-default \
       --from-file=ca-bundle.pem=client-ca.crt \(1)
       -n openshift-config
    1 配置映射数据键必须为ca-bundle.pem,数据值必须为 PEM 格式的 CA 证书。
  2. 编辑openshift-ingress-operator项目中的IngressController资源

    $ oc edit IngressController default -n openshift-ingress-operator
  3. 添加spec.clientTLS字段和子字段以配置双向 TLS

    指定筛选模式的clientTLS配置文件的IngressController CR 示例
      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        clientTLS:
          clientCertificatePolicy: Required
          clientCA:
            name: router-ca-certs-default
          allowedSubjectPatterns:
          - "^/CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift$"
  4. 可选,通过输入以下命令获取allowedSubjectPatterns的区分名称 (DN)。

$ openssl  x509 -in custom-cert.pem  -noout -subject
subject= /CN=example.com/ST=NC/C=US/O=Security/OU=OpenShift

查看默认 Ingress 控制器

Ingress 运算符是 OpenShift Dedicated 的核心功能,并且开箱即用。

每个新的 OpenShift Dedicated 安装都具有名为 default 的ingresscontroller。可以使用其他 Ingress 控制器对其进行补充。如果删除默认ingresscontroller,Ingress 运算符将在 1 分钟内自动重新创建它。

步骤
  • 查看默认 Ingress Controller

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/default

查看 Ingress 运算符状态

您可以查看和检查 Ingress 运算符的状态。

步骤
  • 查看您的 Ingress 运算符状态

    $ oc describe clusteroperators/ingress

查看 Ingress 控制器日志

您可以查看您的 Ingress 控制器日志。

步骤
  • 查看您的 Ingress 控制器日志

    $ oc logs --namespace=openshift-ingress-operator deployments/ingress-operator -c <container_name>

查看 Ingress 控制器状态

您可以查看特定 Ingress 控制器的状态。

步骤
  • 查看 Ingress 控制器的状态

    $ oc describe --namespace=openshift-ingress-operator ingresscontroller/<name>

创建自定义 Ingress 控制器

作为集群管理员,您可以创建新的自定义 Ingress 控制器。由于默认 Ingress 控制器可能会在 OpenShift Dedicated 更新期间发生更改,因此在维护跨集群更新持续存在的配置时,创建自定义 Ingress 控制器会很有帮助。

此示例提供了自定义 Ingress 控制器的最小规范。要进一步自定义您的自定义 Ingress 控制器,请参阅“配置 Ingress 控制器”。

先决条件
  • 安装 OpenShift CLI (oc)。

  • 以具有cluster-admin权限的用户身份登录。

步骤
  1. 创建一个定义自定义IngressController对象的 YAML 文件

    custom-ingress-controller.yaml文件示例
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
        name: <custom_name> (1)
        namespace: openshift-ingress-operator
    spec:
        defaultCertificate:
            name: <custom-ingress-custom-certs> (2)
        replicas: 1 (3)
        domain: <custom_domain> (4)
    1 IngressController对象指定自定义name
    2 指定包含自定义通配符证书的密钥的名称。
    3 最小副本数必须为 1。
    4 将域指定为您的域名。IngressController 对象上指定的域和用于证书的域必须匹配。例如,如果域值为“custom_domain.mycompany.com”,则证书必须具有 SAN *.custom_domain.mycompany.com(在域中添加了*.)。
  2. 通过运行以下命令创建对象

    $ oc create -f custom-ingress-controller.yaml

配置 Ingress 控制器

设置自定义默认证书

作为管理员,您可以通过创建 Secret 资源和编辑IngressController自定义资源 (CR) 来配置 Ingress 控制器以使用自定义证书。

先决条件
  • 您必须拥有 PEM 编码文件中的一对证书/密钥,其中证书由受信任的证书颁发机构或您在自定义 PKI 中配置的私有受信任证书颁发机构签名。

  • 您的证书满足以下要求

    • 证书对于入口域有效。

    • 证书使用subjectAltName扩展名来指定通配符域,例如*.apps.ocp4.example.com

  • 您必须拥有IngressController CR。您可以使用默认的。

    $ oc --namespace openshift-ingress-operator get ingresscontrollers
    示例输出
    NAME      AGE
    default   10m

如果您有中间证书,则必须将其包含在包含自定义默认证书的密钥的tls.crt文件中。指定证书时顺序很重要;将您的中间证书列在任何服务器证书之后。

步骤

以下内容假设自定义证书和密钥对位于当前工作目录下的tls.crttls.key文件中。请将tls.crttls.key替换为实际路径名。在创建Secret资源和在IngressController CR中引用它时,您也可以使用其他名称替换custom-certs-default

此操作将导致Ingress Controller使用滚动部署策略重新部署。

  1. 使用tls.crttls.key文件,在openshift-ingress命名空间中创建一个包含自定义证书的Secret资源。

    $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
  2. 更新IngressController CR以引用新的证书密钥。

    $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
      --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'
  3. 验证更新是否有效。

    $ echo Q |\
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
      openssl x509 -noout -subject -issuer -enddate

    其中

    <domain>

    指定集群的基本域名。

    示例输出
    subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
    issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
    notAfter=May 10 08:32:45 2022 GM

    您可以选择应用以下YAML来设置自定义默认证书。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      defaultCertificate:
        name: custom-certs-default

    证书密钥名称应与用于更新CR的值匹配。

修改IngressController CR后,Ingress Operator会更新Ingress Controller的部署以使用自定义证书。

移除自定义默认证书

作为管理员,您可以移除您已配置Ingress Controller使用的自定义证书。

先决条件
  • 您具有作为具有cluster-admin角色的用户访问集群的权限。

  • 您已安装OpenShift CLI (oc)。

  • 您之前已为Ingress Controller配置了自定义默认证书。

步骤
  • 要移除自定义证书并恢复OpenShift Dedicated附带的证书,请输入以下命令:

    $ oc patch -n openshift-ingress-operator ingresscontrollers/default \
      --type json -p $'- op: remove\n  path: /spec/defaultCertificate'

    集群协调新的证书配置可能需要一些时间。

验证
  • 要确认已恢复原始集群证书,请输入以下命令:

    $ echo Q | \
      openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null | \
      openssl x509 -noout -subject -issuer -enddate

    其中

    <domain>

    指定集群的基本域名。

    示例输出
    subject=CN = *.apps.<domain>
    issuer=CN = ingress-operator@1620633373
    notAfter=May 10 10:44:36 2023 GMT

Ingress Controller自动缩放

您可以自动缩放Ingress Controller以动态满足路由性能或可用性要求,例如提高吞吐量的要求。

以下步骤提供了一个用于扩展默认Ingress Controller的示例。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您可以作为具有cluster-admin角色的用户访问OpenShift Dedicated集群。

  • 您已安装自定义指标自动缩放器Operator和相关的KEDA Controller。

    • 您可以使用Web控制台上的OperatorHub安装Operator。安装Operator后,您可以创建一个KedaController实例。

步骤
  1. 通过运行以下命令创建一个服务帐户以对Thanos进行身份验证:

    $ oc create -n openshift-ingress-operator serviceaccount thanos && oc describe -n openshift-ingress-operator serviceaccount thanos
    示例输出
    Name:                thanos
    Namespace:           openshift-ingress-operator
    Labels:              <none>
    Annotations:         <none>
    Image pull secrets:  thanos-dockercfg-kfvf2
    Mountable secrets:   thanos-dockercfg-kfvf2
    Tokens:              <none>
    Events:              <none>
  2. 使用以下命令手动创建服务帐户密钥令牌:

    $ oc apply -f - <<EOF
    apiVersion: v1
    kind: Secret
    metadata:
      name: thanos-token
      namespace: openshift-ingress-operator
      annotations:
        kubernetes.io/service-account.name: thanos
    type: kubernetes.io/service-account-token
    EOF
  3. 使用服务帐户的令牌在openshift-ingress-operator命名空间中定义一个TriggerAuthentication对象。

    1. 创建TriggerAuthentication对象并将secret变量的值传递给TOKEN参数。

      $ oc apply -f - <<EOF
      apiVersion: keda.sh/v1alpha1
      kind: TriggerAuthentication
      metadata:
        name: keda-trigger-auth-prometheus
        namespace: openshift-ingress-operator
      spec:
        secretTargetRef:
        - parameter: bearerToken
          name: thanos-token
          key: token
        - parameter: ca
          name: thanos-token
          key: ca.crt
      EOF
  4. 创建一个用于从Thanos读取指标的角色。

    1. 创建一个新的角色thanos-metrics-reader.yaml,该角色可从Pod和节点读取指标。

      thanos-metrics-reader.yaml
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
        name: thanos-metrics-reader
        namespace: openshift-ingress-operator
      rules:
      - apiGroups:
        - ""
        resources:
        - pods
        - nodes
        verbs:
        - get
      - apiGroups:
        - metrics.k8s.io
        resources:
        - pods
        - nodes
        verbs:
        - get
        - list
        - watch
      - apiGroups:
        - ""
        resources:
        - namespaces
        verbs:
        - get
    2. 通过运行以下命令应用新角色:

      $ oc apply -f thanos-metrics-reader.yaml
  5. 通过输入以下命令将新角色添加到服务帐户:

    $ oc adm policy -n openshift-ingress-operator add-role-to-user thanos-metrics-reader -z thanos --role-namespace=openshift-ingress-operator
    $ oc adm policy -n openshift-ingress-operator add-cluster-role-to-user cluster-monitoring-view -z thanos

    仅当您使用跨命名空间查询时才需要参数add-cluster-role-to-user。以下步骤使用来自kube-metrics命名空间的查询,这需要此参数。

  6. 创建一个新的ScaledObject YAML文件ingress-autoscaler.yaml,该文件以默认Ingress Controller部署为目标。

    ScaledObject定义示例:
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    metadata:
      name: ingress-scaler
      namespace: openshift-ingress-operator
    spec:
      scaleTargetRef: (1)
        apiVersion: operator.openshift.io/v1
        kind: IngressController
        name: default
        envSourceContainerName: ingress-operator
      minReplicaCount: 1
      maxReplicaCount: 20 (2)
      cooldownPeriod: 1
      pollingInterval: 1
      triggers:
      - type: prometheus
        metricType: AverageValue
        metadata:
          serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091 (3)
          namespace: openshift-ingress-operator (4)
          metricName: 'kube-node-role'
          threshold: '1'
          query: 'sum(kube_node_role{role="worker",service="kube-state-metrics"})' (5)
          authModes: "bearer"
        authenticationRef:
          name: keda-trigger-auth-prometheus
    1 您要定位的自定义资源。在本例中为Ingress Controller。
    2 可选:最大副本数。如果您省略此字段,则默认最大值为100个副本。
    3 openshift-monitoring命名空间中的Thanos服务端点。
    4 Ingress Operator命名空间。
    5 此表达式计算部署集群中存在的worker节点数量。

    如果您使用跨命名空间查询,则必须在serverAddress字段中定位端口9091而不是端口9092。您还必须具有读取此端口指标的提升权限。

  7. 通过运行以下命令应用自定义资源定义:

    $ oc apply -f ingress-autoscaler.yaml
验证
  • 通过运行以下命令验证默认Ingress Controller是否已扩展到与kube-state-metrics查询返回的值匹配:

    • 使用grep命令搜索Ingress Controller YAML文件中的副本。

      $ oc get -n openshift-ingress-operator ingresscontroller/default -o yaml | grep replicas:
      示例输出
        replicas: 3
    • 获取openshift-ingress项目中的Pod。

      $ oc get pods -n openshift-ingress
      示例输出
      NAME                             READY   STATUS    RESTARTS   AGE
      router-default-7b5df44ff-l9pmm   2/2     Running   0          17h
      router-default-7b5df44ff-s5sl5   2/2     Running   0          3d22h
      router-default-7b5df44ff-wwsth   2/2     Running   0          66s

缩放Ingress Controller

手动缩放Ingress Controller以满足路由性能或可用性要求,例如提高吞吐量的要求。使用oc命令缩放IngressController资源。以下步骤提供了一个用于扩展默认IngressController的示例。

缩放不是立即操作,因为它需要时间来创建所需数量的副本。

步骤
  1. 查看默认IngressController当前可用的副本数量:

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    示例输出
    2
  2. 使用oc patch命令将默认IngressController缩放至所需的副本数量。以下示例将默认IngressController缩放至3个副本:

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge
    示例输出
    ingresscontroller.operator.openshift.io/default patched
  3. 验证默认IngressController是否已缩放至您指定的副本数量。

    $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'
    示例输出
    3

    您可以选择应用以下YAML将Ingress Controller缩放至三个副本:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 3               (1)
    1 如果需要不同数量的副本,请更改replicas值。

配置Ingress访问日志

您可以配置Ingress Controller以启用访问日志。如果您的集群流量不大,则可以将日志记录到sidecar容器。如果您的集群流量很大,为了避免超过日志记录堆栈的容量或与OpenShift Dedicated之外的日志记录基础设施集成,您可以将日志转发到自定义syslog端点。您还可以指定访问日志的格式。

容器日志记录对于在低流量集群上启用访问日志很有用,此时没有现有的Syslog日志记录基础设施,或者在诊断Ingress Controller问题期间短期使用。

对于高流量集群,访问日志可能会超过OpenShift Logging堆栈的容量,或者对于任何日志记录解决方案都需要与现有的Syslog日志记录基础设施集成的环境,需要使用Syslog。Syslog的使用案例可能会有重叠。

先决条件
  • 以具有cluster-admin权限的用户身份登录。

步骤

将Ingress访问日志配置到sidecar容器。

  • 要配置Ingress访问日志,必须使用spec.logging.access.destination指定目标。要指定将日志记录到sidecar容器,必须指定Container作为spec.logging.access.destination.type。以下示例是将日志记录到Container目标的Ingress Controller定义:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Container
  • 当您将Ingress Controller配置为记录到sidecar容器时,operator会在Ingress Controller Pod内创建一个名为logs的容器。

    $ oc -n openshift-ingress logs deployment.apps/router-default -c logs
    示例输出
    2020-05-11T19:11:50.135710+00:00 router-default-57dfc6cd95-bpmk6 router-default-57dfc6cd95-bpmk6 haproxy[108]: 174.19.21.82:39654 [11/May/2020:19:11:50.133] public be_http:hello-openshift:hello-openshift/pod:hello-openshift:hello-openshift:10.128.2.12:8080 0/0/1/0/1 200 142 - - --NI 1/1/0/0/0 0/0 "GET / HTTP/1.1"

将Ingress访问日志配置到Syslog端点。

  • 要配置Ingress访问日志,必须使用spec.logging.access.destination指定目标。要指定将日志记录到Syslog端点目标,必须为spec.logging.access.destination.type指定Syslog。如果目标类型为Syslog,则还必须使用spec.logging.access.destination.syslog.address指定目标端点,并且可以使用spec.logging.access.destination.syslog.facility指定设施。以下示例是将日志记录到Syslog目标的Ingress Controller定义:

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514

    syslog目标端口必须为UDP。

    syslog 目标地址必须是 IP 地址。它不支持 DNS 主机名。

使用特定日志格式配置 Ingress 访问日志。

  • 您可以指定 spec.logging.access.httpLogFormat 来自定义日志格式。以下示例是一个 Ingress Controller 定义,它将日志记录到 IP 地址为 1.2.3.4 且端口为 10514 的 syslog 端点。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              port: 10514
          httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

禁用 Ingress 访问日志记录。

  • 要禁用 Ingress 访问日志记录,请将 spec.loggingspec.logging.access 留空。

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access: null

允许 Ingress Controller 在使用 sidecar 时修改 HAProxy 日志长度。

  • 如果您使用的是 spec.logging.access.destination.type: Syslog,请使用 spec.logging.access.destination.syslog.maxLength

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Syslog
            syslog:
              address: 1.2.3.4
              maxLength: 4096
              port: 10514
  • 如果您使用的是 spec.logging.access.destination.type: Container,请使用 spec.logging.access.destination.container.maxLength

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      replicas: 2
      logging:
        access:
          destination:
            type: Container
            container:
              maxLength: 8192

设置 Ingress Controller 线程数

集群管理员可以设置线程数以增加集群可以处理的传入连接数量。您可以修补现有的 Ingress Controller 以增加线程数量。

先决条件
  • 以下假设您已经创建了一个 Ingress Controller。

步骤
  • 更新 Ingress Controller 以增加线程数

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"threadCount": 8}}}'

    如果您有一个能够运行大量资源的节点,您可以使用与目标节点容量匹配的标签配置 spec.nodePlacement.nodeSelector,并将 spec.tuningOptions.threadCount 配置为适当的高值。

配置 Ingress Controller 以使用内部负载均衡器

在云平台上创建 Ingress Controller 时,Ingress Controller 默认由公共云负载均衡器发布。作为管理员,您可以创建一个使用内部云负载均衡器的 Ingress Controller。

如果您想更改 IngressControllerscope,可以在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

OpenShift Dedicated Ingress LoadBalancerService endpoint publishing strategy
图 1. 负载均衡器示意图

上图显示了与 OpenShift Dedicated Ingress LoadBalancerService 端点发布策略相关的以下概念。

  • 您可以使用云提供商负载均衡器进行外部负载均衡,也可以使用 OpenShift Ingress Controller 负载均衡器进行内部负载均衡。

  • 您可以使用负载均衡器的单个 IP 地址和更常用的端口,例如图中所示的集群中的 8080 和 4200。

  • 来自外部负载均衡器的流量定向到 Pod,并由负载均衡器管理,如节点宕机实例所示。有关实现细节,请参阅Kubernetes 服务文档

先决条件
  • 安装 OpenShift CLI (oc)。

  • 以具有cluster-admin权限的用户身份登录。

步骤
  1. 在一个名为 <name>-ingress-controller.yaml 的文件中创建一个 IngressController 自定义资源 (CR),例如以下示例所示

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: <name> (1)
    spec:
      domain: <domain> (2)
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal (3)
    1 <name> 替换为 IngressController 对象的名称。
    2 指定控制器发布的应用程序的 domain
    3 指定值为 Internal 以使用内部负载均衡器。
  2. 通过运行以下命令创建上一步中定义的 Ingress Controller

    $ oc create -f <name>-ingress-controller.yaml (1)
    1 <name> 替换为 IngressController 对象的名称。
  3. 可选:通过运行以下命令确认 Ingress Controller 是否已创建

    $ oc --all-namespaces=true get ingresscontrollers

设置 Ingress Controller 健康检查间隔

集群管理员可以设置健康检查间隔,以定义路由器在两次连续健康检查之间等待的时间。此值作为所有路由的全局默认值应用。默认值为 5 秒。

先决条件
  • 以下假设您已经创建了一个 Ingress Controller。

步骤
  • 更新 Ingress Controller 以更改后端健康检查之间的间隔

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"healthCheckInterval": "8s"}}}'

    要覆盖单个路由的 healthCheckInterval,请使用路由注释 router.openshift.io/haproxy.health.check.interval

将集群的默认 Ingress Controller 配置为内部

您可以通过删除并重新创建默认的 Ingress Controller 来将其配置为内部。

如果您想更改 IngressControllerscope,可以在创建自定义资源 (CR) 后更改 .spec.endpointPublishingStrategy.loadBalancer.scope 参数。

先决条件
  • 安装 OpenShift CLI (oc)。

  • 以具有cluster-admin权限的用户身份登录。

步骤
  1. 您可以通过删除并重新创建默认的 Ingress Controller 来将其配置为内部。

    $ oc replace --force --wait --filename - <<EOF
    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      namespace: openshift-ingress-operator
      name: default
    spec:
      endpointPublishingStrategy:
        type: LoadBalancerService
        loadBalancer:
          scope: Internal
    EOF

配置路由准入策略

管理员和应用程序开发人员可以在具有相同域名名的多个命名空间中运行应用程序。这适用于多个团队开发在同一主机名上公开的微服务的组织。

跨命名空间允许声明应仅在命名空间之间具有信任关系的集群中启用,否则恶意用户可能会接管主机名。因此,默认准入策略不允许跨命名空间的主机名声明。

先决条件
  • 集群管理员权限。

步骤
  • 使用以下命令编辑 ingresscontroller 资源变量的 .spec.routeAdmission 字段

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --patch '{"spec":{"routeAdmission":{"namespaceOwnership":"InterNamespaceAllowed"}}}' --type=merge
    Ingress Controller 配置示例
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed
    ...

    或者,您可以应用以下 YAML 来配置路由准入策略

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      routeAdmission:
        namespaceOwnership: InterNamespaceAllowed

使用通配符路由

HAProxy Ingress Controller 支持通配符路由。Ingress Operator 使用 wildcardPolicy 来配置 Ingress Controller 的 ROUTER_ALLOW_WILDCARD_ROUTES 环境变量。

Ingress Controller 的默认行为是接受通配符策略为 None 的路由,这与现有的 IngressController 资源向后兼容。

步骤
  1. 配置通配符策略。

    1. 使用以下命令编辑 IngressController 资源

      $ oc edit IngressController
    2. spec 下,将 wildcardPolicy 字段设置为 WildcardsDisallowedWildcardsAllowed

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

HTTP 头配置

OpenShift Dedicated 提供了不同的方法来处理 HTTP 头。在设置或删除头时,您可以使用 Ingress Controller 或单个路由中的特定字段来修改请求和响应头。您还可以使用路由注释来设置某些头。各种配置头的方法在协同工作时可能会带来挑战。

您只能在 IngressControllerRoute CR 中设置或删除头,不能附加它们。如果 HTTP 头设置为某个值,则该值必须完整,并且将来不需要附加。在需要附加头的情况下(例如 X-Forwarded-For 头),请使用 spec.httpHeaders.forwardedHeaderPolicy 字段,而不是 spec.httpHeaders.actions

优先级顺序

当 Ingress Controller 和 Route 中都修改了相同的 HTTP 头部时,HAProxy 会根据是请求头部还是响应头部,以特定的方式优先处理操作。

  • 对于 HTTP 响应头部,Ingress Controller 中指定的操作会在 Route 中指定的操作之后执行。这意味着 Ingress Controller 中指定的操作优先。

  • 对于 HTTP 请求头部,Route 中指定的操作会在 Ingress Controller 中指定的操作之后执行。这意味着 Route 中指定的操作优先。

例如,集群管理员使用以下配置在 Ingress Controller 中将 X-Frame-Options 响应头部设置为 `DENY` 值:

示例 `IngressController` 配置
apiVersion: operator.openshift.io/v1
kind: IngressController
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: DENY

Route 所有者设置了与集群管理员在 Ingress Controller 中设置的相同的响应头部,但值使用 `SAMEORIGIN`,使用以下配置:

示例 `Route` 配置
apiVersion: route.openshift.io/v1
kind: Route
# ...
spec:
  httpHeaders:
    actions:
      response:
      - name: X-Frame-Options
        action:
          type: Set
          set:
            value: SAMEORIGIN

当 `IngressController` 配置和 `Route` 配置都配置了 X-Frame-Options 响应头部时,即使特定 Route 允许框架,Ingress Controller 中全局级别为此头部设置的值也将优先,对于请求头部,`Route` 配置值会覆盖 `IngressController` 配置值。

这种优先级是因为 `haproxy.config` 文件使用了以下逻辑,其中 Ingress Controller 被视为前端,各个 Route 被视为后端。应用于前端配置的头部值 `DENY` 会覆盖在后端设置的相同头部值 `SAMEORIGIN`。

frontend public
  http-response set-header X-Frame-Options 'DENY'

frontend fe_sni
  http-response set-header X-Frame-Options 'DENY'

frontend fe_no_sni
  http-response set-header X-Frame-Options 'DENY'

backend be_secure:openshift-monitoring:alertmanager-main
  http-response set-header X-Frame-Options 'SAMEORIGIN'

此外,Ingress Controller 或 Route 中定义的任何操作都将覆盖使用 Route 注解设置的值。

特殊情况下的头部

以下头部要么完全禁止设置或删除,要么仅在特定情况下允许。

表 2. 特殊情况下的头部配置选项
头部名称 可使用 `IngressController` 配置 可使用 `Route` 配置 禁止的原因 可使用其他方法配置

proxy

`proxy` HTTP 请求头部可用于通过将头部值注入 `HTTP_PROXY` 环境变量来利用易受攻击的 CGI 应用程序。`proxy` HTTP 请求头部也是非标准的,并且在配置过程中容易出错。

host

当使用 `IngressController` CR 设置 `host` HTTP 请求头部时,HAProxy 在查找正确的 Route 时可能会失败。

strict-transport-security

`strict-transport-security` HTTP 响应头部已使用 Route 注解处理,无需单独实现。

是:`haproxy.router.openshift.io/hsts_header` Route 注解

`cookie` 和 `set-cookie`

HAProxy 设置的 Cookie 用于会话跟踪,以将客户端连接映射到特定的后端服务器。允许设置这些头部可能会干扰 HAProxy 的会话关联并限制 HAProxy 对 Cookie 的所有权。

  • `haproxy.router.openshift.io/disable_cookie` Route 注解

  • `haproxy.router.openshift.io/cookie_name` Route 注解

在 Ingress Controller 中设置或删除 HTTP 请求和响应头部

您可以出于合规性或其他原因设置或删除某些 HTTP 请求和响应头部。您可以为 Ingress Controller 提供服务的所有 Route 或特定 Route 设置或删除这些头部。

例如,您可能希望迁移在您的集群上运行的应用程序以使用双向 TLS,这需要您的应用程序检查 X-Forwarded-Client-Cert 请求头部,但 OpenShift Dedicated 默认 Ingress Controller 提供的是 X-SSL-Client-Der 请求头部。

以下过程修改 Ingress Controller 以设置 X-Forwarded-Client-Cert 请求头部,并删除 X-SSL-Client-Der 请求头部。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您可以作为具有cluster-admin角色的用户访问OpenShift Dedicated集群。

步骤
  1. 编辑 Ingress Controller 资源

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
  2. 将 X-SSL-Client-Der HTTP 请求头部替换为 X-Forwarded-Client-Cert HTTP 请求头部

    apiVersion: operator.openshift.io/v1
    kind: IngressController
    metadata:
      name: default
      namespace: openshift-ingress-operator
    spec:
      httpHeaders:
        actions: (1)
          request: (2)
          - name: X-Forwarded-Client-Cert (3)
            action:
              type: Set (4)
              set:
               value: "%{+Q}[ssl_c_der,base64]" (5)
          - name: X-SSL-Client-Der
            action:
              type: Delete
    1 您要在 HTTP 头部上执行的操作列表。
    2 您要更改的头部类型。在本例中,是请求头部。
    3 您要更改的头部名称。有关您可以设置或删除的可用头部的列表,请参见“HTTP 头部配置”。
    4 对头部执行的操作类型。此字段的值可以是 `Set` 或 `Delete`。
    5 设置 HTTP 头部时,必须提供一个 `value`。该值可以是该头部可用指令列表中的字符串,例如 `DENY`,也可以是将使用 HAProxy 的动态值语法解释的动态值。在本例中,添加了动态值。

    对于设置 HTTP 响应的动态头部值,允许的示例提取器是 `res.hdr` 和 `ssl_c_der`。对于设置 HTTP 请求的动态头部值,允许的示例提取器是 `req.hdr` 和 `ssl_c_der`。请求和响应动态值都可以使用 `lower` 和 `base64` 转换器。

  3. 保存文件以应用更改。

使用 X-Forwarded 头部

您可以配置 HAProxy Ingress Controller 以指定如何处理 HTTP 头部(包括 `Forwarded` 和 `X-Forwarded-For`)的策略。Ingress Operator 使用 `HTTPHeaders` 字段配置 Ingress Controller 的 `ROUTER_SET_FORWARDED_HEADERS` 环境变量。

步骤
  1. 配置 Ingress Controller 的 `HTTPHeaders` 字段。

    1. 使用以下命令编辑 IngressController 资源

      $ oc edit IngressController
    2. 在 `spec` 下,将 `HTTPHeaders` 策略字段设置为 `Append`、`Replace`、`IfNone` 或 `Never`。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

示例用例

作为集群管理员,您可以:

  • 配置一个外部代理,在将请求转发到 Ingress Controller 之前,将 `X-Forwarded-For` 头部注入到每个请求中。

    要配置 Ingress Controller 以原样传递头部,请指定 `never` 策略。然后,Ingress Controller 永远不会设置头部,应用程序只会接收外部代理提供的头部。

  • 配置 Ingress Controller 以原样传递外部代理在外部集群请求上设置的 `X-Forwarded-For` 头部。

    要配置 Ingress Controller 在内部集群请求(不会通过外部代理)上设置 `X-Forwarded-For` 头部,请指定 `if-none` 策略。如果 HTTP 请求已通过外部代理设置了头部,则 Ingress Controller 会保留它。如果由于请求没有通过代理而缺少头部,则 Ingress Controller 会添加该头部。

作为应用程序开发人员,您可以:

  • 配置一个应用程序特定的外部代理来注入 `X-Forwarded-For` 头部。

    要配置 Ingress Controller 以在应用程序的 Route 上原样传递头部,而不影响其他 Route 的策略,请在应用程序的 Route 上添加注解 `haproxy.router.openshift.io/set-forwarded-headers: if-none` 或 `haproxy.router.openshift.io/set-forwarded-headers: never`。

    您可以为每个路由单独设置haproxy.router.openshift.io/set-forwarded-headers 注解,这与 Ingress 控制器全局设置的值无关。

启用 HTTP/2 Ingress 连接

您可以在 HAProxy 中启用透明的端到端 HTTP/2 连接。这允许应用程序所有者使用 HTTP/2 协议的功能,包括单连接、报头压缩、二进制流等等。

您可以为单个 Ingress 控制器或整个集群启用 HTTP/2 连接。

要启用从客户端到 HAProxy 的连接使用 HTTP/2,路由必须指定自定义证书。使用默认证书的路由无法使用 HTTP/2。此限制是必要的,以避免连接合并问题,其中客户端对使用相同证书的不同路由重用连接。

从 HAProxy 到应用程序 Pod 的连接只能在重新加密路由中使用 HTTP/2,而不能在边缘终止或不安全的路由中使用。这是因为 HAProxy 使用应用程序级协议协商 (ALPN)(这是 TLS 扩展)与后端协商 HTTP/2 的使用。这意味着端到端 HTTP/2 可以与直通和重新加密一起使用,而不能与不安全或边缘终止的路由一起使用。

对于非直通路由,Ingress 控制器独立于来自客户端的连接来协商其与应用程序的连接。这意味着客户端可以连接到 Ingress 控制器并协商 HTTP/1.1,然后 Ingress 控制器可以连接到应用程序,协商 HTTP/2,并使用 HTTP/2 连接到应用程序转发来自客户端 HTTP/1.1 连接的请求。如果客户端随后尝试将其连接从 HTTP/1.1 升级到 WebSocket 协议,这就会产生问题,因为 Ingress 控制器无法将 WebSocket 转发到 HTTP/2,也无法将其 HTTP/2 连接升级到 WebSocket。因此,如果您有一个打算接受 WebSocket 连接的应用程序,则它必须不允许协商 HTTP/2 协议,否则客户端将无法升级到 WebSocket 协议。

步骤

在单个 Ingress 控制器上启用 HTTP/2。

  • 要在 Ingress 控制器上启用 HTTP/2,请输入oc annotate 命令

    $ oc -n openshift-ingress-operator annotate ingresscontrollers/<ingresscontroller_name> ingress.operator.openshift.io/default-enable-http2=true

    <ingresscontroller_name>替换为要添加注释的 Ingress 控制器的名称。

在整个集群上启用 HTTP/2。

  • 要为整个集群启用 HTTP/2,请输入oc annotate 命令

    $ oc annotate ingresses.config/cluster ingress.operator.openshift.io/default-enable-http2=true

    或者,您可以应用以下 YAML 来添加注释

    apiVersion: config.openshift.io/v1
    kind: Ingress
    metadata:
      name: cluster
      annotations:
        ingress.operator.openshift.io/default-enable-http2: "true"

为 Ingress 控制器配置 PROXY 协议

当 Ingress 控制器使用HostNetworkNodePortServicePrivate 端点发布策略类型时,集群管理员可以配置PROXY 协议。PROXY 协议使负载均衡器能够保留 Ingress 控制器接收的连接的原始客户端地址。原始客户端地址对于日志记录、过滤和注入 HTTP 头非常有用。在默认配置中,Ingress 控制器接收的连接仅包含与负载均衡器关联的源地址。

在非云平台上使用 Keepalived Ingress 虚拟 IP (VIP) 的安装程序预配集群的默认 Ingress 控制器不支持 PROXY 协议。

PROXY 协议使负载均衡器能够保留 Ingress 控制器接收的连接的原始客户端地址。原始客户端地址对于日志记录、过滤和注入 HTTP 头非常有用。在默认配置中,Ingress 控制器接收的连接仅包含与负载均衡器关联的源 IP 地址。

对于直通路由配置,OpenShift Dedicated 集群中的服务器无法观察原始客户端源 IP 地址。如果您需要知道原始客户端源 IP 地址,请为您的 Ingress 控制器配置 Ingress 访问日志记录,以便您可以查看客户端源 IP 地址。

对于重新加密和边缘路由,OpenShift Dedicated 路由器设置ForwardedX-Forwarded-For 头,以便应用程序工作负载检查客户端源 IP 地址。

有关 Ingress 访问日志记录的更多信息,请参阅“配置 Ingress 访问日志记录”。

使用LoadBalancerService 端点发布策略类型时,不支持为 Ingress 控制器配置 PROXY 协议。此限制是因为当 OpenShift Dedicated 在云平台上运行时,并且 Ingress 控制器指定应使用服务负载均衡器时,Ingress 运算符会根据平台保留源地址的要求配置负载均衡器服务并启用 PROXY 协议。

您必须将 OpenShift Dedicated 和外部负载均衡器都配置为使用 PROXY 协议或 TCP。

云部署中不支持此功能。此限制是因为当 OpenShift Dedicated 在云平台上运行时,并且 Ingress 控制器指定应使用服务负载均衡器时,Ingress 运算符会根据平台保留源地址的要求配置负载均衡器服务并启用 PROXY 协议。

您必须将 OpenShift Dedicated 和外部负载均衡器都配置为使用 PROXY 协议或传输控制协议 (TCP)。

先决条件
  • 您创建了一个 Ingress 控制器。

步骤
  1. 通过在您的 CLI 中输入以下命令来编辑 Ingress 控制器资源

    $ oc -n openshift-ingress-operator edit ingresscontroller/default
  2. 设置 PROXY 配置

    • 如果您的 Ingress 控制器使用HostNetwork 端点发布策略类型,请将spec.endpointPublishingStrategy.hostNetwork.protocol 子字段设置为PROXY

      hostNetwork 配置设置为PROXY 的示例
      # ...
        spec:
          endpointPublishingStrategy:
            hostNetwork:
              protocol: PROXY
            type: HostNetwork
      # ...
    • 如果您的 Ingress 控制器使用NodePortService 端点发布策略类型,请将spec.endpointPublishingStrategy.nodePort.protocol 子字段设置为PROXY

      nodePort 配置设置为PROXY 的示例
      # ...
        spec:
          endpointPublishingStrategy:
            nodePort:
              protocol: PROXY
            type: NodePortService
      # ...
    • 如果您的 Ingress 控制器使用Private 端点发布策略类型,请将spec.endpointPublishingStrategy.private.protocol 子字段设置为PROXY

      private 配置设置为PROXY 的示例
      # ...
        spec:
          endpointPublishingStrategy:
            private:
              protocol: PROXY
          type: Private
      # ...

使用 appsDomain 选项指定备用集群域

作为集群管理员,您可以通过配置appsDomain 字段来指定用户创建路由的默认集群域的替代方案。appsDomain 字段是 OpenShift Dedicated 用于代替默认域(在domain 字段中指定)的可选域。如果您指定了备用域,则它会覆盖默认集群域,用于确定新路由的默认主机。

例如,您可以使用贵公司的 DNS 域名作为集群上运行的应用程序的路由和入口的默认域名。

先决条件
  • 您已部署 OpenShift Dedicated 集群。

  • 您已安装 oc 命令行界面。

步骤
  1. 通过指定用户创建路由的替代默认域名来配置 appsDomain 字段。

    1. 编辑入口cluster资源

      $ oc edit ingresses.config/cluster -o yaml
    2. 编辑 YAML 文件

      appsDomain 配置示例设置为 test.example.com
      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            (1)
        appsDomain: <test.example.com>      (2)
      1 指定默认域名。安装后无法修改默认域名。
      2 可选:OpenShift Dedicated 基础设施用于应用程序路由的域名。您可以使用替代前缀(如 test),而不是默认前缀 apps
  2. 通过公开路由并验证路由域名的更改,验证现有路由是否包含 appsDomain 字段中指定的域名。

    等待 openshift-apiserver 完成滚动更新后再公开路由。

    1. 公开路由

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed
      示例输出
      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

转换 HTTP 头部大小写

HAProxy 默认情况下会将 HTTP 头部名称转换为小写;例如,将 Host: xyz.com 更改为 host: xyz.com。如果旧版应用程序对 HTTP 头部名称的大小写敏感,请使用 Ingress Controller 的 spec.httpHeaders.headerNameCaseAdjustments API 字段,以解决此问题,直到可以修复这些旧版应用程序为止。

OpenShift Dedicated 包含 HAProxy 2.8。如果您想更新到此版本的基于 Web 的负载均衡器,请确保将 spec.httpHeaders.headerNameCaseAdjustments 部分添加到集群的配置文件中。

作为集群管理员,您可以通过输入 oc patch 命令或在 Ingress Controller YAML 文件中设置 HeaderNameCaseAdjustments 字段来转换 HTTP 头部大小写。

先决条件
  • 您已安装OpenShift CLI (oc)。

  • 您具有作为具有cluster-admin角色的用户访问集群的权限。

步骤
  • 使用 oc patch 命令将 HTTP 头部大写。

    1. 运行以下命令将 HTTP 头部从 host 更改为 Host

      $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'
    2. 创建一个 Route 资源 YAML 文件,以便可以将注释应用于应用程序。

      名为 my-application 的路由示例
      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true (1)
        name: <application_name>
        namespace: <application_name>
      # ...
      1 设置 haproxy.router.openshift.io/h1-adjust-case,以便 Ingress Controller 可以根据指定调整 host 请求标头。
  • 通过在 Ingress Controller YAML 配置文件中配置 HeaderNameCaseAdjustments 字段来指定调整。

    1. 以下 Ingress Controller YAML 文件示例将 HTTP/1 请求到已正确注释路由的 host 头部调整为 Host

      Ingress Controller YAML 示例
      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          headerNameCaseAdjustments:
          - Host
    2. 以下路由示例使用 haproxy.router.openshift.io/h1-adjust-case 注释启用 HTTP 响应标头名称大小写调整

      路由 YAML 示例
      apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        annotations:
          haproxy.router.openshift.io/h1-adjust-case: true (1)
        name: my-application
        namespace: my-application
      spec:
        to:
          kind: Service
          name: my-application
      1 haproxy.router.openshift.io/h1-adjust-case 设置为 true。

使用路由器压缩

您可以配置 HAProxy Ingress Controller 以全局指定针对特定 MIME 类型的路由器压缩。您可以使用 mimeTypes 变量定义应用压缩的 MIME 类型的格式。这些类型包括:application、image、message、multipart、text、video 或以“X-”开头的自定义类型。要查看 MIME 类型和子类型的完整表示法,请参阅 RFC1341

为压缩分配的内存会影响最大连接数。此外,压缩大型缓冲区可能会导致延迟,例如繁重的正则表达式或很长的正则表达式列表。

并非所有 MIME 类型都受益于压缩,但如果指示 HAProxy 进行压缩,它仍然会使用资源进行尝试。通常,文本格式(例如 html、css 和 js 格式)会受益于压缩,但那些已经压缩的格式(例如图像、音频和视频)则几乎没有好处,但却要花费时间和资源进行压缩。

步骤
  1. 配置 Ingress Controller 的 httpCompression 字段。

    1. 使用以下命令编辑 IngressController 资源

      $ oc edit -n openshift-ingress-operator ingresscontrollers/default
    2. spec 下,将 httpCompression 策略字段设置为 mimeTypes 并指定应应用压缩的 MIME 类型列表。

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpCompression:
          mimeTypes:
          - "text/html"
          - "text/css; charset=utf-8"
          - "application/json"
         ...

公开路由器指标

您可以默认情况下以 Prometheus 格式在默认统计端口 1936 上公开 HAProxy 路由器指标。外部指标收集和聚合系统(例如 Prometheus)可以访问 HAProxy 路由器指标。您可以在浏览器中以 HTML 和逗号分隔值 (CSV) 格式查看 HAProxy 路由器指标。

先决条件
  • 您已将防火墙配置为访问默认统计端口 1936。

步骤
  1. 运行以下命令获取路由器 pod 名称

    $ oc get pods -n openshift-ingress
    示例输出
    NAME                              READY   STATUS    RESTARTS   AGE
    router-default-76bfffb66c-46qwp   1/1     Running   0          11h
  2. 获取路由器的用户名和密码,路由器 pod 将其存储在 /var/lib/haproxy/conf/metrics-auth/statsUsername/var/lib/haproxy/conf/metrics-auth/statsPassword 文件中

    1. 运行以下命令获取用户名

      $ oc rsh <router_pod_name> cat metrics-auth/statsUsername
    2. 运行以下命令获取密码

      $ oc rsh <router_pod_name> cat metrics-auth/statsPassword
  3. 运行以下命令获取路由器 IP 和指标证书

    $ oc describe pod <router_pod>
  4. 运行以下命令获取 Prometheus 格式的原始统计信息

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
  5. 运行以下命令安全地访问指标

    $ curl -u user:password https://<router_IP>:<stats_port>/metrics -k
  6. 运行以下命令访问默认统计端口 1936

    $ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics
    示例输出
    ...
    # HELP haproxy_backend_connections_total Total number of connections.
    # TYPE haproxy_backend_connections_total gauge
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route-alt"} 0
    haproxy_backend_connections_total{backend="http",namespace="default",route="hello-route01"} 0
    ...
    # HELP haproxy_exporter_server_threshold Number of servers tracked and the current threshold value.
    # TYPE haproxy_exporter_server_threshold gauge
    haproxy_exporter_server_threshold{type="current"} 11
    haproxy_exporter_server_threshold{type="limit"} 500
    ...
    # HELP haproxy_frontend_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_frontend_bytes_in_total gauge
    haproxy_frontend_bytes_in_total{frontend="fe_no_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="fe_sni"} 0
    haproxy_frontend_bytes_in_total{frontend="public"} 119070
    ...
    # HELP haproxy_server_bytes_in_total Current total of incoming bytes.
    # TYPE haproxy_server_bytes_in_total gauge
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_no_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="",pod="",route="",server="fe_sni",service=""} 0
    haproxy_server_bytes_in_total{namespace="default",pod="docker-registry-5-nk5fz",route="docker-registry",server="10.130.0.89:5000",service="docker-registry"} 0
    haproxy_server_bytes_in_total{namespace="default",pod="hello-rc-vkjqx",route="hello-route",server="10.130.0.90:8080",service="hello-svc-1"} 0
    ...
  7. 在浏览器中输入以下 URL 启动统计窗口

    http://<user>:<password>@<router_IP>:<stats_port>
  8. 可选:在浏览器中输入以下 URL 获取 CSV 格式的统计信息

    http://<user>:<password>@<router_ip>:1936/metrics;csv

自定义 HAProxy 错误代码响应页面

作为集群管理员,您可以为 503、404 或这两个错误页面指定自定义错误代码响应页面。当应用程序 pod 未运行时,HAProxy 路由器会提供 503 错误页面;当请求的 URL 不存在时,HAProxy 路由器会提供 404 错误页面。例如,如果您自定义 503 错误代码响应页面,则当应用程序 pod 未运行时会提供该页面,而 HAProxy 路由器会为错误路由或不存在的路由提供默认的 404 错误代码 HTTP 响应页面。

自定义错误代码响应页面在配置映射中指定,然后将其修补到 Ingress Controller。配置映射键有两个可用的文件名,如下所示:error-page-503.httperror-page-404.http

自定义 HTTP 错误代码响应页面必须遵循 HAProxy HTTP 错误页面配置指南。这是一个 OpenShift Dedicated HAProxy 路由器的默认 http 503 错误代码响应页面 示例。您可以使用默认内容作为创建自定义页面的模板。

默认情况下,当应用程序未运行或路由不正确或不存在时,HAProxy 路由器仅提供 503 错误页面。此默认行为与 OpenShift Dedicated 4.8 及更早版本的行为相同。如果没有提供用于自定义 HTTP 错误代码响应的配置映射,并且您正在使用自定义 HTTP 错误代码响应页面,则路由器会提供默认的 404 或 503 错误代码响应页面。

如果您使用 OpenShift Dedicated 默认的 503 错误代码页面作为自定义的模板,则文件中的标头需要可以使用 CRLF 行尾的编辑器。

步骤
  1. openshift-config 命名空间中创建一个名为 my-custom-error-code-pages 的配置映射

    $ oc -n openshift-config create configmap my-custom-error-code-pages \
    --from-file=error-page-503.http \
    --from-file=error-page-404.http

    如果您未为自定义错误代码响应页面指定正确的格式,则会发生路由器 pod 故障。要解决此故障,您必须删除或更正配置映射并删除受影响的路由器 pod,以便可以使用正确的信息重新创建它们。

  2. 修补 Ingress Controller 以按名称引用 my-custom-error-code-pages 配置映射

    $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge

    Ingress Operator 将openshift-config命名空间中的my-custom-error-code-pages配置映射复制到openshift-ingress命名空间。Operator 根据模式<你的Ingress控制器名称>-errorpagesopenshift-ingress命名空间中命名该配置映射。

  3. 显示复制结果

    $ oc get cm default-errorpages -n openshift-ingress
    示例输出
    NAME                       DATA   AGE
    default-errorpages         2      25s  (1)
    1 由于default Ingress控制器自定义资源 (CR) 已被修补,因此示例配置映射名称为default-errorpages
  4. 确认包含自定义错误响应页面的配置映射已挂载到路由器卷上,其中配置映射键是具有自定义HTTP错误代码响应的文件名。

    • 对于503自定义HTTP错误代码响应

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-503.http
    • 对于404自定义HTTP错误代码响应

      $ oc -n openshift-ingress rsh <router_pod> cat /var/lib/haproxy/conf/error_code_pages/error-page-404.http
验证

验证您的自定义错误代码HTTP响应

  1. 创建一个测试项目和应用程序

     $ oc new-project test-ingress
    $ oc new-app django-psql-example
  2. 对于503自定义HTTP错误代码响应

    1. 停止应用程序的所有Pod。

    2. 运行以下curl命令或在浏览器中访问路由主机名

      $ curl -vk <route_hostname>
  3. 对于404自定义HTTP错误代码响应

    1. 访问不存在的路由或不正确的路由。

    2. 运行以下curl命令或在浏览器中访问路由主机名

      $ curl -vk <route_hostname>
  4. 检查haproxy.config文件中errorfile属性是否正确。

    $ oc -n openshift-ingress rsh <router> cat /var/lib/haproxy/conf/haproxy.config | grep errorfile

设置Ingress控制器的最大连接数

集群管理员可以设置OpenShift路由器部署的最大并发连接数。您可以修补现有的Ingress控制器以增加最大连接数。

先决条件
  • 以下假设您已经创建了Ingress控制器。

步骤
  • 更新Ingress控制器以更改HAProxy的最大连接数。

    $ oc -n openshift-ingress-operator patch ingresscontroller/default --type=merge -p '{"spec":{"tuningOptions": {"maxConnections": 7500}}}'

    如果您将spec.tuningOptions.maxConnections值设置为大于当前操作系统限制的值,则HAProxy进程将无法启动。有关此参数的更多信息,请参阅“Ingress控制器配置参数”部分中的表格。

OpenShift Dedicated Ingress Operator配置

下表详细说明了Ingress Operator的组件以及Red Hat站点可靠性工程师 (SRE) 是否在OpenShift Dedicated集群上维护此组件。

表3. Ingress Operator责任图表
Ingress组件 由谁管理 默认配置?

扩展Ingress控制器

SRE

Ingress Operator线程数

SRE

Ingress控制器访问日志记录

SRE

Ingress控制器分片

SRE

Ingress控制器路由准入策略

SRE

Ingress控制器通配符路由

SRE

Ingress控制器X-Forwarded标头

SRE

Ingress控制器路由压缩

SRE