OpenShift 文档正在迁移，不久将仅在 docs.redhat.com（所有 Red Hat 产品文档的所在地）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

在 AWS 上的 Red Hat OpenShift 服务中的 Ingress 运算符

编辑

Ingress 运算符实现IngressController API，是启用对 AWS 集群服务的 Red Hat OpenShift 服务的外部访问的组件。

编辑

AWS 上的 Red Hat OpenShift 服务 Ingress 运算符

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

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

编辑

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 运算符使用集群 Ingress 配置中的域名作为默认 Ingress 控制器的域名。

  • OpenShift API 服务器运算符使用集群 Ingress 配置中的域名。此域名还在生成不指定显式主机的Route资源的默认主机时使用。

编辑

Ingress 控制器配置参数

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

参数 描述

domain

domain 是 Ingress 控制器服务的 DNS 名称，用于配置多个功能。

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

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

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

domain值在所有 Ingress 控制器中必须唯一，并且不能更新。

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

replicas

replicas 是 Ingress 控制器副本的数量。如果未设置，则默认值为2。

endpointPublishingStrategy

endpointPublishingStrategy 用于将 Ingress 控制器端点发布到其他网络、启用负载均衡器集成以及提供对其他系统的访问。

对于云环境，请使用loadBalancer字段为 Ingress 控制器配置端点发布策略。

您可以配置以下endpointPublishingStrategy字段：

  • loadBalancer.scope

  • loadBalancer.allowedSourceRanges

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

  • Amazon Web Services (AWS)：LoadBalancerService（具有外部范围）

defaultCertificate

defaultCertificate值是对包含 Ingress 控制器服务的默认证书的密钥的引用。当路由未指定自己的证书时，将使用defaultCertificate。

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

如果未设置，则会自动生成并使用通配符证书。证书对 Ingress 控制器domain和subdomains有效，生成的证书的 CA 会自动集成到集群的信任存储中。

正在使用的证书（无论是生成的还是用户指定的）都会自动与 AWS 内置 OAuth 服务器上的 Red Hat OpenShift 服务集成。

namespaceSelector

namespaceSelector用于过滤 Ingress 控制器服务的一组命名空间。这对于实现分片很有用。

routeSelector

routeSelector用于过滤 Ingress 控制器服务的一组路由。这对于实现分片很有用。

nodePlacement

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

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

nodePlacement 参数包括两部分：nodeSelector 和 tolerations。例如

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

tlsSecurityProfile

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

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

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

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

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

Ingress Operator 将 Old 或 Custom 配置文件的 TLS 1.0 转换为 1.1。

clientTLS

clientTLS 认证客户端对集群和服务的访问；因此，启用了双向 TLS 认证。如果未设置，则不会启用客户端 TLS。

clientTLS 具有必需的子字段 spec.clientTLS.clientCertificatePolicy 和 spec.clientTLS.ClientCA。

ClientCertificatePolicy 子字段接受两个值之一：Required 或 Optional。ClientCA 子字段指定位于 openshift-config 命名空间中的 ConfigMap。该 ConfigMap 应包含 CA 证书包。

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

routeAdmission

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

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

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

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

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

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

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

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 消息的最大长度。它必须介于 480 和 4096 字节之间。如果此字段为空，则最大长度设置为默认值 1024 字节。

        • facility 指定日志消息的 syslog 设施。如果此字段为空，则设施为 local1。否则，它必须指定有效的 syslog 设施：kern、user、mail、daemon、auth、syslog、lpr、news、uucp、cron、auth2、ftp、ntp、audit、alert、cron2、local0、local1、local2、local3、local4、local5、local6 或 local7。

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

httpHeaders

httpHeaders 定义 HTTP 头的策略。

