OpenShift Container Platform 中的 Ingress 运算符 - 网络运算符 | 网络 | OpenShift Container Platform 4.17

OpenShift Container Platform Ingress 运算符
Ingress 配置资源
Ingress 控制器配置参数
- Ingress 控制器 TLS 安全配置文件
查看默认 Ingress 控制器
查看 Ingress 运算符状态
查看 Ingress 控制器日志
查看 Ingress 控制器状态
创建自定义 Ingress 控制器
配置 Ingress 控制器
其他资源

Ingress 运算符实现了IngressController API，是负责启用对 OpenShift Container Platform 集群服务的外部访问的组件。

OpenShift Container Platform Ingress 运算符

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

Ingress 运算符通过部署和管理一个或多个基于 HAProxy 的Ingress 控制器来处理路由，从而使外部客户端能够访问您的服务。您可以使用 Ingress 运算符通过指定 OpenShift Container Platform Route 和 Kubernetes Ingress 资源来路由流量。Ingress 控制器中的配置（例如定义endpointPublishingStrategy 类型和内部负载均衡的能力）提供了发布 Ingress 控制器端点的方法。

Ingress 配置资源

安装程序会生成一个资源为Ingress，API 组为config.openshift.io的资源，名为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 Server 运算符使用集群 Ingress 配置中的域。此域也用于为未指定显式主机的Route资源生成默认主机。

Ingress 控制器配置参数

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

参数描述

domain

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

对于LoadBalancerService 端点发布策略，domain 用于配置 DNS 记录。请参见endpointPublishingStrategy。
使用生成的默认证书时，证书对domain及其子域有效。请参见defaultCertificate。
该值发布到各个路由状态，以便用户知道在哪里定位外部 DNS 记录。

所有 Ingress 控制器中的domain值必须唯一，并且无法更新。

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

replicas

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

endpointPublishingStrategy

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

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

在 GCP、AWS 和 Azure 上，您可以配置以下endpointPublishingStrategy字段：

loadBalancer.scope
loadBalancer.allowedSourceRanges

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

Azure：LoadBalancerService（具有外部范围）
Google Cloud Platform (GCP)：LoadBalancerService（具有外部范围）

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

loadBalancer.scope
loadbalancer.providerParameters.gcp.clientAccess

对于非云环境（例如裸机平台），请使用NodePortService、HostNetwork或Private字段来配置 Ingress 控制器的端点发布策略。

如果您未在这些字段中的任何一个中设置值，则默认值基于IngressController CR 中.status.platform值中指定的绑定端口。

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

hostNetwork.protocol
nodePort.protocol
private.protocol

defaultCertificate

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

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

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

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

namespaceSelector

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

routeSelector

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

nodePlacement

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

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

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

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

tlsSecurityProfile

tlsSecurityProfile指定 Ingress 控制器的 TLS 连接设置。

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

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

Ingress 控制器的最小 TLS 版本为1.1，最大 TLS 版本为1.3。

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

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 命名空间中的配置映射。配置映射应包含 CA 证书捆绑包。

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

routeAdmission

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

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

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

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

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

IngressControllerLogging

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

access描述了如何记录客户端请求。如果此字段为空，则禁用访问日志记录。
- destination描述日志消息的目标。
  - type是日志目标的类型
    
    Container指定日志应发送到 sidecar 容器。Ingress Operator 在 Ingress Controller pod 上配置名为 **logs** 的容器，并配置 Ingress 控制器将日志写入该容器。预期管理员会配置一个自定义日志记录解决方案，该解决方案从该容器读取日志。使用容器日志意味着如果日志速率超过容器运行时容量或自定义日志记录解决方案容量，则日志可能会丢失。
    
    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 将无法启动。
- 如果您配置了不同 ulimits 的节点，并且您选择了一个离散值，建议为此字段使用 -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（传输层安全）安全配置文件来定义各种 OpenShift Container Platform 组件所需的 TLS 密码套件。OpenShift Container Platform TLS 安全配置文件基于 Mozilla 推荐的配置。

您可以为每个组件指定以下 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 版本上部署了使用 Intermediate 配置文件的规范，升级到 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` 角色的用户访问集群。

步骤

编辑 `openshift-ingress-operator` 项目中的 `IngressController` CR 以配置 TLS 安全配置文件
```
$ oc edit IngressController default -n openshift-ingress-operator
```

添加 `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 版本。

保存文件以应用更改。

验证

验证配置文件是否已在 `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` 值，这是一个对 ConfigMap 的引用。ConfigMap 包含用于验证客户端证书的 PEM 编码的 CA 证书捆绑包。您还可以选择配置证书主题筛选器列表。

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

先决条件

