×

创建基于 HTTP 的路由

路由允许您在公共 URL 上托管您的应用程序。根据应用程序的网络安全配置,它可以是安全的或不安全的。基于 HTTP 的路由是不安全的路由,它使用基本的 HTTP 路由协议并在不安全的应用程序端口上公开服务。

以下步骤描述了如何使用 `hello-openshift` 应用程序为例,创建一个简单的基于 HTTP 的路由到 Web 应用程序。

前提条件
  • 您已安装 OpenShift CLI(`oc`)。

  • 您已以管理员身份登录。

  • 您有一个 Web 应用程序,它公开了一个端口和一个在该端口上侦听流量的 TCP 端点。

步骤
  1. 通过运行以下命令创建一个名为 `hello-openshift` 的项目

    $ oc new-project hello-openshift
  2. 通过运行以下命令在项目中创建一个 Pod

    $ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
  3. 通过运行以下命令创建一个名为 `hello-openshift` 的服务

    $ oc expose pod/hello-openshift
  4. 通过运行以下命令创建一个指向 `hello-openshift` 应用程序的不安全路由

    $ oc expose svc hello-openshift
验证
  • 要验证您创建的 `route` 资源,请运行以下命令

    $ oc get routes -o yaml <name of resource> (1)
    1 在此示例中,路由名为 `hello-openshift`。
已创建的不安全路由的示例 YAML 定义
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: hello-openshift
spec:
  host: hello-openshift-hello-openshift.<Ingress_Domain> (1)
  port:
    targetPort: 8080 (2)
  to:
    kind: Service
    name: hello-openshift
1 `<Ingress_Domain>` 是默认的 Ingress 域名。`ingresses.config/cluster` 对象在安装期间创建,无法更改。如果要指定不同的域名,可以使用 `appsDomain` 选项指定备用集群域名。
2 `targetPort` 是此路由指向的服务选择的 Pod 上的目标端口。

要显示您的默认 Ingress 域名,请运行以下命令

$ oc get ingresses.config/cluster -o jsonpath={.spec.domain}

配置路由超时

当您拥有需要低超时(服务级别可用性 (SLA) 所需)或高超时(后端速度慢的情况)的服务时,您可以为现有路由配置默认超时。

前提条件
  • 您需要在正在运行的集群上部署 Ingress 控制器。

步骤
  1. 使用 `oc annotate` 命令,将超时添加到路由

    $ oc annotate route <route_name> \
        --overwrite haproxy.router.openshift.io/timeout=<timeout><time_unit> (1)
    1 支持的时间单位是微秒 (us)、毫秒 (ms)、秒 (s)、分钟 (m)、小时 (h) 或天 (d)。

    以下示例在名为 `myroute` 的路由上设置两秒的超时

    $ oc annotate route myroute --overwrite haproxy.router.openshift.io/timeout=2s

HTTP 严格传输安全

HTTP 严格传输安全 (HSTS) 策略是一种安全增强功能,它向浏览器客户端发出信号,表明只有 HTTPS 流量才允许在路由主机上使用。HSTS 还通过发出 HTTPS 传输所需的信号来优化 Web 流量,而无需使用 HTTP 重定向。HSTS 有助于加快与网站交互的速度。

当强制执行 HSTS 策略时,HSTS 会向来自站点的 HTTP 和 HTTPS 响应添加严格传输安全标头。您可以使用路由中的 `insecureEdgeTerminationPolicy` 值将 HTTP 重定向到 HTTPS。当强制执行 HSTS 时,客户端会在发送请求之前将所有来自 HTTP URL 的请求更改为 HTTPS,从而无需重定向。

集群管理员可以配置 HSTS 来执行以下操作

  • 启用每个路由的 HSTS

  • 按路由禁用 HSTS

  • 对一组域名强制实施 HSTS(每个域名),或将命名空间标签与域名结合使用

HSTS 仅适用于安全路由,无论是边缘终止路由还是重新加密路由。此配置对 HTTP 路由或直通路由无效。

按路由启用 HTTP 严格传输安全

HTTP 严格传输安全 (HSTS) 实现在 HAProxy 模板中,并应用于具有 haproxy.router.openshift.io/hsts_header 注解的边缘终止路由和重新加密路由。

