$ oc new-project hello-openshift
路由允许您在公共 URL 上托管您的应用程序。根据应用程序的网络安全配置,它可以是安全的或不安全的。基于 HTTP 的路由是不安全的路由,它使用基本的 HTTP 路由协议并在不安全的应用程序端口上公开服务。
以下步骤描述了如何使用 `hello-openshift` 应用程序为例,创建一个简单的基于 HTTP 的路由到 Web 应用程序。
您已安装 OpenShift CLI(`oc`)。
您已以管理员身份登录。
您有一个 Web 应用程序,它公开了一个端口和一个在该端口上侦听流量的 TCP 端点。
通过运行以下命令创建一个名为 `hello-openshift` 的项目
$ oc new-project hello-openshift
通过运行以下命令在项目中创建一个 Pod
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/hello-openshift/hello-pod.json
通过运行以下命令创建一个名为 `hello-openshift` 的服务
$ oc expose pod/hello-openshift
通过运行以下命令创建一个指向 `hello-openshift` 应用程序的不安全路由
$ oc expose svc hello-openshift
要验证您创建的 `route` 资源,请运行以下命令
$ oc get routes -o yaml <name of resource> (1)
1 | 在此示例中,路由名为 `hello-openshift`。 |
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 上的目标端口。
|
当您拥有需要低超时(服务级别可用性 (SLA) 所需)或高超时(后端速度慢的情况)的服务时,您可以为现有路由配置默认超时。
您需要在正在运行的集群上部署 Ingress 控制器。
使用 `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 严格传输安全 (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 严格传输安全 (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 严格传输安全 (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 的示例
|
要禁用命名空间中每个路由的 HSTS,请输入以下命令。
$ oc annotate route --all -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=0"
要查询所有路由的注释,请输入以下命令。
$ 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
OpenShift Dedicated 提供粘性会话,通过确保所有流量都命中相同的端点来启用有状态应用程序流量。但是,如果端点 Pod 终止(通过重启、缩放或配置更改),则此有状态性可能会消失。
OpenShift Dedicated 可以使用 Cookie 来配置会话持久性。入口控制器选择一个端点来处理任何用户请求,并为会话创建一个 Cookie。Cookie 会在对请求的响应中返回,用户会在会话中的下一个请求中将 Cookie 发送回。Cookie 会告诉入口控制器哪个端点正在处理会话,确保客户端请求使用 Cookie,以便它们被路由到相同的 Pod。
由于无法查看 HTTP 流量,因此无法在直通路由上设置 Cookie。相反,将根据源 IP 地址计算一个数字,该数字决定后端。 如果后端发生更改,则流量可能会被定向到错误的服务器,从而降低其粘性。如果您使用的是隐藏源 IP 的负载均衡器,则所有连接都会设置相同的数字,并且流量将发送到相同的 Pod。 |
您可以设置 Cookie 名称以覆盖路由的默认自动生成的 Cookie 名称。这允许接收路由流量的应用程序知道 Cookie 名称。删除 Cookie 可以强制下一个请求重新选择端点。结果是,如果服务器过载,该服务器会尝试从客户端删除请求并重新分配它们。
使用指定的 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"
将路由主机名捕获到变量中
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
其中
<route_name>
指定路由的名称。
保存 Cookie,然后访问路由
$ curl $ROUTE_NAME -k -c /tmp/cookie_jar
连接到路由时,使用上一个命令保存的 Cookie
$ curl $ROUTE_NAME -k -b /tmp/cookie_jar
基于路径的路由指定可以与 URL 进行比较的路径组件,这要求路由的流量必须基于 HTTP。因此,可以使用相同的主机名服务多个路由,每个路由都有不同的路径。路由器应根据最具体的路径到最不具体的路径来匹配路由。
下表显示了示例路由及其可访问性
路由 | 与……相比 | 是否可访问 |
---|---|---|
www.example.com/test |
www.example.com/test |
是 |
www.example.com |
否 |
|
www.example.com/test 和 www.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 并且无法读取请求的内容。 |
OpenShift Dedicated 提供了不同的处理 HTTP 头的方法。在设置或删除头时,您可以使用入口控制器或单个路由中的特定字段来修改请求和响应头。您还可以使用路由注释设置某些头。各种配置头的方法在协同工作时可能会带来挑战。
您只能在 |
当在入口控制器和路由中都修改了相同的 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 或路由中定义的任何操作都将覆盖使用路由注释设置的值。
以下标头要么完全禁止设置或删除,要么在特定情况下允许
标头名称 | 使用IngressController 规范可配置 |
使用Route 规范可配置 |
不允许的原因 | 使用其他方法可配置 |
---|---|---|---|---|
|
否 |
否 |
|
否 |
|
否 |
是 |
当使用 |
否 |
|
否 |
否 |
|
是: |
|
否 |
否 |
HAProxy 设置的 Cookie 用于会话跟踪,以将客户端连接映射到特定的后端服务器。允许设置这些标头可能会干扰 HAProxy 的会话关联并限制 HAProxy 对 Cookie 的所有权。 |
是
|
您可以设置或删除某些 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 端点。
创建路由定义并将其保存在名为app-example-route.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 | 对标头执行的操作类型。此字段的值可以是Set 或Delete 。 |
5 | 设置 HTTP 标头时,必须提供value 。该值可以是该标头的可用指令列表中的字符串,例如DENY ,也可以是将使用 HAProxy 的动态值语法解释的动态值。在本例中,该值设置为内容的相对位置。 |
使用新创建的路由定义创建到现有 Web 应用程序的路由
$ oc -n app-example create -f app-example-route.yaml
对于 HTTP 请求标头,路由定义中指定的操作将在 Ingress Controller 中对 HTTP 请求标头执行任何操作之后执行。这意味着在路由中为这些请求标头设置的任何值都将优先于在 Ingress Controller 中设置的值。有关 HTTP 标头处理顺序的更多信息,请参见《HTTP 标头配置》。
Ingress Controller 可以为其公开的所有路由设置默认选项。单个路由可以通过在其注释中提供特定配置来覆盖其中一些默认值。Red Hat 不支持向运营商管理的路由添加路由注释。
要创建具有多个源 IP 或子网的白名单,请使用空格分隔的列表。任何其他分隔符类型都会导致忽略列表,而不会发出警告或错误消息。 |
变量 | 描述 | 用作默认值的環境變數 |
---|---|---|
|
设置负载均衡算法。可用选项包括 |
直通路由的 |
|
禁用使用 Cookie 来跟踪相关连接。如果设置为 |
|
|
指定此路由要使用的可选 Cookie。名称必须由任何组合的大写和小写字母、数字、“_”和“-”组成。默认值为路由的哈希内部键名。 |
|
|
设置路由器允许到后端 Pod 的最大连接数。 |
|
|
设置 |
|
|
限制通过相同源 IP 地址进行的并发 TCP 连接数。它接受数值。 |
|
|
限制具有相同源 IP 地址的客户端可以发出 HTTP 请求的速率。它接受数值。 |
|
|
限制具有相同源 IP 地址的客户端可以进行 TCP 连接的速率。它接受数值。 |
|
|
设置路由的服务器端超时。(时间单位) |
|
|
此超时适用于隧道连接,例如,通过明文、边缘、重新加密或直通路由的 WebSocket。对于明文、边缘或重新加密类型的路由,此注释将作为具有现有超时值的超时隧道应用。对于直通类型的路由,此注释优先于任何已设置的现有超时值。 |
|
|
您可以设置 IngressController 或 ingress 配置。此注释重新部署路由器并配置 HAProxy 以发出 haproxy `hard-stop-after` 全局选项,该选项定义允许执行干净软停止的最长时间。 |
|
|
设置后端健康检查的间隔。(时间单位) |
|
|
为路由设置允许列表。允许列表是批准的源地址的 IP 地址和 CIDR 范围的空格分隔列表。来自允许列表中不存在的 IP 地址的请求将被丢弃。 在 `haproxy.config` 文件中直接可见的 IP 地址和 CIDR 范围的最大数量为 61。[1] |
|
|
为边缘终止或重新加密路由设置 Strict-Transport-Security 标头。 |
|
|
设置后端请求的重写路径。 |
|
|
设置一个值来限制cookie。其值包括: `Lax`:浏览器不会在跨站点请求中发送 Cookie,但在用户从外部站点导航到原始站点时会发送 Cookie。当未指定 `SameSite` 值时,这是浏览器的默认行为。 `Strict`:浏览器仅对同站点请求发送 Cookie。 `None`:浏览器同时对跨站点和同站点请求发送 Cookie。 此值仅适用于重新加密和边缘路由。有关更多信息,请参阅 SameSite Cookie 文档。 |
|
|
设置每个路由处理 `Forwarded` 和 `X-Forwarded-For` HTTP 标头的策略。其值包括: `append`:追加标头,保留任何现有标头。这是默认值。 `replace`:设置标头,删除任何现有标头。 `never`:从不设置标头,但保留任何现有标头。 `if-none`:如果标头尚未设置,则设置标头。 |
|
如果允许列表中 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`).
变量 | 默认值 | 描述 |
---|---|---|
|
|
后端后续存活性检查之间的时长。 |
|
|
控制连接到路由的客户端的 TCP FIN 超时周期。如果在给定时间内未回复发送以关闭连接的 FIN,则 HAProxy 会关闭连接。如果设置为较低的值,则无害且使用更少的路由器资源。 |
|
|
客户端必须确认或发送数据的时长。 |
|
|
最大连接时间。 |
|
|
控制从路由器到支持路由的 Pod 的 TCP FIN 超时。 |
|
|
服务器必须确认或发送数据的时长。 |
|
|
TCP 或 WebSocket 连接保持打开的时长。每当 HAProxy 重新加载时,此超时周期都会重置。 |
|
|
设置等待出现新 HTTP 请求的最长时间。如果设置得太低,则可能会导致浏览器和应用程序出现问题,因为它们不希望 `keepalive` 值很小。 一些有效的超时值可能是某些变量的总和,而不是特定的预期超时。例如,`ROUTER_SLOWLORIS_HTTP_KEEPALIVE` 会调整 `timeout http-keep-alive`。它默认设置为 `300s`,但 HAProxy 还会等待 `tcp-request inspect-delay`,该值设置为 `5s`。在这种情况下,总超时将为 `300s` 加 `5s`。 |
|
|
HTTP 请求传输可以持续的时长。 |
|
|
允许路由器重新加载并接受新更改的最小频率。 |
|
|
收集 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 连接频繁超时。 |
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.10 192.168.1.11 192.168.1.12
metadata:
annotations:
haproxy.router.openshift.io/ip_whitelist: 192.168.1.0/24
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`、请求路径和重写目标的各种组合的路径重写行为示例。
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
中某些特殊字符需要特殊处理,因为必须对其进行正确的转义。请参考下表了解这些字符的处理方式。
对于字符 | 使用字符 | 备注 |
---|---|---|
# |
\# |
避免使用 #,因为它会终止重写表达式 |
% |
% 或 %% |
避免使用奇数个百分号序列,例如 %%% |
‘ |
\’ |
避免使用 ‘,因为它会被忽略 |
所有其他有效的 URL 字符都可以直接使用,无需转义。
如果您创建 Ingress 对象时未指定任何 TLS 配置,OpenShift Dedicated 将生成一个不安全的路由。要创建使用默认 Ingress 证书生成安全、边缘终止路由的 Ingress 对象,您可以指定如下所示的空 TLS 配置。
您有一个要公开的服务。
您可以访问 OpenShift CLI (oc
)。
为 Ingress 对象创建一个 YAML 文件。在此示例中,该文件名为 example-ingress.yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: frontend
...
spec:
rules:
...
tls:
- {} (1)
1 | 使用此确切语法指定 TLS,无需指定自定义证书。 |
运行以下命令创建 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 终止策略。 |
route.openshift.io/destination-ca-certificate-secret
注解可用于在 Ingress 对象上定义具有自定义目标 CA 证书的路由。
您可能拥有 PEM 编码文件的证书/密钥对,其中证书对路由主机有效。
您可能拥有 PEM 编码文件的单独 CA 证书,它可以完成证书链。
您必须拥有 PEM 编码文件的单独目标 CA 证书。
您必须有一个要公开的服务。
将 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 密钥。 |
此注解中引用的密钥将插入生成的路由中。
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-----
...