您可以使用具有 `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

步骤

在 `openshift-config` 命名空间中，从您的 CA 捆绑包创建 ConfigMap
```
$ oc create configmap \
   router-ca-certs-default \
   --from-file=ca-bundle.pem=client-ca.crt \(1)
   -n openshift-config
```
1 ConfigMap 数据键必须为 `ca-bundle.pem`，数据值必须为 PEM 格式的 CA 证书。
编辑 `openshift-ingress-operator` 项目中的 `IngressController` 资源
```
$ oc edit IngressController default -n openshift-ingress-operator
```

添加 `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$"

可选：通过输入以下命令获取 `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 是 OpenShift Container Platform 的核心功能，并且已开箱即用。

每个新的 OpenShift Container Platform 安装都具有名为 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 可能会在 OpenShift Container Platform 更新期间发生更改，因此在手动维护跨集群更新保持不变的配置时，创建自定义 Ingress Controller 会很有帮助。

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

先决条件

安装 OpenShift CLI ( `oc` )。
以具有 `cluster-admin` 权限的用户身份登录。

步骤

创建一个定义自定义 `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	指定包含自定义通配符证书的 Secret 的名称。
3	最小副本数必须为 1
4	将域指定为您的域名。IngressController 对象上指定的域和用于证书的域必须匹配。例如，如果域值为“custom_domain.mycompany.com”，则证书必须具有 SAN .custom_domain.mycompany.com（在域中添加了 `.`）。

通过运行以下命令来创建对象

$ 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

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

步骤

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

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

使用 `tls.crt` 和 `tls.key` 文件在 `openshift-ingress` 命名空间中创建包含自定义证书的 Secret 资源。
```
$ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key
```

更新 IngressController CR 以引用新的证书 Secret

$ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
  --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

验证更新是否有效

$ 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

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

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

删除自定义默认证书

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

先决条件

您可以使用具有 `cluster-admin` 角色的用户访问集群。
您已安装 OpenShift CLI（oc）。
您之前已为 Ingress Controller 配置了自定义默认证书。

步骤

要移除自定义证书并恢复 OpenShift Container Platform 附带的证书，请输入以下命令：
```
$ 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 Container Platform 集群。
您已安装自定义指标自动缩放器操作符和关联的 KEDA Controller。
- 您可以使用 Web 控制台上的 OperatorHub 安装操作符。安装操作符后，您可以创建一个 KedaController 实例。

步骤

运行以下命令创建服务帐户以使用 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>

使用以下命令手动创建服务帐户密钥令牌：

$ 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

使用服务帐户的令牌在 openshift-ingress-operator 命名空间中定义 TriggerAuthentication 对象。

创建 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

创建一个用于从 Thanos 读取指标的角色。

创建一个新的角色 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

运行以下命令应用新角色：

$ oc apply -f thanos-metrics-reader.yaml

输入以下命令将新角色添加到服务帐户：

$ 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 命名空间的查询，这需要此参数。

创建一个新的 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。您还必须具有读取此端口指标的提升权限。

运行以下命令应用自定义资源定义：
```
$ 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 的示例。

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

步骤

查看默认 IngressController 的当前可用副本数：

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

示例输出

使用 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

验证默认 IngressController 是否已缩放至您指定的副本数：

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

示例输出

或者，您可以应用以下 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 Container Platform 之外的日志记录基础设施集成，您可以将日志转发到自定义 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。

如果您的云提供商是Microsoft Azure，则必须至少有一个指向您的节点的公共负载均衡器。如果没有，您的所有节点都将丢失到互联网的出站连接。

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

OpenShift Container Platform Ingress LoadBalancerService endpoint publishing strategy

图1. 负载均衡器图

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

您可以使用云提供商负载均衡器进行外部负载均衡，也可以使用OpenShift Ingress Controller负载均衡器进行内部负载均衡。
您可以使用负载均衡器的单个IP地址和更常用的端口，例如图中所示的集群中的8080和4200。
来自外部负载均衡器的流量定向到Pod，并由负载均衡器管理，如图中节点宕机的情况所示。有关实现细节，请参阅Kubernetes服务文档。

先决条件

安装 OpenShift CLI ( `oc` )。
以具有 `cluster-admin` 权限的用户身份登录。

步骤