前提条件
  • 您已使用具有项目管理员权限的用户登录到集群。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  • 要在路由上启用 HSTS,请将 haproxy.router.openshift.io/hsts_header 值添加到边缘终止路由或重新加密路由。您可以使用 oc annotate 工具通过运行以下命令来执行此操作。

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;\ (1)
    includeSubDomains;preload"
    1 在此示例中,最大年龄设置为 31536000 毫秒,约为 8.5 小时。

    在此示例中,等号 (=) 位于引号内。这是正确执行注释命令所必需的。

    配置了注释的示例路由
    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      annotations:
        haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload   (1) (2) (3)
    ...
    spec:
      host: def.abc.com
      tls:
        termination: "reencrypt"
        ...
      wildcardPolicy: "Subdomain"
    1 必需。max-age 用于衡量 HSTS 策略生效的时间长度(以秒为单位)。如果设置为 0,则会否定该策略。
    2 可选。包含时,includeSubDomains 会告诉客户端,主机的所有子域名都必须与主机具有相同的 HSTS 策略。
    3 可选。当 max-age 大于 0 时,您可以在 haproxy.router.openshift.io/hsts_header 中添加 preload,以允许外部服务将其站点包含在其 HSTS 预加载列表中。例如,Google 等站点可以构建一个设置了 preload 的站点列表。然后,浏览器可以使用这些列表来确定它们可以通过 HTTPS 与哪些站点通信,甚至在它们与站点交互之前。

按路由禁用 HTTP 严格传输安全

要按路由禁用 HTTP 严格传输安全 (HSTS),您可以将路由注释中的 max-age 值设置为 0

前提条件
  • 您已使用具有项目管理员权限的用户登录到集群。

  • 您已安装 OpenShift CLI(`oc`)。

步骤
  • 要禁用 HSTS,请将路由注释中的 max-age 值设置为 0,方法是输入以下命令。

    $ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"

    或者,您可以应用以下 YAML 来创建配置映射。

    按路由禁用 HSTS 的示例
    metadata:
      annotations:
        haproxy.router.openshift.io/hsts_header: max-age=0
  • 要禁用命名空间中每个路由的 HSTS,请输入以下命令。

    $ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
验证
  1. 要查询所有路由的注释,请输入以下命令。

    $ oc get route  --all-namespaces -o go-template='{{range .items}}{{if .metadata.annotations}}{{$a := index .metadata.annotations "haproxy.router.openshift.io/hsts_header"}}{{$n := .metadata.name}}{{with $a}}Name: {{$n}} HSTS: {{$a}}{{"\n"}}{{else}}{{""}}{{end}}{{end}}{{end}}'
    示例输出
    Name: routename HSTS: max-age=0

使用 Cookie 保持路由状态

OpenShift Dedicated 提供粘性会话,通过确保所有流量都命中相同的端点来启用有状态应用程序流量。但是,如果端点 Pod 终止(通过重启、缩放或配置更改),则此有状态性可能会消失。

OpenShift Dedicated 可以使用 Cookie 来配置会话持久性。入口控制器选择一个端点来处理任何用户请求,并为会话创建一个 Cookie。Cookie 会在对请求的响应中返回,用户会在会话中的下一个请求中将 Cookie 发送回。Cookie 会告诉入口控制器哪个端点正在处理会话,确保客户端请求使用 Cookie,以便它们被路由到相同的 Pod。

由于无法查看 HTTP 流量,因此无法在直通路由上设置 Cookie。相反,将根据源 IP 地址计算一个数字,该数字决定后端。

如果后端发生更改,则流量可能会被定向到错误的服务器,从而降低其粘性。如果您使用的是隐藏源 IP 的负载均衡器,则所有连接都会设置相同的数字,并且流量将发送到相同的 Pod。

您可以设置 Cookie 名称以覆盖路由的默认自动生成的 Cookie 名称。这允许接收路由流量的应用程序知道 Cookie 名称。删除 Cookie 可以强制下一个请求重新选择端点。结果是,如果服务器过载,该服务器会尝试从客户端删除请求并重新分配它们。

步骤
  1. 使用指定的 Cookie 名称注释路由

    $ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"

    其中

    <route_name>

    指定路由的名称。

    <cookie_name>

    指定 Cookie 的名称。

    例如,要使用 Cookie 名称 my_cookie 注释路由 my_route

    $ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
  2. 将路由主机名捕获到变量中

    $ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')

    其中

    <route_name>

    指定路由的名称。

  3. 保存 Cookie,然后访问路由

    $ curl $ROUTE_NAME -k -c /tmp/cookie_jar

    连接到路由时,使用上一个命令保存的 Cookie

    $ curl $ROUTE_NAME -k -b /tmp/cookie_jar