通过设置 IngressControllerHTTPHeaders 的 forwardedHeaderPolicy，您可以指定 Ingress Controller 何时以及如何设置 Forwarded、X-Forwarded-For、X-Forwarded-Host、X-Forwarded-Port、X-Forwarded-Proto 和 X-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.response`和`spec.httpHeader.actions.request`

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

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

httpCompression

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

  • `mimeTypes`定义应应用压缩的MIME类型列表。例如，`text/css; charset=utf-8`、`text/html`、`text/*`、`image/svg+xml`、`application/octet-stream`、`X-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`字段使用`Exact`和`Prefix`参数。

例如

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

httpCaptureHeaders

`httpCaptureHeaders`指定您希望在访问日志中捕获的HTTP报头。如果`httpCaptureHeaders`字段为空，则访问日志不会捕获报头。

`httpCaptureHeaders`包含两个要在访问日志中捕获的报头列表。这两个报头字段列表是`request`和`response`。在这两个列表中，`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`、`-1`、`2000`到`2000000`之间的任何值，或者可以留空此字段。

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

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

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

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

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

logEmptyRequests

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

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

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

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

HTTPEmptyRequestsPolicy

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

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

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

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

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

Ingress Controller TLS 安全配置文件

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

编辑

了解 TLS 安全配置文件

您可以使用 TLS（传输层安全）安全配置文件来定义各种 Red Hat OpenShift Service on AWS 组件所需的 TLS 密码。Red Hat OpenShift Service on AWS 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 Controller 配置 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 Controller 的 TLS 连接的最小 TLS 版本和 TLS 密码。

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

HAProxy Ingress Controller 镜像支持 TLS 1.3 和Modern配置文件。

Ingress Operator 还将Old或Custom配置文件的 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 安全配置文件类型 (Old、Intermediate或Custom)。默认为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 Controller 以启用双向 TLS (mTLS) 身份验证。clientTLS值将 Ingress Controller 配置为验证客户端证书。此配置包括设置clientCA值，这是一个对 config map 的引用。config map 包含用于验证客户端证书的 PEM 编码的 CA 证书捆绑包。可选地，您还可以配置证书主题筛选器的列表。

如果clientCA值指定 X509v3 证书吊销列表 (CRL) 分发点，则 Ingress Operator 将根据每个提供的证书中指定的 HTTP URI X509v3 CRL Distribution Point 下载和管理 CRL config map。Ingress Controller 在 mTLS/TLS 协商期间使用此 config map。不提供有效证书的请求将被拒绝。

先决条件

  • 您可以以具有cluster-admin角色的用户身份访问集群。

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

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

     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 Controller

Ingress Operator 是 Red Hat OpenShift Service on AWS 的核心功能，默认启用。

每个新的 Red Hat OpenShift Service on AWS 安装都包含一个名为 default 的 ingresscontroller。可以补充添加额外的 Ingress Controller。如果删除默认 ingresscontroller，Ingress Operator 将在一分钟内自动重新创建它。

步骤

  • 查看默认 Ingress 控制器

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

查看 Ingress Operator 状态

您可以查看和检查 Ingress Operator 的状态。

步骤

  • 查看您的 Ingress Operator 状态

    $ oc describe clusteroperators/ingress
编辑

查看 Ingress Controller 日志

您可以查看您的 Ingress Controller 日志。

步骤

  • 查看您的 Ingress Controller 日志

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

查看 Ingress Controller 状态

您可以查看特定 Ingress Controller 的状态。

步骤

  • 查看 Ingress Controller 的状态

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

创建自定义 Ingress Controller

作为集群管理员，您可以创建一个新的自定义 Ingress Controller。由于默认 Ingress Controller 可能会在 Red Hat OpenShift Service on AWS 更新期间发生更改，因此在手动维护跨集群更新持续存在的配置时，创建自定义 Ingress Controller 会很有帮助。

此示例提供自定义 Ingress Controller 的最小规范。要进一步自定义您的自定义 Ingress Controller，请参阅“配置 Ingress Controller”。

先决条件

  • 安装 OpenShift 命令行界面 (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 Controller

编辑

设置自定义默认证书

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

先决条件

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

  • 您的证书满足以下要求：

    • 证书对入口域名有效。

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

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

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

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

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

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

  1. 使用 tls.crt 和 tls.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 命令行界面 (oc)。

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

步骤

  • 要删除自定义证书并恢复 Red Hat OpenShift Service on AWS 附带的证书，请输入以下命令：

    $ 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 命令行界面 (oc)。

  • 您可以作为具有 cluster-admin 角色的用户访问 Red Hat OpenShift Service on AWS 集群。

  • 您已安装自定义指标自动缩放程序运算符和相关的 KEDA 控制器。

    • 您可以使用 Web 控制台上的 OperatorHub 来安装运算符。安装运算符后，您可以创建 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。如果您拥有高流量集群，为避免超过日志记录堆栈的容量或与 Red Hat OpenShift Service on AWS 之外的日志记录基础设施集成，您可以将日志转发到自定义 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 时，操作员会在 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来自定义日志格式。以下示例是一个将日志记录到 IP 地址为 1.2.3.4 且端口为 10514 的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
      httpLogFormat: '%ci:%cp [%t] %ft %b/%s %B %bq %HM %HU %HV'

禁用 Ingress 访问日志记录。

  • 要禁用 Ingress 访问日志记录，请将spec.logging或spec.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。

如果您想更改IngressController的scope，您可以在创建自定义资源 (CR) 后更改.spec.endpointPublishingStrategy.loadBalancer.scope参数。
Red Hat OpenShift Service on AWS Ingress LoadBalancerService endpoint publishing strategy
图 1. 负载均衡器示意图

上图显示了与 Red Hat OpenShift Service on AWS Ingress LoadBalancerService 端点发布策略相关的以下概念

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

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

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

先决条件

  • 安装 OpenShift 命令行界面 (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 来将其配置为内部。

如果您想更改IngressController的scope，您可以在创建自定义资源 (CR) 后更改.spec.endpointPublishingStrategy.loadBalancer.scope参数。
先决条件

  • 安装 OpenShift 命令行界面 (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字段设置为WildcardsDisallowed或WildcardsAllowed

      spec:
  routeAdmission:
    wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

HTTP 头配置

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

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

优先级顺序

当在 Ingress Controller 和路由中同时修改相同的 HTTP 头时，HAProxy 会根据它是请求头还是响应头以某种方式优先执行操作。

  • 对于 HTTP 响应头，Ingress Controller 中指定的操作在路由中指定的操作之后执行。这意味着 Ingress Controller 中指定的操作具有优先权。

  • 对于 HTTP 请求头，路由中指定的操作在 Ingress Controller 中指定的操作之后执行。这意味着路由中指定的操作具有优先权。

例如，集群管理员使用以下配置在 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

路由所有者设置了集群管理员在 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 响应头时，即使特定路由允许框架，在 Ingress Controller 的全局级别为此头设置的值也具有优先权。对于请求头，Route规范值会覆盖IngressController规范值。

出现此优先级是因为haproxy.config文件使用以下逻辑，其中 Ingress Controller 被视为前端，单个路由被视为后端。应用于前端配置的头值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 或路由中定义的任何操作都会覆盖使用路由注释设置的值。

特殊情况下的头

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

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

proxy

否

否

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

否

host

否

是

当使用IngressController CR 设置host HTTP 请求头时，HAProxy 在查找正确路由时可能会失败。

否

strict-transport-security

否

否

strict-transport-security HTTP 响应头已通过路由注解处理，无需单独实现。

是的：haproxy.router.openshift.io/hsts_header 路由注解

cookie 和 set-cookie

否

否

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

是

  • haproxy.router.openshift.io/disable_cookie 路由注解

  • haproxy.router.openshift.io/cookie_name 路由注解
编辑

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

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

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

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

先决条件

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

  • 您可以作为具有 cluster-admin 角色的用户访问 Red Hat OpenShift Service on AWS 集群。

步骤

  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 运算符使用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 以不修改地传递应用程序路由的头，而不影响其他路由的策略，请在应用程序的路由上添加注释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 Controller 的全局设置值。
编辑

启用 HTTP/2 Ingress 连接

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

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

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

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

对于非直通路由，Ingress Controller 与应用程序的连接协商独立于客户端的连接。这意味着客户端可能会连接到 Ingress Controller 并协商 HTTP/1.1，然后 Ingress Controller 可能会连接到应用程序，协商 HTTP/2，并使用 HTTP/2 连接到应用程序转发来自客户端 HTTP/1.1 连接的请求。如果客户端随后尝试将其连接从 HTTP/1.1 升级到 WebSocket 协议，这就会出现问题，因为 Ingress Controller 无法将 WebSocket 转发到 HTTP/2，也无法将其 HTTP/2 连接升级到 WebSocket。因此，如果您有一个旨在接受 WebSocket 连接的应用程序，则它不能允许协商 HTTP/2 协议，否则客户端将无法升级到 WebSocket 协议。
步骤

在单个 Ingress Controller 上启用 HTTP/2。

  • 要在 Ingress Controller 上启用 HTTP/2，请输入oc annotate 命令

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

    将<ingresscontroller_name> 替换为要注释的 Ingress Controller 的名称。

在整个集群上启用 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 Controller 配置 PROXY 协议

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

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

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

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

对于重新加密和边缘路由，AWS 上的 Red Hat OpenShift Service 路由器会设置 `Forwarded` 和 `X-Forwarded-For` 头，以便应用程序工作负载检查客户端源 IP 地址。

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

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

您必须配置 AWS 上的 Red Hat OpenShift Service 和外部负载均衡器以使用 PROXY 协议或 TCP。

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

您必须配置 AWS 上的 Red Hat OpenShift Service 和外部负载均衡器以使用 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` 字段是 AWS 上 Red Hat OpenShift Service 可使用的可选域名，用于替代在 `domain` 字段中指定的默认域名。如果您指定了替代域名，它将覆盖默认集群域名，用于确定新路由的默认主机。

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

先决条件

  • 您已部署 AWS 上的 Red Hat OpenShift Service 集群。

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

步骤

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

    1. 编辑 ingress `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 可选：AWS 上 Red Hat OpenShift Service 基础架构用于应用程序路由的域名。您可以使用替代前缀（例如 `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 控制器 `spec.httpHeaders.headerNameCaseAdjustments` API 字段来解决此问题，直到可以修复这些旧版应用程序为止。

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

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

先决条件

  • 您已安装 OpenShift 命令行界面 (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 控制器可以根据指定调整 `host` 请求头。

  • 通过在 Ingress 控制器 YAML 配置文件中配置 `HeaderNameCaseAdjustments` 字段来指定调整。

    1. 以下 Ingress 控制器 YAML 文件示例将 `host` 头调整为 `Host`，用于对已正确注释路由的 HTTP/1 请求。

      Ingress 控制器 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 控制器以全局指定路由器压缩，用于特定 MIME 类型。您可以使用mimeTypes变量定义应用压缩的 MIME 类型的格式。这些类型包括：application、image、message、multipart、text、video 或以“X-”开头的自定义类型。要查看 MIME 类型和子类型的完整表示法，请参阅RFC1341。

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

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

  1. 配置 Ingress 控制器的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 不存在时，提供 404 错误页面。例如，如果您自定义 503 错误代码响应页面，则在应用程序 pod 未运行时提供该页面，并且 HAProxy 路由器为不正确的路由或不存在的路由提供默认的 404 错误代码 HTTP 响应页面。

自定义错误代码响应页面在配置映射中指定，然后修补到 Ingress 控制器。配置映射键有两个可用的文件名，如下所示：error-page-503.http和error-page-404.http。

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

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

如果您使用 Red Hat OpenShift Service on AWS 默认 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 控制器以按名称引用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 运算符将my-custom-error-code-pages配置映射从openshift-config命名空间复制到openshift-ingress命名空间。运算符根据模式<your_ingresscontroller_name>-errorpages在openshift-ingress命名空间中命名配置映射。

  3. 显示副本

    $ oc get cm default-errorpages -n openshift-ingress
    示例输出
    NAME                       DATA   AGE
default-errorpages         2      25s  (1)
    1 示例配置映射名称为default-errorpages，因为已修补default Ingress 控制器自定义资源 (CR)。

  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. 检查errorfile属性是否正确地在haproxy.config文件中。

    $ 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 控制器配置参数”部分中的表格。
编辑

Red Hat OpenShift Service on AWS Ingress 运算符配置

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

表 3. Ingress 运算符责任图
Ingress 组件 由谁管理 默认配置？

扩展 Ingress 控制器

SRE

是

入口控制器线程数

SRE

是

入口控制器访问日志记录

SRE

是

入口控制器分片

SRE

是

入口控制器路由准入策略

SRE

是

入口控制器通配符路由

SRE

是

入口控制器 X-Forwarded 头部

SRE

是

入口控制器路由压缩

SRE

是