在一个名为<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`以使用内部负载均衡器。

通过运行以下命令来创建上一步中定义的Ingress Controller。
```
$ oc create -f <name>-ingress-controller.yaml (1)
```
1 将<name>替换为IngressController对象的名称。
可选：通过运行以下命令确认Ingress Controller已创建。
```
$ oc --all-namespaces=true get ingresscontrollers
```

配置GCP上Ingress Controller的全局访问

在GCP上使用内部负载均衡器创建的Ingress Controller会为服务生成一个内部IP地址。集群管理员可以指定全局访问选项，这使得位于与负载均衡器相同的VPC网络和计算区域内的任何区域中的客户端都可以访问在您的集群上运行的工作负载。

有关更多信息，请参阅GCP文档中的全局访问。

先决条件

您已在GCP基础架构上部署了OpenShift Container Platform集群。
您已将Ingress Controller配置为使用内部负载均衡器。
您已安装OpenShift CLI (oc)。

步骤

配置Ingress Controller资源以允许全局访问。

您也可以创建一个Ingress Controller并指定全局访问选项。

配置Ingress Controller资源

$ oc -n openshift-ingress-operator edit ingresscontroller/default

编辑YAML文件

clientAccess配置示例设置为Global

  spec:
    endpointPublishingStrategy:
      loadBalancer:
        providerParameters:
          gcp:
            clientAccess: Global (1)
          type: GCP
        scope: Internal
      type: LoadBalancerService

1	将`gcp.clientAccess`设置为`Global`。

保存文件以应用更改。

运行以下命令以验证服务是否允许全局访问。
```
$ oc -n openshift-ingress edit svc/router-default -o yaml
```
输出显示使用注释networking.gke.io/internal-load-balancer-allow-global-access为GCP启用了全局访问。

设置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来将其配置为内部。

如果您的云提供商是Microsoft Azure，则必须至少有一个指向您的节点的公共负载均衡器。如果没有，您的所有节点都将丢失到互联网的出站连接。

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

先决条件

安装 OpenShift CLI ( `oc` )。
以具有 `cluster-admin` 权限的用户身份登录。

步骤

您可以通过删除并重新创建默认的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. 使用以下命令编辑IngressController资源。
  $ oc edit IngressController
2. 在spec下，将wildcardPolicy字段设置为WildcardsDisallowed或WildcardsAllowed。
  spec: routeAdmission: wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

HTTP标头配置

OpenShift Container Platform 提供了多种处理 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 请求头部，但 OpenShift Container Platform 默认 Ingress Controller 提供 X-SSL-Client-Der 请求头部。

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

先决条件

您已安装 OpenShift CLI（oc）。
您可以以具有 cluster-admin 角色的用户身份访问 OpenShift Container Platform 集群。

步骤

编辑 Ingress Controller 资源

$ oc -n openshift-ingress-operator edit ingresscontroller/default

将 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 转换器。

保存文件以应用更改。

使用 X-Forwarded 头部

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

步骤

配置 Ingress Controller 的HTTPHeaders 字段。

使用以下命令编辑IngressController资源。
```
$ oc edit IngressController
```

在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 控制器之前，为每个请求注入X-Forwarded-For 头。

要配置 Ingress 控制器以未修改的方式传递该头，请指定never策略。然后，Ingress 控制器将永远不会设置这些头，应用程序只会接收外部代理提供的头。
配置 Ingress 控制器以未修改的方式传递外部代理在外部集群请求上设置的X-Forwarded-For 头。

要配置 Ingress 控制器在内部集群请求（不通过外部代理）上设置X-Forwarded-For 头，请指定if-none策略。如果 HTTP 请求已通过外部代理设置了该头，则 Ingress 控制器会保留它。如果该头不存在，因为请求没有通过代理，则 Ingress 控制器会添加该头。

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

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

要配置 Ingress 控制器以未修改的方式传递应用程序路由上的头，而不影响其他路由的策略，请在应用程序的路由上添加注释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 控制器使用HostNetwork、NodePortService或Private端点发布策略类型时，集群管理员可以配置PROXY 协议。PROXY 协议使负载均衡器能够保留 Ingress 控制器接收的连接的原始客户端地址。原始客户端地址对于日志记录、过滤和注入 HTTP 头很有用。在默认配置中，Ingress 控制器接收的连接仅包含与负载均衡器关联的源地址。

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

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

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

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

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

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

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

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

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

先决条件

您创建了一个 Ingress 控制器。

步骤

通过在您的 CLI 中输入以下命令来编辑 Ingress 控制器资源
```
$ oc -n openshift-ingress-operator edit ingresscontroller/default
```
设置 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 # ...

其他资源

配置 Ingress 访问日志记录

使用 appsDomain 选项指定替代集群域名

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

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

先决条件

您已部署了一个 OpenShift Container Platform 集群。
您已安装了 `oc` 命令行界面。

步骤

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

编辑 ingress `cluster` 资源

$ oc edit ingresses.config/cluster -o yaml

编辑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 Container Platform 基础设施用于应用程序路由的域名。您可以使用替代前缀（例如 `test`），而不是默认前缀 `apps`。

通过公开路由并验证路由域名更改，验证现有路由是否包含在 `appsDomain` 字段中指定的域名

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

公开路由

$ 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 Container Platform 包含 HAProxy 2.8。如果您想更新到此版本的基于 Web 的负载均衡器，请确保将 `spec.httpHeaders.headerNameCaseAdjustments` 部分添加到集群的配置文件中。

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

先决条件

您已安装 OpenShift CLI（oc）。
您可以使用具有 `cluster-admin` 角色的用户访问集群。

步骤

使用 `oc patch` 命令将 HTTP 头部大写。

通过运行以下命令将 HTTP 头部从 `host` 更改为 `Host`

$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"httpHeaders":{"headerNameCaseAdjustments":["Host"]}}}'

创建一个 `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` 字段来指定调整。

以下 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

以下路由示例使用 `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 格式）会受益于压缩，但已经压缩的格式（如图像、音频和视频）在压缩所花费的时间和资源方面几乎没有好处。