基于路径的路由

基于路径的路由指定可以与 URL 进行比较的路径组件,这要求路由的流量必须基于 HTTP。因此,可以使用相同的主机名服务多个路由,每个路由都有不同的路径。路由器应根据最具体的路径到最不具体的路径来匹配路由。

下表显示了示例路由及其可访问性

表 1. 路由可用性
路由 与……相比 是否可访问

www.example.com/test

www.example.com/test

www.example.com

www.example.com/testwww.example.com

www.example.com/test

www.example.com

www.example.com

www.example.com/text

是(由主机匹配,而不是路由)

www.example.com

具有路径的不安全路由
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: route-unsecured
spec:
  host: www.example.com
  path: "/test" (1)
  to:
    kind: Service
    name: service-name
1 路径是基于路径的路由的唯一附加属性。

使用直通 TLS 时,基于路径的路由不可用,因为在这种情况下路由器不会终止 TLS 并且无法读取请求的内容。

HTTP 头配置

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

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

优先级顺序

当在入口控制器和路由中都修改了相同的 HTTP 头时,HAProxy 会根据它是请求头还是响应头以某种方式优先执行操作。

  • 对于 HTTP 响应头,入口控制器中指定的操作将在路由中指定的操作之后执行。这意味着入口控制器中指定的操作具有优先权。

  • 对于 HTTP 请求头,路由中指定的操作将在入口控制器中指定的操作之后执行。这意味着路由中指定的操作具有优先权。

例如,集群管理员使用以下配置在 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 路由注释

cookieset-cookie

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

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

  • haproxy.router.openshift.io/cookie_name 路由注释

在路由中设置或删除 HTTP 请求和响应标头

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

例如,如果内容是用多种语言编写的,即使 Ingress Controller 指定了为路由提供服务的默认全局位置,您可能也希望启用 Web 应用程序为特定路由提供备用位置的内容。

