4.12. 为客户端连接配置基于 Operator 的代理部署
4.12.1. 配置接受者 复制链接链接已复制到粘贴板!
要在 OpenShift 部署中启用到代理 pod 的客户端连接,您可以为部署定义 acceptors。acceptors 定义代理 pod 如何接受连接。您可以在用于代理部署的主自定义资源(CR)中定义 acceptors。当您创建 acceptor 时,您可以指定在 acceptor 上启用的消息传递协议以及代理 pod 上的端口用于这些协议的信息。
流程
-
编辑用于代理部署的
ActiveMQArtemis
自定义资源(CR)。 在
acceptors
属性中,添加命名的 acceptor。添加 protocol和
port
属性。设置值,以指定接受者和每个代理 Pod 上的端口用于这些协议的消息传递协议。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置的 acceptor 将端口 5672 公开给 AMQP 客户端。您可以为
protocols
属性指定的完整值集合显示在表中。Expand 表 4.4. acceptor 协议 协议 值 核心协议
core
AMQP
amqp
OpenWire
OpenWire
MQTT
mqtt
STOMP
STOMP
所有支持的协议
all
注意- 对于部署中的每个代理 pod,Operator 还会创建一个使用默认接受者,它使用端口 61616。代理集群需要这个默认接收器,并启用核心协议。
- 默认情况下,AMQ Broker 管理控制台使用代理 pod 上的端口 8161。部署中的每个代理 pod 都有一个专用的 Service,提供对控制台的访问。如需更多信息,请参阅 第 5 章 为基于 Operator 的代理部署连接到 AMQ 管理控制台。
要在同一接收器中使用另一个协议,请修改 protocol 属性。
指定以逗号分隔的协议列表。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置的 acceptor 现在将端口 5672 公开给 AMQP 和 OpenWire 客户端。
要指定 acceptor 允许的并发客户端连接数,请添加
connectionsAllowed
属性并设置值。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 默认情况下,接受者仅公开给与代理部署相同的 OpenShift 集群中的客户端。要向 OpenShift 外部的客户端公开接受者,请将
expose
属性和sslEnabled
属性设置为true
。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 当您在接收器(或连接器)上启用 SSL (即安全套接字层)安全时,您可以添加相关的配置,例如:
- 用于在 OpenShift 集群中存储身份验证凭据的机密名称。当您在 acceptor 上启用 SSL 时,需要一个 secret。
-
用于保护网络通信的传输层安全(TLS)协议。TLS 是一个更新的、更加安全的 SSL 版本。您可以在
enabledProtocols
属性中指定 TLS 协议。 -
接受器是否使用 mTLS,也称为 mutual 身份验证,在代理和客户端之间。您可以通过将
needClientAuth
属性的值设置为true
来指定。
有关这些任务的更多信息,请参阅 第 4.12.2 节 “保护 broker-client 连接”。
当您向 OpenShift 外部的客户端公开接收器时,Operator 会自动为部署中的每个代理 pod 创建一个专用服务和 Openshift 路由。
如果要自定义每个 pod 上为 acceptor 公开的路由的主机名,以匹配 Openshift 集群上的内部路由配置,您可以执行以下操作之一或其中之一:
-
使用
ingressHost
属性将默认主机名替换为特定接受器的自定义主机名。 使用
ingressDomain
属性将自定义域附加到主机名。自定义域也应用于所有其他路由,如其他接收器和控制台的路由,这些路由由 CR 配置公开。要为 acceptor 路由设置自定义主机名,请添加
ingressHost
属性并指定 host 字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意ingressHost
值在 Openshift 集群中必须是唯一的。如果您的代理集群有多个代理 pod,您可以通过在值中包含 $(BROKER_ORDINAL)变量使ingressHost
值唯一。Operator 将每个代理 pod 上的此变量替换为分配给 pod 的 StatefulSet 的 ordinal 号。例如,第一个 pod 上的ingressHost
值my-acceptor-$(BROKER_ORDINAL)-production.my-subdomain.com
设置路由的主机名到my-acceptor-0-production.my-subdomain
,在第二个 pod 上设置my-acceptor-1-production.my-subdomain
的主机名,以此类推。您可以在自定义主机名字符串中为 acceptor 路由包含以下变量:
Expand 表 4.5. 自定义主机名字符串中的变量用于 acceptor 路由 Name 描述 $(CR_NAME)
CR 中的
metadata.name
属性的值。$(CR_NAMESPACE)
自定义资源的命名空间。
$(BROKER_ORDINAL)
StatefulSet 分配给代理 pod 的 ordinal 号。
$(ITEM_NAME)
接受者的名称。
$(RES_TYPE)
资源类型。路由的资源类型为
rte
。入口的资源类型为。
$(INGRESS_DOMAIN)
如果在 CR 中配置了
spec.ingressDomain
属性的值。要将自定义域附加到路由中的主机名,请添加
spec.ingressDomain
属性并指定自定义字符串。例如:spec: ... ingressDomain: my.domain.com
spec: ... ingressDomain: my.domain.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用
如果机构的网络策略需要您使用入口而不是路由公开接收器,请完成以下步骤:
添加
exposeMode
属性,并将值设置为ingress
。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果要自定义接受者公开的入口的主机名,以匹配 Openshift 集群上的内部路由配置,您可以执行以下操作之一或这两者:
-
使用
ingressHost
属性将默认主机名替换为自定义主机名。 使用
ingressDomain
属性将自定义域附加到主机名。自定义域也应用于所有其他入口,如其他接收器和控制台(由 CR 配置公开的)。要为 acceptor 设置 ingresses 的自定义主机名,请添加
ingressHost
属性并指定主机字符串。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 您可以包含相同的变量来自定义作为路由主机的 ingress 主机,这在此流程前面进行了描述。
要将自定义域附加到 ingresses 中的主机名中,请添加
spec.ingressDomain
属性并指定自定义字符串。例如:spec: ... ingressDomain: my-subdomain.domain.com
spec: ... ingressDomain: my-subdomain.domain.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于 acceptors,入口的默认主机名是 <
cr-name>-<acceptor name>-<ordinal>-svc-ing-<namespace>
; 的格式。例如,如果您在amqbroker
名称空间中有一个名为production
的 CR,则ingressDomain
值为mydomain.com
提供主机值production-wconsj-0-svc-mynamespace.amqbroker.com
用于 pod 0 上创建的 ingress。
-
使用
其他资源
- 要了解如何将 TLS 配置为安全 broker-client 连接,包括生成 secret 来存储身份验证凭证,请参阅 第 4.12.2 节 “保护 broker-client 连接”。
- 有关完整的自定义资源配置参考,包括接收器和连接器的配置,请参阅 第 8.1 节 “自定义资源配置参考”。
4.12.2. 保护 broker-client 连接 复制链接链接已复制到粘贴板!
如果您在接受或连接器上启用了安全性(即,通过将 sslEnabled
设置为 true
),您必须配置传输层安全(TLS)以允许代理和客户端之间的基于证书的身份验证。TLS 是一个更新的、更加安全的 SSL 版本。有两个主要的 TLS 配置:
- TLS
- 只有代理提供证书。客户端使用证书来验证代理。这是最常见的配置。
- mTLS
- 代理和客户端存在证书。这有时被称为 mutual 身份验证。
您可以使用各种方法生成 TLS 证书。
如果代理和客户端在同一 Openshift 集群上运行,您可以使用 Openshift 为代理生成服务用证书。
如果代理和客户端没有在同一 Openshift 集群上运行,则必须使用允许您自定义证书的方法生成证书。本节介绍了可以用来生成自定义证书的两个方法:
- Openshift 的 cert-manager Operator
- Java Keytool 实用程序。
4.12.2.1. 使用 Openshift 服务服务证书 复制链接链接已复制到粘贴板!
如果要保护同一 Openshift 集群上的代理和客户端之间的内部连接,您可以向 acceptor 服务添加注解,以请求 Openshift 生成服务服务证书。生成的证书和密钥采用 PEM 格式,分别存储在所创建 secret 的 tls.crt
和 tls.key
中。
用于发布服务证书的服务 CA 证书在 26 个月内有效,并在有效期少于 13 个月时进行自动轮转。轮转后,以前的服务 CA 配置仍会被信任直到其过期为止。这将为所有受影响的服务建立一个宽限期,以在过期前刷新其密钥内容。如果没有在这个宽限期内对集群进行升级(升级会重启服务并刷新其密钥),您可能需要手动重启服务以避免在上一个服务 CA 过期后出现故障。
流程
-
编辑用于代理部署的
ActiveMQArtemis
自定义资源(CR)。 使用
resourceTemplates
属性来注解为 acceptor 创建的服务。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow - resourceTemplates.selector.kind
-
指定自定义应用到的资源类型是
Service
。 - resourceTemplates.selector.name
指定要应用注解的服务名称。acceptor 服务的名称格式为: <
CR name><acceptor name><ordinal>-svc
,其中:-
<CR name> name 是 CR 中的
metadata.name
属性的值。 -
<acceptor name> 是 acceptor 的名称。示例假定 acceptor 的名称是
myacceptor
。 - <ordinal> 是 StatefulSet 分配给代理 pod 的 ordinal 号。
-
<CR name> name 是 CR 中的
- resourceTemplates.annotations
指定
service.beta.openshift.io/serving-cert-secret-name: <secret>
;,其中< secret > 是 Openshift 为服务创建的 secret 的名称。注意secret 名称必须与 acceptor 名称匹配,并且具有 a
-ptls
后缀。需要特定的后缀来允许 Operator 在创建 secret 前部署 CR。
在 CR 中的 sslSecret' 属性中,指定包含代理证书的 secret。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
brokerProperties
属性中,将代理配置为在每次证书在 Openshift 中续订时自动加载新证书。例如:spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.myacceptor.params.sslAutoReload=true" ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 将服务用证书的公钥添加到每个客户端的信任存储中。
如果要在代理和客户端之间配置 mTLS 身份验证,请完成以下步骤。
-
创建一个信任捆绑包,其中包含您希望代理信任的每个客户端的证书,并将信任捆绑包添加到 secret 中,如
trusted-clients-bundle
。 在代理 CR 中配置的 acceptors 中,添加
needClientAuth
属性,并设置为true
以要求客户端身份验证。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 acceptor 的
trustSecret
属性中,指定包含客户端证书信任捆绑包的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
创建一个信任捆绑包,其中包含您希望代理信任的每个客户端的证书,并将信任捆绑包添加到 secret 中,如
- 保存 CR。
其他资源
4.12.2.2. 为 Openshift 使用 cert-manager Operator 复制链接链接已复制到粘贴板!
OpenShift 的 cert-manager Operator 是一个集群范围的服务,提供应用程序证书生命周期管理。cert-manager 会自动来自各种证书颁发机构的 TLS 证书的管理和颁发。
以下示例流程描述了如何使用自签名证书配置传输层安全(TLS)。如果您的策略需要由可识别的证书管理器签名的证书,您可以使用 cert-manager Operator for OpenShift 请求证书。
先决条件
已安装 Red Hat OpenShift 的 cert-manager Operator。
如需更多信息,请参阅 OpenShift Container Platform 文档中的 为 Red Hat OpenShift 安装 cert-manager Operator。
如果要在代理和客户端之间配置 mTLS,则安装 Kubernetes 的信任管理器。
如需更多信息,请参阅安装 trust-manager。
流程
创建一个 YAML 文件,如
self-signed-issuer.yaml
,该文件定义了 root 自签名签发者。签发者(签发者)是一个 Openshift 资源,它代表证书颁发机构(CA),它可以通过遵循证书签名请求来生成签名证书。以下示例 yaml 创建一个自签名签发者,然后您可以使用它来创建证书颁发机构(CA)证书。您的 CA 证书可由 cert-manager Operator 管理。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建一个定义 root CA 证书的 YAML 文件,如
root-ca.yaml
。在
issuerRef.name
字段中,指定您创建的自签名签发者(root-issuer
)的名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 证书以 Privacy Enhanced Mail (PEM)格式创建,使用名为
root-ca-secret
的 secret。创建一个 YAML 文件,如
root-ca-issuer.yaml
,该文件定义了一个 CA 签发者来发布由 root CA 签名的证书。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建定义代理证书的 YAML 文件,如
broker-cert.yaml
。在
issuerRef.Name
字段中,指定签发者(root-ca-issuer
)的名称,用来发布由 root CA 签名的证书。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 YAML 文件中部署您为签发者和证书定义的自定义资源,以创建对应的 OpenShift 对象。例如:
oc create -f self-signed-issuer.yaml oc create -f root-ca.yaml oc create -f root-ca-issuer.yaml oc create -f broker-cert.yaml
$ oc create -f self-signed-issuer.yaml $ oc create -f root-ca.yaml $ oc create -f root-ca-issuer.yaml $ oc create -f broker-cert.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
编辑
ActiveMQArtemis
CR 以进行代理部署。 指定在您要保护的每个 acceptor 的
sslSecret
属性中包含代理证书的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
brokerProperties
属性中,将代理配置为在每次为 Openshift 的 cert-manager Operator 续订证书时自动加载接受者的新代理证书。例如:spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...
spec: ... brokerProperties - "acceptorConfigurations.new-acceptor.params.sslAutoReload=true" ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
将签名代理证书的 root CA 证书(在本例中名为
root-ca-secret
secret 的 secret 中创建)添加到每个客户端的信任存储中,以便客户端可以信任代理。 如果要在代理和客户端之间配置 mTLS 身份验证,请完成以下步骤。
-
使用 Trust Manager for Kubernetes 创建一个信任捆绑包,其中包含您要信任的每个客户端的证书,并将信任捆绑包添加到 secret 中,如
trusted-clients-bundle
。有关如何创建信任捆绑包的详情,请参考 trust-manager 文档。 在代理 CR 中配置的 acceptors 中,添加
needClientAuth
属性,并设置为true
以要求客户端身份验证。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在每个 acceptor 的
trustSecret
属性中,指定包含客户端证书信任捆绑包的 secret。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
使用 Trust Manager for Kubernetes 创建一个信任捆绑包,其中包含您要信任的每个客户端的证书,并将信任捆绑包添加到 secret 中,如
- 保存 CR。
4.12.2.3. 使用 Java keytool 工具 复制链接链接已复制到粘贴板!
keytool 是 Java 中包含的证书管理实用程序。
4.12.2.3.1. 配置单向 TLS 复制链接链接已复制到粘贴板!
本节中的步骤演示了如何配置单向传输层安全(TLS)来保护代理客户端连接。
在单向 TLS 中,只有代理提供证书。客户端使用此证书来验证代理。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.12.2.4 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从代理密钥存储导出证书,以便可以与客户端共享。以 Base64 编码的
.pem
格式导出证书。例如:keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,创建一个导入代理证书的客户端信任存储。
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到包含代理部署的项目。例如:
oc project <my_openshift_project>
$ oc project <my_openshift_project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建用于存储 TLS 凭据的机密。例如:
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/client.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在生成 secret 时,OpenShift 需要您同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts
。对于代理和客户端之间的单向 TLS,实际不需要信任存储。但是,要成功生成 secret,您需要将 一些 有效的存储文件指定为client.ts
的值。前面的步骤通过重新使用之前生成的代理密钥存储文件为client.ts
提供了 "dummy" 值。这足以生成带有单向 TLS 所需的所有凭证的 secret。将 secret 链接到安装 Operator 时创建的服务帐户。例如:
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在安全接收器或连接器的
sslSecret
参数中指定 secret 名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.3.2. 配置双向 TLS 复制链接链接已复制到粘贴板!
本节中的步骤演示了如何配置双向传输层安全(TLS)来保护代理客户端连接。
在双向 TLS 中,代理和客户端都会显示证书。代理和客户端使用这些证书在进程中相互进行身份验证,有时被称为 mutual 身份验证。
先决条件
- 当客户端使用主机名验证时,您应该了解代理证书生成的要求。更多信息请参阅 第 4.12.2.4 节 “为主机名验证配置代理证书”。
流程
为代理密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/broker.ks
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 从代理密钥存储导出证书,以便可以与客户端共享。以 Base64 编码的
.pem
格式导出证书。例如:keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
$ keytool -export -alias broker -keystore ~/broker.ks -file ~/broker_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,创建一个导入代理证书的客户端信任存储。
keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
$ keytool -import -alias broker -keystore ~/client.ts -file ~/broker_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,为客户端密钥存储生成自签名证书。
keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
$ keytool -genkey -alias broker -keyalg RSA -keystore ~/client.ks
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在客户端上,从客户端密钥存储导出证书,以便可以与代理共享。以 Base64 编码的
.pem
格式导出证书。例如:keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
$ keytool -export -alias broker -keystore ~/client.ks -file ~/client_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建导入客户端证书的代理信任存储。
keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
$ keytool -import -alias broker -keystore ~/broker.ts -file ~/client_cert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以管理员身份登录 OpenShift Container Platform。例如:
oc login -u system:admin
$ oc login -u system:admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 切换到包含代理部署的项目。例如:
oc project <my_openshift_project>
$ oc project <my_openshift_project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建用于存储 TLS 凭据的机密。例如:
oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
$ oc create secret generic my-tls-secret \ --from-file=broker.ks=~/broker.ks \ --from-file=client.ts=~/broker.ks \ --from-literal=keyStorePassword=<password> \ --from-literal=trustStorePassword=<password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意在生成 secret 时,OpenShift 需要您同时指定密钥存储和信任存储。信任存储密钥通常被命名为
client.ts
。对于代理和客户端之间的双向 TLS,您必须生成一个包含代理信任存储的 secret,因为这包含客户端证书。因此,在上一步中,您为client.ts
键指定的值实际上是 代理 信任存储文件。将 secret 链接到安装 Operator 时创建的服务帐户。例如:
oc secrets link sa/amq-broker-operator secret/my-tls-secret
$ oc secrets link sa/amq-broker-operator secret/my-tls-secret
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在安全接收器或连接器的
sslSecret
参数中指定 secret 名称。例如:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.12.2.4. 为主机名验证配置代理证书 复制链接链接已复制到粘贴板!
本节论述了在配置单向或双向 TLS 时必须生成的代理证书的一些要求。
当客户端试图连接到部署中的代理 Pod 时,客户端连接 URL 中的 verifyHost
选项决定了客户端是否将代理证书的通用名称(CN)与主机名进行比较,以验证它们是否匹配。如果您在客户端连接 URL 中指定 verifyHost=true
或类似,客户端执行此验证。
当您对连接安全性没有考虑的情况,例如,如果代理部署在隔离的网络的 OpenShift 集群中,您可能会在个别情况下省略此验证。否则,对于安全连接,建议客户端执行此验证。在这种情况下,代理密钥存储证书正确配置非常重要,以确保成功客户端连接。
通常,当客户端使用主机验证时,您在生成代理证书时指定的 CN 必须与客户端连接到的代理 Pod 上的 Route 的完整主机名匹配。例如,如果您使用单个代理 Pod 部署,CN 可能类似如下:
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
为确保 CN 可以解析带有多个代理的的代理 Pod 中的任何代理,您可以指定一个星号(*
)通配符字符来代替普通的代理 Pod。例如:
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
CN=my-broker-deployment-*-svc-rte-my-openshift-project.my-openshift-domain
上例中显示的 CN 可以成功解析到 my-broker-deployment
部署中的任何代理 Pod。
另外,您在生成代理证书时指定的 Subject Alternative Name (SAN) 必须单独列出 部署中的所有代理 Pod,作为用逗号分开的列表。例如:
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
"SAN=DNS:my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain,DNS:my-broker-deployment-1-svc-rte-my-openshift-project.my-openshift-domain,..."
4.12.3. 代理部署中的网络服务 复制链接链接已复制到粘贴板!
在代理部署的 OpenShift Container Platform Web 控制台的 Networking 窗格中,有两个运行的服务: 无头服务 和 ping 服务。无头服务的默认名称使用 < custom_resource_name>-hdls-svc
,例如 my-broker-deployment-hdls-svc
。ping 服务的默认名称使用 < custom_resource_name>-ping-svc
的格式,例如 'my-broker-deployment-ping-svc
。
无头服务提供对端口 61616 的访问,该端口用于内部代理集群。
ping 服务供代理用于发现,并允许代理在 OpenShift 环境中组成集群。在内部,此服务会公开端口 8888。
4.12.4. 从内部和外部客户端连接到代理 复制链接链接已复制到粘贴板!
本节中的示例演示了如何从内部客户端(即,与代理部署相同的 OpenShift 集群中的客户端)和外部客户端(即 OpenShift 集群外部的客户端)连接到代理。
4.12.4.1. 从内部客户端连接到代理 复制链接链接已复制到粘贴板!
要将内部客户端连接到代理(在客户端连接详情中),请指定代理 pod 的 DNS 可解析名称。例如:
tcp://ex–aao-ss-0:<port>
$ tcp://ex–aao-ss-0:<port>
如果内部客户端使用 Core 协议,且 useTopologyForLoadBalancing=false
密钥没有在连接 URL 中设置,则在客户端第一次连接到代理后,代理可以通知客户端集群中的所有代理地址。然后,客户端可以在所有代理之间负载平衡连接。
如果您的代理有持久的订阅队列或请求/回复队列,请注意在客户端连接负载平衡时使用这些队列相关的注意事项。更多信息请参阅 第 4.12.4.4 节 “当您有持久订阅队列或回复/请求队列时,对负载均衡客户端连接的注意事项”。
4.12.4.2. 从外部客户端连接到代理 复制链接链接已复制到粘贴板!
当您向外部客户端公开接收器(即,通过将 expose
参数的值设置为 true
)时,Operator 会自动为部署中的每个代理 pod 创建一个专用服务和路由。
外部客户端可以通过指定为代理 pod 创建的路由的完整主机名来连接到代理。您可以使用基本的 curl
命令测试此完整主机名的外部访问。例如:
curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
$ curl https://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain
代理 Pod 的路由的完整主机名必须解析为托管 OpenShift 路由器的节点。OpenShift 路由器使用主机名来确定在 OpenShift 内部网络内发送流量的位置。默认情况下,OpenShift 路由器在端口 80 上侦听非安全(即非 SSL)流量,以及用于安全(即 SSL 加密)流量的端口 443。对于 HTTP 连接,如果指定了一个非安全连接 URL (即 https
)或端口 80 (即 http
),则路由器会自动将流量定向到端口 443。
如果您希望外部客户端在集群中的代理间负载均衡连接:
-
通过在每个代理 Pod 的 OpenShift 路由上配置
haproxy.router.openshift.io/balance
roundrobin 选项来启用负载平衡。 如果外部客户端使用 Core 协议,请在客户端的连接 URL 中设置
useTopologyForLoadBalancing=false
密钥。设置
useTopologyForLoadBalancing=false
键可防止客户端使用代理提供的集群拓扑信息中的 AMQ Broker Pod DNS 名称。Pod DNS 名称解析为内部 IP 地址,外部客户端无法访问该地址。
如果您的代理有持久的订阅队列或请求/回复队列,请注意在负载平衡客户端连接时使用这些队列相关的注意事项。更多信息请参阅 第 4.12.4.4 节 “当您有持久订阅队列或回复/请求队列时,对负载均衡客户端连接的注意事项”。
如果您不希望外部客户端在集群中的不同代理间进行负载均衡连接:
- 在每个客户端的连接 URL 中,指定每个代理 pod 的路由的完整主机名。客户端尝试连接到连接 URL 中的第一个主机名。但是,如果第一个主机名不可用,客户端会自动连接到连接 URL 中的下一个主机名,以此类推。
-
如果外部客户端使用 Core 协议,请在客户端的连接 URL 中设置
useTopologyForLoadBalancing=false
键,以防止客户端使用代理提供的集群拓扑信息。
对于非 HTTP 连接:
- 客户端必须明确指定端口号(例如,端口 443)作为连接 URL 的一部分。
- 对于单向 TLS,客户端必须指定其信任存储的路径和对应的密码,作为连接 URL 的一部分。
- 对于双向 TLS,客户端还必须指定其密钥存储的路径和对应的密码,作为连接 URL 的一部分。
以下显示了一些客户端连接 URL (对于支持的消息传递协议)。
外部核心客户端,使用单向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&trustStorePath=~/client.ts&trustStorePassword=<password>
在连接 URL 中明确将 useTopologyForLoadBalancing
键明确设置为 false
,因为外部核心客户端无法使用代理返回的拓扑信息。如果此键设为 true
,或者您没有指定值,则会生成 DEBUG 日志消息。
外部核心客户端,使用双向 TLS
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \ &keyStorePath=~/client.ks&keyStorePassword=<password> \ &trustStorePath=~/client.ts&trustStorePassword=<password>
tcp://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?useTopologyForLoadBalancing=false&sslEnabled=true \
&keyStorePath=~/client.ks&keyStorePassword=<password> \
&trustStorePath=~/client.ts&trustStorePassword=<password>
外部 OpenWire 客户端,使用单向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
外部 OpenWire 客户端,使用双向 TLS
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443" # Also, specify the following JVM flags -Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \ -Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
ssl://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443"
# Also, specify the following JVM flags
-Djavax.net.ssl.keyStore=~/client.ks -Djavax.net.ssl.keyStorePassword=<password> \
-Djavax.net.ssl.trustStore=~/client.ts -Djavax.net.ssl.trustStorePassword=<password>
外部 AMQP 客户端,使用单向 TLS
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
外部 AMQP 客户端,使用双向 TLS
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \ &transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \ &transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
amqps://my-broker-deployment-0-svc-rte-my-openshift-project.my-openshift-domain:443?transport.verifyHost=true \
&transport.keyStoreLocation=~/client.ks&transport.keyStorePassword=<password> \
&transport.trustStoreLocation=~/client.ts&transport.trustStorePassword=<password>
4.12.4.3. 使用 NodePort 连接到代理 复制链接链接已复制到粘贴板!
作为使用路由的替代选择,OpenShift 管理员可以配置 NodePort 以从 OpenShift 外部的客户端连接到代理 pod。NodePort 应映射到由为代理配置的 acceptors 指定的一个协议特定端口。
默认情况下,NodePort 在 30000 到 32767 之间,这意味着 NodePort 通常与代理 Pod 上的预期端口不匹配。
要通过 NodePort 从 OpenShift 外部客户端连接到代理,您需要以 <protocol>://<ocp_node_ip>:<node_port_number>
格式指定一个 URL。
4.12.4.4. 当您有持久订阅队列或回复/请求队列时,对负载均衡客户端连接的注意事项 复制链接链接已复制到粘贴板!
持久化订阅
持久化订阅以代理上的队列表示,并在持久订阅者首先连接到代理时创建。此队列存在并接收消息,直到客户端取消订阅为止。如果客户端重新连接到不同的代理,则会在该代理上创建另一个持久订阅队列。这可能导致以下问题。
问题 |
缓解方案 |
消息可能会在原始订阅队列中显示。 |
通过为地址或一组地址设置
在这个示例中,代理会在队列的最终消费者关闭后等待 5000 毫秒,然后再将消息重新分发到其他代理。 有关消息重新发布的更多信息,请参阅启用消息重新发布。 |
当其他消息仍然被路由时,消息可能会以错误的顺序接收,因为消息重新发布期间会出现一个窗口。 |
无。 |
当客户端取消订阅时,它只删除其上一次连接的代理上的队列。这意味着其他队列仍然可以存在并接收消息。 |
要删除其他可能为未订阅的客户端存在的空队列,请为地址或一组地址配置以下两个属性:您可以在
将 如需更多信息,请参阅配置自动创建和删除地址和队列。 |
请求/Reply 队列
当 JMS Producer 创建临时回复队列时,会在代理上创建队列。如果从工作队列消耗的客户端并响应临时队列连接到不同的代理,则可能会出现以下问题。
问题 | 缓解方案 |
---|---|
由于客户端连接到的代理上不存在回复队列,客户端可能会生成错误。 |
将代理配置为在客户端请求连接到不存在的队列时自动创建队列。若要配置自动队列创建,请在
|
发送到工作队列的消息可能无法分发。 |
通过在
另外,通过为地址或一组地址设置
如需更多信息,请参阅启用消息重新发布。 |
其他资源
有关使用 Routes 和 NodePort 等方法与集群中运行的服务从外部通信的更多信息,请参阅:
- OpenShift Container Platform 文档中的配置集群入口流量概述。
4.12.5. 禁用 FIPS 模式 复制链接链接已复制到粘贴板!
Federal Information Processing Standard (FIPS) Publication 140-3 是一个标准,用于指定应用程序中使用的加密模块的安全要求。AMQ Broker 是 FIPS-tolerant,这意味着它在启用了 FIPS 的 OpenShift 集群中自动运行。如果要允许代理接受使用非FIPS 兼容算法的客户端的连接,您可以在代理中禁用 FIPS 模式。如果您禁用 FIPS 模式,代理可以加载不兼容 FIPS 的加密模块。
流程
-
编辑用于代理部署的
ActiveMQArtemis
自定义资源(CR)。 添加环境变量来设置在代理中禁用 FIPS 模式的 Java 系统属性。例如:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
保存
ActiveMQArtemis
CR。