步骤

配置 Ingress Controller 的 `httpCompression` 字段。

使用以下命令编辑IngressController资源。

$ oc edit -n openshift-ingress-operator ingresscontrollers/default

在 `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。

步骤

通过运行以下命令获取路由器 pod 名称

$ oc get pods -n openshift-ingress

示例输出

NAME                              READY   STATUS    RESTARTS   AGE
router-default-76bfffb66c-46qwp   1/1     Running   0          11h

获取路由器的用户名和密码，路由器 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
通过运行以下命令获取路由器 IP 和指标证书
```
$ oc describe pod <router_pod>
```

通过运行以下命令获取 Prometheus 格式的原始统计信息

$ curl -u <user>:<password> http://<router_IP>:<stats_port>/metrics

通过运行以下命令安全地访问指标

$ curl -u user:password https://<router_IP>:<stats_port>/metrics -k

通过运行以下命令访问默认统计端口 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
...

在浏览器中输入以下 URL 以启动统计窗口
```
http://<user>:<password>@<router_IP>:<stats_port>
```
可选：在浏览器中输入以下 URL 以 CSV 格式获取统计信息
```
http://<user>:<password>@<router_ip>:1936/metrics;csv
```

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

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

自定义错误代码响应页面在 config map 中指定，然后修补到 Ingress Controller。config map 密钥有两个可用的文件名：`error-page-503.http` 和 `error-page-404.http`。

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

默认情况下，如果应用程序未运行或路由不正确或不存在，HAProxy 路由器只会返回 503 错误页面。此默认行为与 OpenShift Container Platform 4.8 及更早版本的行为相同。如果没有提供用于自定义 HTTP 错误代码响应的 ConfigMap，并且您正在使用自定义 HTTP 错误代码响应页面，则路由器将返回默认的 404 或 503 错误代码响应页面。

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

步骤

在 `openshift-config` 命名空间中创建一个名为 `my-custom-error-code-pages` 的 ConfigMap。

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

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

修补 Ingress Controller 以按名称引用 `my-custom-error-code-pages` ConfigMap。
```
$ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"httpErrorCodePages":{"name":"my-custom-error-code-pages"}}}' --type=merge
```
Ingress Operator 将 `my-custom-error-code-pages` ConfigMap 从 `openshift-config` 命名空间复制到 `openshift-ingress` 命名空间。Operator 根据模式 `-errorpages` 在 `openshift-ingress` 命名空间中命名 ConfigMap。
显示副本。
```
$ oc get cm default-errorpages -n openshift-ingress
```
示例输出
```
NAME                       DATA   AGE
default-errorpages         2      25s  (1)
```
1 示例 ConfigMap 名称是 `default-errorpages`，因为已修补了 `default` Ingress Controller 自定义资源 (CR)。
确认包含自定义错误响应页面的 ConfigMap 已挂载到路由器卷上，其中 ConfigMap 密钥是具有自定义 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 响应。

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

 $ oc new-project test-ingress

$ oc new-app django-psql-example

针对 503 自定义 HTTP 错误代码响应
1. 停止应用程序的所有 Pod。
2. 运行以下 curl 命令或在浏览器中访问路由主机名。
  $ curl -vk <route_hostname>
针对 404 自定义 HTTP 错误代码响应
1. 访问不存在的路由或不正确的路由。
2. 运行以下 curl 命令或在浏览器中访问路由主机名。
  $ curl -vk <route_hostname>

检查 `errorfile` 属性是否正确位于 `haproxy.config` 文件中。

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

设置 Ingress Controller 最大连接数

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

先决条件

以下假设您已经创建了一个 Ingress Controller。

步骤

更新 Ingress Controller 以更改 HAProxy 的最大连接数。

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

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

其他资源

配置自定义 PKI