以下过程创建一个设置 Content-Location HTTP 请求标头的路由,以便与应用程序关联的 URL(https://app.example.com)指向位置https://app.example.com/lang/en-us。将应用程序流量定向到此位置意味着任何使用该特定路由的人都正在访问用美式英语编写的 Web 内容。

前提条件
  • 您已安装 OpenShift CLI(oc)。

  • 您已以项目管理员身份登录到 OpenShift Dedicated 集群。

  • 您有一个 Web 应用程序,该应用程序公开一个端口以及一个侦听端口上流量的 HTTP 或 TLS 端点。

步骤
  1. 创建路由定义并将其保存在名为app-example-route.yaml的文件中

    创建的具有 HTTP 标头指令的路由的 YAML 定义
    apiVersion: route.openshift.io/v1
    kind: Route
    # ...
    spec:
      host: app.example.com
      tls:
        termination: edge
      to:
        kind: Service
        name: app-example
      httpHeaders:
        actions: (1)
          response: (2)
          - name: Content-Location (3)
            action:
              type: Set (4)
              set:
                value: /lang/en-us (5)
    1 您想要对 HTTP 标头执行的操作列表。
    2 您想要更改的标头类型。在本例中,为响应标头。
    3 您想要更改的标头的名称。有关您可以设置或删除的可用标头的列表,请参见《HTTP 标头配置》。
    4 对标头执行的操作类型。此字段的值可以是SetDelete
    5 设置 HTTP 标头时,必须提供value。该值可以是该标头的可用指令列表中的字符串,例如DENY,也可以是将使用 HAProxy 的动态值语法解释的动态值。在本例中,该值设置为内容的相对位置。
  2. 使用新创建的路由定义创建到现有 Web 应用程序的路由

    $ oc -n app-example create -f app-example-route.yaml

对于 HTTP 请求标头,路由定义中指定的操作将在 Ingress Controller 中对 HTTP 请求标头执行任何操作之后执行。这意味着在路由中为这些请求标头设置的任何值都将优先于在 Ingress Controller 中设置的值。有关 HTTP 标头处理顺序的更多信息,请参见《HTTP 标头配置》。

特定于路由的注释

Ingress Controller 可以为其公开的所有路由设置默认选项。单个路由可以通过在其注释中提供特定配置来覆盖其中一些默认值。Red Hat 不支持向运营商管理的路由添加路由注释。

要创建具有多个源 IP 或子网的白名单,请使用空格分隔的列表。任何其他分隔符类型都会导致忽略列表,而不会发出警告或错误消息。

表 3. 路由注释
变量 描述 用作默认值的環境變數

haproxy.router.openshift.io/balance

设置负载均衡算法。可用选项包括randomsourceroundrobinleastconn。对于 TLS 直通路由,默认值为source。对于所有其他路由,默认值为random

直通路由的ROUTER_TCP_BALANCE_SCHEME。否则,使用ROUTER_LOAD_BALANCE_ALGORITHM

haproxy.router.openshift.io/disable_cookies

禁用使用 Cookie 来跟踪相关连接。如果设置为'true''TRUE',则负载均衡算法用于为每个传入的 HTTP 请求选择哪个后端提供服务。

router.openshift.io/cookie_name

指定此路由要使用的可选 Cookie。名称必须由任何组合的大写和小写字母、数字、“_”和“-”组成。默认值为路由的哈希内部键名。

haproxy.router.openshift.io/pod-concurrent-connections

设置路由器允许到后端 Pod 的最大连接数。
注意:如果有多个 Pod,则每个 Pod 都可以有这么多连接。如果您有多个路由器,则它们之间没有协调,每个路由器都可能连接这么多次。如果未设置或设置为 0,则没有限制。

haproxy.router.openshift.io/rate-limit-connections

设置'true''TRUE'启用速率限制功能,该功能是通过每个路由的特定后端上的粘性表实现的。
注意:使用此注释可提供针对拒绝服务攻击的基本保护。

haproxy.router.openshift.io/rate-limit-connections.concurrent-tcp

限制通过相同源 IP 地址进行的并发 TCP 连接数。它接受数值。
注意:使用此注释可提供针对拒绝服务攻击的基本保护。

haproxy.router.openshift.io/rate-limit-connections.rate-http

限制具有相同源 IP 地址的客户端可以发出 HTTP 请求的速率。它接受数值。
注意:使用此注释可提供针对拒绝服务攻击的基本保护。

haproxy.router.openshift.io/rate-limit-connections.rate-tcp

限制具有相同源 IP 地址的客户端可以进行 TCP 连接的速率。它接受数值。
注意:使用此注释可提供针对拒绝服务攻击的基本保护。

haproxy.router.openshift.io/timeout

设置路由的服务器端超时。(时间单位)

ROUTER_DEFAULT_SERVER_TIMEOUT

haproxy.router.openshift.io/timeout-tunnel

此超时适用于隧道连接,例如,通过明文、边缘、重新加密或直通路由的 WebSocket。对于明文、边缘或重新加密类型的路由,此注释将作为具有现有超时值的超时隧道应用。对于直通类型的路由,此注释优先于任何已设置的现有超时值。

ROUTER_DEFAULT_TUNNEL_TIMEOUT

ingresses.config/cluster ingress.operator.openshift.io/hard-stop-after

您可以设置 IngressController 或 ingress 配置。此注释重新部署路由器并配置 HAProxy 以发出 haproxy `hard-stop-after` 全局选项,该选项定义允许执行干净软停止的最长时间。

ROUTER_HARD_STOP_AFTER

router.openshift.io/haproxy.health.check.interval

设置后端健康检查的间隔。(时间单位)

ROUTER_BACKEND_CHECK_INTERVAL

haproxy.router.openshift.io/ip_whitelist

为路由设置允许列表。允许列表是批准的源地址的 IP 地址和 CIDR 范围的空格分隔列表。来自允许列表中不存在的 IP 地址的请求将被丢弃。

在 `haproxy.config` 文件中直接可见的 IP 地址和 CIDR 范围的最大数量为 61。[1]

haproxy.router.openshift.io/hsts_header

为边缘终止或重新加密路由设置 Strict-Transport-Security 标头。

haproxy.router.openshift.io/rewrite-target

设置后端请求的重写路径。

router.openshift.io/cookie-same-site

设置一个值来限制cookie。其值包括:

`Lax`:浏览器不会在跨站点请求中发送 Cookie,但在用户从外部站点导航到原始站点时会发送 Cookie。当未指定 `SameSite` 值时,这是浏览器的默认行为。

`Strict`:浏览器仅对同站点请求发送 Cookie。

`None`:浏览器同时对跨站点和同站点请求发送 Cookie。

此值仅适用于重新加密和边缘路由。有关更多信息,请参阅 SameSite Cookie 文档

haproxy.router.openshift.io/set-forwarded-headers

设置每个路由处理 `Forwarded` 和 `X-Forwarded-For` HTTP 标头的策略。其值包括:

`append`:追加标头,保留任何现有标头。这是默认值。

`replace`:设置标头,删除任何现有标头。

`never`:从不设置标头,但保留任何现有标头。

`if-none`:如果标头尚未设置,则设置标头。

ROUTER_SET_FORWARDED_HEADERS

  1. 如果允许列表中 IP 地址和 CIDR 范围的数量超过 61 个,则将其写入单独的文件,然后从 `haproxy.config` 中引用该文件。此文件存储在 `var/lib/haproxy/router/whitelists` 文件夹中。

    要确保将地址写入允许列表,请检查 Ingress Controller 配置文件中是否列出了 CIDR 范围的完整列表。etcd 对象大小限制会限制路由注释可以有多大。因此,它为您可以包含在允许列表中的 IP 地址和 CIDR 范围的最大数量创建了一个阈值。

环境变量无法编辑。

路由器超时变量

`时间单位` 由一个数字后跟单位表示:`us`(微秒)、`ms`(毫秒,默认)、`s`(秒)、`m`(分钟)、`h`(小时)、`d`(天)。

正则表达式为:[1-9][0-9]*(`us`\|`ms`\|`s`\|`m`\|`h`\|`d`).

变量 默认值 描述

ROUTER_BACKEND_CHECK_INTERVAL

5000ms

后端后续存活性检查之间的时长。

ROUTER_CLIENT_FIN_TIMEOUT

1s

控制连接到路由的客户端的 TCP FIN 超时周期。如果在给定时间内未回复发送以关闭连接的 FIN,则 HAProxy 会关闭连接。如果设置为较低的值,则无害且使用更少的路由器资源。

ROUTER_DEFAULT_CLIENT_TIMEOUT

30s

客户端必须确认或发送数据的时长。

ROUTER_DEFAULT_CONNECT_TIMEOUT

5s

最大连接时间。

ROUTER_DEFAULT_SERVER_FIN_TIMEOUT

1s

控制从路由器到支持路由的 Pod 的 TCP FIN 超时。

ROUTER_DEFAULT_SERVER_TIMEOUT

30s

服务器必须确认或发送数据的时长。

ROUTER_DEFAULT_TUNNEL_TIMEOUT

1h

TCP 或 WebSocket 连接保持打开的时长。每当 HAProxy 重新加载时,此超时周期都会重置。

ROUTER_SLOWLORIS_HTTP_KEEPALIVE

300s

设置等待出现新 HTTP 请求的最长时间。如果设置得太低,则可能会导致浏览器和应用程序出现问题,因为它们不希望 `keepalive` 值很小。

一些有效的超时值可能是某些变量的总和,而不是特定的预期超时。例如,`ROUTER_SLOWLORIS_HTTP_KEEPALIVE` 会调整 `timeout http-keep-alive`。它默认设置为 `300s`,但 HAProxy 还会等待 `tcp-request inspect-delay`,该值设置为 `5s`。在这种情况下,总超时将为 `300s` 加 `5s`。

ROUTER_SLOWLORIS_TIMEOUT

10s

HTTP 请求传输可以持续的时长。

RELOAD_INTERVAL

5s

允许路由器重新加载并接受新更改的最小频率。

ROUTER_METRICS_HAPROXY_TIMEOUT

5s

收集 HAProxy 指标的超时。

路由设置自定义超时
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/timeout: 5500ms (1)
...
1 使用 HAProxy 支持的单位(`us`、`ms`、`s`、`m`、`h`、`d`)指定新的超时。如果未提供单位,则默认为 `ms`。

将直通路由的服务器端超时值设置得太低可能会导致该路由上的 WebSocket 连接频繁超时。

仅允许一个特定 IP 地址的路由
metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
允许多个 IP 地址的路由
metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
允许 IP 地址 CIDR 网络的路由
metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
允许 IP 地址和 IP 地址 CIDR 网络的路由
metadata:
  annotations:
    haproxy.router.openshift.io/ip_whitelist: 180.5.61.153 192.168.1.0/24 10.0.0.0/8
指定重写目标的路由
apiVersion: route.openshift.io/v1
kind: Route
metadata:
  annotations:
    haproxy.router.openshift.io/rewrite-target: / (1)
...
1 将 `/` 设置为后端请求的重写路径。

在路由上设置 `haproxy.router.openshift.io/rewrite-target` 注释指定在将请求转发到后端应用程序之前,Ingress Controller 应该使用此路由重写 HTTP 请求中的路径。与 `spec.path` 中指定的路径匹配的请求路径部分将替换为此注释中指定的重写目标。

下表提供了针对 `spec.path`、请求路径和重写目标的各种组合的路径重写行为示例。

表 4. rewrite-target 示例
Route.spec.path 请求路径 重写目标 转发请求路径

/foo

/foo

/

/

/foo

/foo/

/

/

/foo

/foo/bar

/

/bar

/foo

/foo/bar/

/

/bar/

/foo

/foo

/bar

/bar

/foo

/foo/

/bar

/bar/

/foo

/foo/bar

/baz

/baz/bar

/foo

/foo/bar/

/baz

/baz/bar/

/foo/

/foo

/

N/A(请求路径与路由路径不匹配)

/foo/

/foo/

/

/

/foo/

/foo/bar

/

/bar

haproxy.router.openshift.io/rewrite-target 中某些特殊字符需要特殊处理,因为必须对其进行正确的转义。请参考下表了解这些字符的处理方式。

表 5. 特殊字符处理
对于字符 使用字符 备注

#

\#

避免使用 #,因为它会终止重写表达式

%

% 或 %%

避免使用奇数个百分号序列,例如 %%%

\’

避免使用 ‘,因为它会被忽略

所有其他有效的 URL 字符都可以直接使用,无需转义。

使用默认证书通过 Ingress 对象创建路由

如果您创建 Ingress 对象时未指定任何 TLS 配置,OpenShift Dedicated 将生成一个不安全的路由。要创建使用默认 Ingress 证书生成安全、边缘终止路由的 Ingress 对象,您可以指定如下所示的空 TLS 配置。

前提条件
  • 您有一个要公开的服务。

  • 您可以访问 OpenShift CLI (oc)。

步骤
  1. 为 Ingress 对象创建一个 YAML 文件。在此示例中,该文件名为 example-ingress.yaml

    Ingress 对象的 YAML 定义
    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      ...
    spec:
      rules:
        ...
      tls:
      - {} (1)
    1 使用此确切语法指定 TLS,无需指定自定义证书。
  2. 运行以下命令创建 Ingress 对象

    $ oc create -f example-ingress.yaml
验证
  • 运行以下命令验证 OpenShift Dedicated 是否已为 Ingress 对象创建了预期的路由

    $ oc get routes -o yaml
    示例输出
    apiVersion: v1
    items:
    - apiVersion: route.openshift.io/v1
      kind: Route
      metadata:
        name: frontend-j9sdd (1)
        ...
      spec:
      ...
        tls: (2)
          insecureEdgeTerminationPolicy: Redirect
          termination: edge (3)
      ...
    1 路由名称包括 Ingress 对象的名称以及一个随机后缀。
    2 为了使用默认证书,路由不应指定 spec.certificate
    3 路由应指定 edge 终止策略。

使用 Ingress 注解中的目标 CA 证书创建路由

route.openshift.io/destination-ca-certificate-secret 注解可用于在 Ingress 对象上定义具有自定义目标 CA 证书的路由。

前提条件
  • 您可能拥有 PEM 编码文件的证书/密钥对,其中证书对路由主机有效。

  • 您可能拥有 PEM 编码文件的单独 CA 证书,它可以完成证书链。

  • 您必须拥有 PEM 编码文件的单独目标 CA 证书。

  • 您必须有一个要公开的服务。

步骤
  1. route.openshift.io/destination-ca-certificate-secret 添加到 Ingress 注解中

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: frontend
      annotations:
        route.openshift.io/termination: "reencrypt"
        route.openshift.io/destination-ca-certificate-secret: secret-ca-cert (1)
    ...
    1 此注解引用了一个 Kubernetes 密钥。
  2. 此注解中引用的密钥将插入生成的路由中。

    示例输出
    apiVersion: route.openshift.io/v1
    kind: Route
    metadata:
      name: frontend
      annotations:
        route.openshift.io/termination: reencrypt
        route.openshift.io/destination-ca-certificate-secret: secret-ca-cert
    spec:
    ...
      tls:
        insecureEdgeTerminationPolicy: Redirect
        termination: reencrypt
        destinationCACertificate: |
          -----BEGIN CERTIFICATE-----
          [...]
          -----END CERTIFICATE-----
    ...